Question

I am developing a database to store test data. Each piece of data has 11 tags of metadata. Currently I have a separate table for each of the metadata options. I have seen a few questions on here regarding best practices for numerous small tables, but I thought I’d pose the question for my own project because I didn’t get a clear answer from the other questions asked.

Here is my table list, with the fields in each table:

Source Type - id, name, description
For Flight - id, name, description
Site - id, name, abrv, description
Stand - id, site (FK site table), name, abrv, descrition
Sensor Type - id, name, channels, descrition
Vehicle - id, name, abrv, descrition
Zone - id, vehicle (FK vehicle table), name, abrv, description
Event Type - id, name, description
Event - id, event type (FK to event type Table), name, descrition
Analysis - id, name, descrition
Bandwidth - id, name, descrition

You can see the fields are more or less the same in each of these tables. There are three tables that reference another table.

Would it be better to have just one large table called something like Meta with the following fields:

Meta: id, metavalue, name, abrv, FK, value, descrition

where metavalue = one of the above table names
and FK = a reference to another row in the Meta table in place of a foreign key?

I am new to databases and multiple tables seems most intuitive, but one table makes the programming easier.

So questions are:

1. Is it good practice to reduce the number of tables and put all static values in one table.
2. Is it bad to have a self referencing table.

FYI I am making this web database using django and mysql on a windows server with NTFS formatting.

Tips and best practices appreciate.

thanks.

Answer 1

“Would it be better to have just one large table” – emphatically and categorically, NO!

This anti-pattern is sometimes referred to as ‘The one table to rule them all”!

Ten Common Database Design Mistakes: One table to hold all domain values.

• Using the data in a query is much easier

• Data can be validated using foreign key constraints very naturally,
  something not feasible for the other
  solution unless you implement ranges
  of keys for every table – a terrible
  mess to maintain.

• If it turns out that you need to keep more information about a
  ShipViaCarrier than just the code,
  ‘UPS’, and description, ‘United Parcel
  Service’, then it is as simple as
  adding a column or two. You could even
  expand the table to be a full blown
  representation of the businesses that
  are carriers for the item.

• All of the smaller domain tables will fit on a single page of disk.
  This ensures a single read (and likely
  a single page in cache). If the other
  case, you might have your domain table
  spread across many pages, unless you
  cluster on the referring table name,
  which then could cause it to be more
  costly to use a non-clustered index if
  you have many values.

• You can still have one editor for all rows, as most domain tables will
  likely have the same base
  structure/usage. And while you would
  lose the ability to query all domain
  values in one query easily, why would
  you want to? (A union query could
  easily be created of the tables easily
  if needed, but this would seem an
  unlikely need.)