Home/ Questions/Q 4085882
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-20T18:38:45+00:00

I have to add some functionality to a system that is already a mess

  • 0

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

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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?

    • 0