NYCPHP Meetup

[dorgan at optonline.net]

why not make a table then with 4 fields 1 being an id of course, one being 
the parentid or original version, and the other two fields one being the 
name of the field updated and the other being what the field was changed to.


----- Original Message -----
From: Adam Maccabee Trachtenberg <adam at trachtenberg.com>
Date: Tuesday, April 27, 2004 1:58 pm
Subject: Re: [nycphp-talk] MySQL versioning system

> On Tue, 27 Apr 2004, Mark Withington wrote:
> 
> > I have a client who would like to store product development 
> information> within a MySQL table.  The table will consist of 
> multiple fields, each
> > representing a product attribute (height, weight, color, etc.).  
> The client
> > would like to store each iteration (or version) of the product 
> development> information along with the ability to role back to 
> prior versions if
> > necessary.
> 
> My first idea would be to create a unique identifier for each product
> and store all the product specifications alongside the identifier and
> a version number. When you select the specifications for a product,
> select the one with the highest version number. Rolling back only
> requires you to delete the highest version number from the database.
> 
> The easiest version number is either an auto_increment field or maybe
> a timestamp of the insert time.
> 
> Also, if you were super concerned about select speed, you could make
> an additional column that's an enum('current', 'old') and make the
> latest version as "current" and the others as "old". Of course, this
> requires more convoluted insert / update logic. But this may or may
> not be necessary.
> 
> -adam
> 
> -- 
> adam at trachtenberg.com
> author of o'reilly's php cookbook
> avoid the holiday rush, buy your copy today!
> _______________________________________________
> talk mailing list
> talk at lists.nyphp.org
> http://lists.nyphp.org/mailman/listinfo/talk
>