Database Design - Advice - How would you do it?

Question

I have to add some functionality to a system that is already a mess and I don't want to make things worse. This shop places very little value on proper design but I do so looking for a compromise.

They want to add the ability to add file attachments to various entities in the database but the files would be stored on a file system. The entities they'd like to attach files (one to many) are, and they want every attachment accounted for in the database (pointer filename with root_mount_point a dynamic parameter. How I will keep it in sync is my next nightmare. But I'm torn on what to use for a "many" table for the one to many attachments for a Client, Account, Vendor, or Invoice.

create table client {
  client_id      char(11)   not null,
  ...
}

create table account {
  client_id      char(11)   not null,
  account_number char(22)   not null,
  ...
}

create table vendor {
  client_id      char(11)   not null,
  account_number char(22)   not null,
  vendor_number  char(15)   not null,
    ...
}

create table invoice {
  client_id      char(11)   not null,
  account_number char(22)   not null,
  vendor_number  char(15)   not null,
  invoice_number char(22)   not null,
  invoice_date   datetime   not null (yes this is part of PK)
  ...
}

Each of these is one to many as you work your way down.

I'm thinking of doing something like this for a "file_attachment" table which can be a many table for either of the four entities, depending on which columns are null. If Invoice cols are null the attachment is to vendor, etc.

create table NEW_ENTITY_ATTACHMENT {
   attach_id           char(11)   not null   (dummy key, but keeping their char 11 standard),
   attach_status_cd    char(1)    not null,   ( "A"ctive or "D"eleted ) ,etc.
   attach_status_date  datetime   not null,  (they want complete history, soft deletes, and restores)
   client_id           char(11)   not null,
   account_number      char(22),
   vendor_number       char(15),
   invoice_number      char(22),
   invoice_date        datetime,
   attachment_filename char(blah blah),
   ..
   .. 
   blah
}

So the first three columns are required, client_id required and the account, vendor, invoice optional depending on which level the attachment is stored.

Am I way off on my thinking here, should there be a many table for EACH entity (e.g. Client Attachment, Account Attachment, Vendor Attachment, Invoice Attachment? If this is the answer they don't want to hear it anyway so I'm screwed.

I don't ask many questions but GREATLY appreciate any suggestions. Keep in mind this client just wants it done they consider this a one to two day project including data model, GUI, and backend. It's Sybase ASE15 if it matters.

Thanks in advance. R

Answer 1

Given the key structures of the other tables, putting all your attachments in one table makes sense. For example, you'll be able to query all the attachments that belong to a client (at all levels) by selecting on just client_id, and attachments that belong to a client (at just that level) by selecting on client_id and account_number IS NULL.

The one problem I see is the key for your new table:
Using a date as part of a key (attach_status_date) makes me uncomfortable (and it obviously makes you uncomfortable too based on your comment about invoice_date).

Is the attach_id going to be unique? If not, then even with attach_status_date as part of your key you may not get a unique key. If it is going to be unique (A GUID maybe?) then having attach_status_date as part of the key doesn't seem necessary especially since it doesn't look like you will be linking to this field. Maybe it should just be indexed?

Answer 2

It appears you have missed some normalization steps. You should look at whether the column introduced on each child uniquely identifies the entity. Then use a foreign key to the parent. Vendor is typically a strong table and not the child of another table.

The attachment table should probably be standalone table. Add a nullable attachment_id to each entity which may have an attachment. If the entity may have multiple attachments, then use a many-to-many relationship table instead of a column.