Re: Audit Table storage for Primary Key(s)

2013-05-31 Thread Andrew Moore
** 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

RE: Audit Table storage for Primary Key(s)

2013-05-31 Thread Jason Trebilcock
Original Message- From: Neil Tompkins [mailto:neil.tompk...@googlemail.com] Sent: Friday, May 31, 2013 3:43 AM To: [MySQL] Subject: Fwd: Audit Table storage for Primary Key(s) Any advice anyone ? -- Forwarded message -- From: Neil Tompkins Date: Thu, May 30, 2013 at 8:27 AM

RE: Audit Table storage for Primary Key(s)

2013-05-31 Thread Rick James
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. > &

Re: Audit Table storage for Primary Key(s)

2013-05-31 Thread Andrew Moore
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

Re: Audit Table storage for Primary Key(s)

2013-05-31 Thread Carsten Pedersen
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

Re: Audit Table storage for Primary Key(s)

2013-05-31 Thread Neil Tompkins
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

Re: Audit Table storage for Primary Key(s)

2013-05-31 Thread Carsten Pedersen
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

Re: Audit Table storage for Primary Key(s)

2013-05-31 Thread Neil Tompkins
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

Re: Audit Table storage for Primary Key(s)

2013-05-31 Thread Carsten Pedersen
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

Fwd: Audit Table storage for Primary Key(s)

2013-05-31 Thread Neil Tompkins
Any advice anyone ? -- Forwarded message -- From: Neil Tompkins Date: Thu, May 30, 2013 at 8:27 AM Subject: Audit Table storage for Primary Key(s) To: "[MySQL]" Hi, I've created a Audit table which tracks any changed fields for multiple tables. In my Audit ta

Audit Table storage for Primary Key(s)

2013-05-30 Thread Neil Tompkins
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 VARCHAR field which stores primary keys like 1 1|