Bastian Balthazar Bux wrote:
We need to track the modification to the records too so the route has
been to keep them all in a different, specular databases.
If the "real" table look like this:
CREATE TABLE `users` (
`id` int(11) NOT NULL auto_increment,
`ts` timestamp NOT NULL
default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP,
`username` varchar(32) default NULL,
`password` varchar(32) default NULL,
PRIMARY KEY (`id`)
);
The backup one look like this:
CREATE TABLE `users` (
`del__id` int(11) NOT NULL auto_increment,
`del__ts` timestamp NOT NULL
default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP,
`del__flag` char(1) default 'D',
`del__note` mediumtext,
`id` int(11) NOT NULL auto_increment,
`ts` datetime NOT NULL default '0000-00-00 00:00:00',
`username` varchar(32) default NULL,
`password` varchar(32) default NULL,
PRIMARY KEY (`del__id`)
);
That is the first one whit "del__*" fields added but all indexed removed.
Having the same name and similar schema for the two tables make easier
have a photo of the database in a defined time slice.
Usefull with small, not very often changing databases.
hi bastian
just a thought. rather stay away from auto_increment PK's and rather
generate your own PK.
i have run into trouble a couple of times using auto_increment when i
made backups and restored the data again. The PK changed and i had
records in other tables referencing the old PK , but then the PK changed.
--
Arno Coetzee
Developer
Flash Media Group
Office : 2712 342 7595
Mobile : 2782 693 6180
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
