Hi all.
How can we manage the history of changed rows in the database. I have some
idea but not yet implemented. By using triggers to make a copy of the row
being changed to the another table in the same db. Is there any way to only
save the changed fields data and field name? Any other idea?
Thanks
CPK

--
Keep your Environment clean and green.

No problem.

I do this using three triggers on Insert, Update and Delete. Then
update a log file who's schema starts:

CREATE TABLE ?_log (
id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
transact ENUM ('I','U','D') NOT NULL,
key_from_table ??? NOT NULL,
KEY (key_from_table),
field_1 ?? ,
field_2 ??,
...
field_n ??

I don't know a way of copying over every field accept long-hand in the
triggers.

Hope this is useful...

Ben


C K wrote:
> Hi all.
> How can we manage the history of changed rows in the database. I have some
> idea but not yet implemented. By using triggers to make a copy of the row
> being changed to the another table in the same db. Is there any way to only
> save the changed fields data and field name? Any other idea?
> Thanks
> CPK
>

C K wrote:
> Hi all.
> How can we manage the history of changed rows in the database. I have some
> idea but not yet implemented. By using triggers to make a copy of the row
> being changed to the another table in the same db. Is there any way to only
> save the changed fields data and field name? Any other idea?
> Thanks
> CPK
>
How about mysqlbinlog?

CK,

>How can we manage the history of changed rows in the database.

Point-in-time architecture. For a bit of discussion see
http://www.artfulsoftware.com/infotree/tip.php?id=547

PB

-----

C K wrote:
> Hi all.
> How can we manage the history of changed rows in the database. I have some
> idea but not yet implemented. By using triggers to make a copy of the row
> being changed to the another table in the same db. Is there any way to only
> save the changed fields data and field name? Any other idea?
> Thanks
> CPK
>
>
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG.
> Version: 7.5.519 / Virus Database: 269.23.1/1385 - Release Date: 4/18/2008 9:30 AM
>

On Fri, Apr 18, 2008 at 8:13 AM, Peter Brawley <peter.brawley@earthlink.net>
wrote:

> CK,
>
> > How can we manage the history of changed rows in the database.
> >
>
> Point-in-time architecture. For a bit of discussion see
> http://www.artfulsoftware.com/infotree/tip.php?id=547
>
> PB


I have used this convention and it works well.

I have a real problem with how it suggests using NULL. NULL is undefined,
and they are basically abusing it to mean infinite positive. NULL has issues
being indexed, big datetime values don't.

At the recent postgres convention I eavesdropped on a discussion about a
possible new temporal range format which would basically consist of a start
date and an end date and preclude any other entries from overlapping. Such
a format would be ideal for PITA, but the start and end would need to be not
null...

--
Rob Wultsch
wultsch@gmail.com
wultsch (aim)

Thanks for all of you. I will test the suggestions and then reply.
CPK


--
Keep your Environment clean and green.