| mwilliams 2006-02-21, 1:23 pm |
| Yes, schema changes would/should be rare. You may be right, but I would think that since schema information is *alway* checked before any INSERTS then we should be good. There should never be an occasion to "break" per se. Obviously anything can happen
, and appropriate recovery methods (e.g. via reguar dumps) would be in place, but I don't necessarily see that happening often, if at all.
All excellent points though!
Regards
---------- Original Message ----------------------------------
From: SGreen@unimin.com
Date: Tue, 21 Feb 2006 13:29:22 -0500
>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@mgreg.com> wrote on 02/21/2006 01:08:52 PM:
>
><snipped>
>
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql? unsub...sie.nctu.edu.tw
|