One table or many? [closed]

Answer 1

"life is easier with the one big table": I've seen the natural consequence of this, being a 100+ column table, and I can tell you I find this no joy to work with.

The main problem is that the designers of such tables tend to omit the constraints required to ensure data integrity. For example, the OP says:

a journal reference requires both a journal title and an article title, and also a page number, whereas a book requires a publisher and a publication date which journal articles do not require

...which implies the following constraints:

CONSTRAINT a_journal_must_have_a_journal_title
   CHECK ( type <> 'journal' OR journal_title IS NOT NULL );

CONSTRAINT a_journal_must_have_an_article_title 
   CHECK ( type <> 'journal' OR article_title IS NOT NULL );

CONSTRAINT a_journal_must_have_a_page_number 
   CHECK ( type <> 'journal' OR page_number IS NOT NULL );

CONSTRAINT a_journal_cannot_have_a_publisher 
   CHECK ( type <> 'journal' OR publisher IS NULL );

CONSTRAINT a_journal_cannot_have_a_publication_date 
   CHECK ( type <> 'journal' OR publication_date IS NULL );

CONSTRAINT a_book_cannot_have_a_journal_title 
   CHECK ( type <> 'book' OR journal_title IS NULL );

CONSTRAINT a_book_cannot_have_a_article_title 
   CHECK ( type <> 'book' OR article_title IS NULL );

CONSTRAINT a_book_cannot_have_a_page_number 
   CHECK ( type <> 'book' OR page_number IS NULL );

CONSTRAINT a_book_must_have_a_publisher 
   CHECK ( type <> 'book' OR publisher IS NOT NULL );

CONSTRAINT a_jbook_must_have_a_publication_date 
   CHECK ( type <> 'book' OR publication_date IS NOT NULL );

...and I suspect that's only the tip of the iceberg!

It's my hope that after writing several hundred such constraints the designer may have second thoughts about all those nullable columns :)

Answer 2

You're asking about database normalization. Jeff Atwood wrote about it in his post Maybe Normalizing Isn't Normal. It's a good read.

Answer 3

I think you have to look ahead at what the SQL will look like for each of the solutions. If you go through that excercise, then you'll find that putting everything in one table is the easiest to code and will probably lead to having the best performance. It's easier to separate out the things you want from one table then it is to put things together from multiple tables.

Lets say my-one-big-table looks like this:

1 id
2 type
3 field-common-to-book-and-journal
4 field-specific-to-book
5 field-specific-to-journal

If I am just interested in books, I can create a view, or just plain sql, like this:

create view book as  
select id, field_common-to-book-and-journal, field-specific-to-book
from my-one-big-table
where type = 'book'

So, it's easy to simulate that the data is in separate tables when I want to.

But, if I start off by putting the data in seperate tables then I'll end up writing SQL like this:

select id, field-common-to-book-and-journal from books
union
select id, field-common-to-book-and-journal from journal-articles
union
.... etc, for each type

I don't know about other databases, but doing unions in SQL Server can be costly and there are restrictions when working with datatypes like ntext.

If you follow olavk's advice then your SQL for combining types in one query would end up looking like this:

select 
    common.id, 
    common.field-common-to-book-and-journal, 
    book.field-specific-to-book 
    journal.field-specific-to-journal
from common-table common
left outer join book-specific-table book on 
left outer join journal-specific-table journal on
... etc, for each type

I've worked with systems that used all three of these ways and by far, life is easier with the one big table.

Answer 4

I don't find the need to join tables particularly tedious; I'd take the more normalized approach here.

Answer 5

one table and a "type" field would be my suggestion

Answer 6

There's another option: not one I'd fully endorse, but it's still another option:

Use three tables:

refs (id, title, refType)
-- title of the reference, and what type of reference it is

fieldDef (id, fieldName, refType, dataType)
-- name of the field, which reference types it applies to, and
-- what type of data is stored in these fields (ISDN number, date, etc)

fields (refId, fieldId, value)
-- where you actually add data to the references.

refType can be the type of reference, and if you make it an integer with values increase by powers of two (1, 2, 4, 8...) then they can be added together to make a bitmask in the fieldDef table.

Pros: very simple and extensible. If you come up with another type of reference, or a new field type for an existing reference type, it can be added in very quickly. Forms can be automatically generated for each reference type. All data is stored in one place, meaning you don't need to keep track of multiple schemas (schemata?) for CRUD operations.

Cons: this is the stuff that The Daily WTF is made on. Select statements can become very confusing and complicated. The database can't perform type-checking (eg: for dates, etc), and the generic "value" field will not be optimised for the data being stored in it.