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: [EMAIL PROTECTED] 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" <[EMAIL PROTECTED]> 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> > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
