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 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
> Is this the best approach, or should I have a individual field in the audit
> 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.