Ok, I get that. I have several tables just like that (I use mine as shadow
tables for change audits. Every change to the "normal" table ends up
creating new record in the "shadow" table thus documenting each state of
the normal table through time). However, shouldn't schema changes be very
rare under such a design as yours?
Such infrequent modifications deserve any special attention it would take
to convert the output of a SHOW CREATE TABLE xxx into a sequence of ALTER
TABLE statements within whichever programming language you are using to
control the synchronization. I mean it's not hard to take the output of a
SHOW CREATE TABLE xxx statement and transform it into a sequence of ALTER
TABLE statements. Alternatively, you could use the output from a SHOW
COLUMNS FROM xxx statement as the important parts are already parsed into
separate columns (column name, data type, null or not null, etc.).
If the application on A is changed to use a new table design (X2) and that
schema change is sent to Server B, how does the application on Server B
not "break" ? In particular, if you created X2 by deleting a column from
X, that would cause major problems with the application running on B until
B is notified of the change from X to X2, wouldn't it?
I am not trying to discourage your design or your plan of attack. I am
just trying to help by playing "devil's advocate". If you plan works well,
it may be something many of us in the community may be interested in
trying for some of our data issues, if you can share. We understand if you
can't.
Yours,
Shawn Green
Database Administrator
Unimin Corporation - Spruce Pine
"mwilliams" <mwilliams@stripped> wrote on 02/21/2006 01:08:52 PM:
> Ah, well, in this particular DB, *every single transaction* it's
> it's own entry. . .basically the DB itself is a binary log. . .
> kinda. . .sorta. So the current value of a particular item isn't
> necessarily an issue since, once entered, it will always be the
> same. A change to that value will in itself be a transaction with
> its own UUID.
>
> As for your question regarding how it's any different, I'm not
> really sure, besides the need to have the server go down or be
> locked for a period of time.
>
> Regards,
> Michael
>
<snipped>
