On June 28, 2003 05:33 am, Aodhan Cullen wrote:
> 6/27/03 6:37:49 PM, Jeremy Zawodny <[EMAIL PROTECTED]> wrote:
> >> My read/update ratio would be something along the lines of 1:3, 3
> >> updates for every read. So it is highly unusual, and more or less
> >> rules replication out of the picture.
>
6/27/03 6:37:49 PM, Jeremy Zawodny <[EMAIL PROTECTED]> wrote:
>> My read/update ratio would be something along the lines of 1:3, 3
>> updates for every read. So it is highly unusual, and more or less
>> rules replication out of the picture.
>
>I'm unclear why you can't use replication for this. T
On Thu, Jun 26, 2003 at 08:33:15PM +0100, Aodhan Cullen wrote:
>
> I've got an interesting problem for you all. I'd love to hear what
> you think.
>
> I've simplified the database design of my web application to its
> root problem, so it'll be very easy to see my difficulty, and if
> you're feelin
>I think it's always a bad idea to create complex setups like you are
>contemplating.
I'd agree. They are very hard to maintain if you need to change things in the
future.
>see any reason to use varchar, that creates variable length records
>which you want to avoid if you can. Especially with
> adding an integer 'userid' to member table and using it as a foreign key
> in member_log table instead of username.
You're right. The main reason i'm doing this, is due to legacy reasons.
> Also, I don't know what you mean by 'medint' but if it is a mediumint,
> you will be in trouble since its
I think it's always a bad idea to create complex setups like you are
contemplating. I would try everything else first. For instance, I don't
see any reason to use varchar, that creates variable length records
which you want to avoid if you can. Especially with the number of
records you are comp
Sorry to reply to myself but after reading your post again,
I think you can use replication to maintain member table in sync:
it is possible to restrict replication to a some tables within a
database: check 'replicate-do-table' option.
Hope this helps
Joseph Bueno
Joseph Bueno wrote:
I don't have d
I don't have direct answers to your questions but you should consider
adding an integer 'userid' to member table and using it as a foreign key
in member_log table instead of username. It will make selects and joins
faster, data and index sizes smaller.
Also, I don't know what you mean by 'medint' b
I've got an interesting problem for you all. I'd love to hear what you think.
I've simplified the database design of my web application to its root problem,
so it'll be very easy to see my difficulty, and if you're feeling generous
possibly offer a solution.
I have two tables.
member table (ci
