** how much RAM you have
>
> > -Original Message-
> > From: Carsten Pedersen [mailto:cars...@bitbybit.dk]
> > Sent: Friday, May 31, 2013 4:05 AM
> > Cc: [MySQL]
> > Subject: Re: Audit Table storage for Primary Key(s)
> >
> > Based on the little infor
I'll ask the dumb question.
Why not create individual history tables corresponding to your 'main'
tables? So, if you have an 'address' table, then the original record could
be written to an 'address_his' table via an update or delete trigger
(depending on whether you allow deletions or not) when a
om: Carsten Pedersen [mailto:cars...@bitbybit.dk]
> Sent: Friday, May 31, 2013 4:05 AM
> Cc: [MySQL]
> Subject: Re: Audit Table storage for Primary Key(s)
>
> Based on the little information available, I would make a lookup field
> consisting of tablename and primary keys.
>
&
There's been a thirst for this kind of thing for sometime but possibly
you're looking for a cheaper option? Since 5.5 there's some incarnation of
an audit plugin which can be extended for your own needs which should allow
you to perform some persistence of the results with either a log file which
c
Based on the little information available, I would make a lookup field
consisting of tablename and primary keys.
(although I still believe that storing this information in the database
in the first place is probably the wrong approach, but to each his own)
/ Carsten
On 31-05-2013 12:58, Neil
The kind of look ups will be trying to diagnose when and by who applied a
update. So the primary key of the audit is important. My question is for
performance, should the primary key be stored as a indexed field like I
mentioned before, or should I have a actual individual field per primary key
Again: Unless you can give some idea as to the kind of lookups you will
be performing (which fields? Temporal values? etc.), it is impossible to
give advice on the table structure. I wouldn't blame anyone for not
being able to do so; saving data for debugging will always be a moving
target and
Thanks for your response. We expect to use the Audit log when looking into
exceptions and/or any need to debug table updates. I don't think a CSV
table would be sufficient as we are wanting to use a interface to query
this data at least on a daily basis if not weekly.
I use UUID because we have
On 30-05-2013 09:27, Neil Tompkins wrote:
Hi,
I've created a Audit table which tracks any changed fields for multiple
tables. In my Audit table I'm using a UUID for the primary key. However I
need to have a reference back to the primary key(s) of the table audited.
At the moment I've a VARCHA
