Mittwoch, 5. Juni 2013

Fields a table should always have

These are fields I think should be available in (almost) every database table, everywhere:


  • id
    • A unique identifier. There might be a few exceptions, but almost every time I designed a table without a primary key, I came to regret it afterwards.
  • created_by
    • Almost always, you want to be able to find out who did what, when, where.
  • created_at
    • Almost always, you want to be able to find out who did what, when, where.
  • updated_at
    • Almost always, you want to be able to find out who did what, when, where. Obviously you don't need this field on insert-only tables.
  • is_active
    • Most of the time, you do not actually want to delete data. You want to deativate it, mark it deleted. On rare, VERY rare occasions, it makes sense to move it to another table or database. But that's really the exception. By default, just mark it as unactive or deleted or whatever. Quite often, you might want a status instead of a flag. (But only VERY rarely, methinks, do you want both. It's a smell to have a lot of flags, and it's another smell to have a status field plus flags.)
  • source
    • AT LEAST on tables that you (might at some point) import from another database, you want to mark the source. I can't count the times I've had to create enormous code monsters just to heuristically find out what data came from the last import, just to then delete it and re-start the process. DELETE FROM funny_table WHERE source='my_funny_import' would have made my life so much easier! (There, I said it: Delete. Yep, that's definitely one exception where it actually makes sense.)