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 currently 54 tables, of which probably 30 will
be audited. So a INT PK wouldn't work because of the number of updates we
On Fri, May 31, 2013 at 9:58 AM, Carsten Pedersen <carsten@stripped>wrote:
> On 30-05-2013 09:27, Neil Tompkins wrote:
>> 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
>> 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
>> Is this the best approach, or should I have a individual field in the
>> table for all primary keys. At the moment I think the max number of
>> primary keys on any given table is 3
> First you need to ask yourself how you expect to use the table in the
> future. Will you be looking up the data on a regular basis? Or will lookups
> only be something you will do in exceptional situtions?
> What is the intended goal of having a UUID for the primary key rather
> than, say, an integer - or having no PK at all?
> My immediate thought when reading this was "why even store that data in a
> table?" - if it's a simple log, use a log file. Especially if you don't
> know how you intend to search for data later on. There are many tools that
> are far superior to SQL when it comes to searching for text strings. You
> could even consider having a CSV table, which will give you an SQL
> interface to said text file.
> / Carsten
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe: http://lists.mysql.com/mysql