Database Design - Conseils - Comment voulez-vous faire?

Question

Je dois ajouter des fonctionnalités à un système qui est déjà un gâchis et je ne veux pas faire empirer les choses. Cette boutique des endroits très peu de valeur sur la conception proprement dite, mais je ne recherche donc un compromis.

Ils veulent ajouter la possibilité d'ajouter des pièces jointes à différentes entités dans la base de données, mais les fichiers seront stockés sur un système de fichiers. Les entités qu'ils aimeraient joindre des fichiers (un à plusieurs) sont, et ils veulent toutes les pièces jointes pris en compte dans la base de données (nom de fichier pointeur avec root_mount_point un paramètre dynamique. Comment je le synchroniser est mon prochain cauchemar. Mais je m déchiré sur ce qu'il faut utiliser pour un « plusieurs » table pour une à plusieurs pièces jointes pour un client, compte, vendeur ou de la facture.

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)
  ...
}

Chacun d'eux est un à plusieurs que vous travaillez votre chemin vers le bas.

Je pense à faire quelque chose comme ça pour une table « file_attachment » qui peut être une table pour beaucoup l'une des quatre entités, selon les colonnes sont nulles. Si facture sont nuls Col. la pièce jointe est au fournisseur, 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
}

Ainsi, les trois premières colonnes sont nécessaires, CLIENT_ID requis et le compte, le vendeur, la facture en option en fonction de quel niveau la pièce jointe est enregistrée.

Suis-je loin de ma pensée ici, devrait-il y avoir un grand nombre table pour chaque entité (par exemple attachement client, pièce jointe de compte, pièce jointe fournisseur, facture jointe? Si cela est la réponse qu'ils ne veulent pas l'entendre de toute façon Je suis foutue.

Je ne demande pas beaucoup de questions, mais RÉJOUISSENT des suggestions. Gardez à l'esprit ce client veut juste faire ce qu'ils considèrent comme un à deux projets de jour y compris le modèle de données, l'interface graphique et back-end. Il est Sybase ASE15 si elle compte.

Merci d'avance. R

Answer 1

Compte tenu des structures clés des autres tables, mettre tous vos pièces jointes dans une table est logique. Par exemple, vous serez en mesure d'interroger toutes les pièces jointes qui appartiennent à un client (à tous les niveaux) en sélectionnant uniquement sur client_id, et les pièces jointes qui appartiennent à un client (juste à ce niveau) en sélectionnant sur client_id et ACCOUNT_NUMBER IS NULL .

Le seul problème que je vois est la clé de votre nouvelle table:
En utilisant une date dans le cadre d'une clé (attach_status_date) me rend mal à l'aise (et il vous rend mal à l'aise de toute évidence trop basé sur vos commentaires sur INVOICE_DATE).

est le attach_id va être unique? Sinon, même avec attach_status_date dans le cadre de votre clé, vous ne pouvez pas obtenir une clé unique. Si cela va être unique (GUID peut-être?) Puis d'avoir attach_status_date dans le cadre de la clé ne semble pas particulièrement nécessaire car il ne semble pas que vous serez liez à ce domaine. Peut-être qu'il devrait juste être indexé?

Answer 2

Il semble que vous avez manqué quelques pas de normalisation. Vous devriez regarder si la colonne introduit sur chaque enfant identifie de manière unique l'entité. Ensuite, utilisez une clé étrangère à la société mère. Fournisseur est généralement une table forte et non l'enfant d'une autre table.

Le tableau de fixation devrait probablement être autonome tableau. Ajouter un attachment_id annulable à chaque entité qui peut avoir une pièce jointe. Si l'entité peut avoir plusieurs pièces jointes, puis d'utiliser un grand nombre à plusieurs table de relation au lieu d'une colonne.