One table or many? [closed]

Answer 1

My advise is to start by designing the database properly, that is using normalisation to ensure tables only contain data about one thing (book, journal, etc.) and that attributes are stored in the right table.

If in the future it creates performance problems you can de-normalise it into less tables, but this is unlikely to be a problem unless you have a huge database.

Create one table that will hold the common attributes for all references.

Create separate tables to hold the attributes that are specific to each type of reference.

The other issue is whether you will have many references to a single work,e.g. hundreds of references to a particular journal. Normalisation would then suggest you have a table that holds the journals (title, author,journal), a table that holds the reference information that is specific to journals (article, page), and another table that holds data that is common to all references (date of reference, type of reference).

Answer 2

What I've ended up doing in the past is using sub-categories: having a single table with all common fields inside it, and then several tables which can have a zero-or-one relationship to the "core" table.

The example below is similar to something we use "in the wild"; it basically builds a hierarchical data structure, where each node may be a folder or document:

CREATE TABLE Node (
  Id int identity primary key,
  ParentId int null references Node.ParentId,
  Name varchar(50) not null,
  Description varchar(max) null
)

CREATE TABLE Doc (
  Id int primary key references Node.Id,
  FileExtension char(3) not null,
  MimeType varchar(50) not null,
  ContentLength bigint not null,
  FilePathOnDisk varchar(255)
)

CREATE TABLE Folder (
  Id int primary key references Node.Id,
  ReadOnly bit not null
)

So your GetFolder sproc will do:

SELECT n.Id, n.ParentId, n.Name, n.Description, f.ReadOnly
FROM Node n 
JOIN Folder f ON n.Id = f.Id
WHERE f.Id = @Id

This translates quite nicely into class-based inheritance:

public class Folder : Node
{
  public bool IsReadOnly { get; set; }
  ...etc
}

Answer 3

Olavk makes good points, and Corey gives a great detailed explanation. Reading Corey's info, though, gives me a conclusion of Olavk's answer. Keep in mind that depending on what you're doing with the information, you may end up 2-staging your query. Find the item, then for each reference, do a direct select on what was of interest.

Also consider the idea of storing everything in multiple tables and reading it from a single table. I do this for a large database I have where most of the queries need certain common information, but the full multiple table layout is still required. The inserts are slowed down a little by the triggers that they kick off (in my case, one per file where each file is responsible for up to a million rows inserted), but my later select queries can go from minutes to single digit seconds.

Data warehousing :)