Forums PostgreSQL.fr

Jiff

Membre

Question design

Salut forumers,
.
Question sur le design d'une table contenant des n° de série.
.
Étant donné les contraintes (notamment une traçabilité totale), J'aurais tendance à penser que mon design n'est pas mauvais; cependant entre lectures et questions, j'ai appris que SQL comporte des virages parfois dangereux et que "ma logique" n'était souvent qu'une mauvaise conseillère
.
Mon design:

CREATE TABLE item.serialnb (				
  id               BIGSERIAL   NOT NULL       PRIMARY KEY,	
  ri_item          INTEGER     NOT NULL       REFERENCES item.item(id) ON DELETE RESTRICT,
  ri_stock_place   INTEGER     DEFAULT NULL   REFERENCES item.stock_place(id) ON DELETE RESTRICT DEFERRABLE INITIALLY DEFERRED,
  serialnb         DA_SN       DEFAULT NULL,	
  qty              DN_QTY      DEFAULT 1.0,	
  output           BOOLEAN     NOT NULL       DEFAULT FALSE,	
  consumption      BOOLEAN     NOT NULL       DEFAULT FALSE,	
  ri_comnoml       INTEGER     DEFAULT NULL   REFERENCES item.comnoml(id) ON DELETE RESTRICT,
  ri_sup_dlol      BIGINT      DEFAULT NULL   REFERENCES supplier.dlol(id) ON DELETE RESTRICT DEFERRABLE INITIALLY DEFERRED,
  ri_sup_invl	   BIGINT      DEFAULT NULL   REFERENCES supplier.invl(id) ON DELETE RESTRICT,
  ri_sup_rmal      BIGINT      DEFAULT NULL   REFERENCES supplier.rmal(id) ON DELETE RESTRICT,
  ri_sup_cdnl      BIGINT      DEFAULT NULL   REFERENCES supplier.cdnl(id) ON DELETE RESTRICT,
  ri_cli_prel      BIGINT      DEFAULT NULL   REFERENCES client.prel(id) ON DELETE RESTRICT,
  ri_cli_fabl      BIGINT      DEFAULT NULL   REFERENCES client.fabl(id) ON DELETE RESTRICT,
  ri_cli_dlol      BIGINT      DEFAULT NULL   REFERENCES client.dlol(id) ON DELETE RESTRICT,
  ri_cli_invl      BIGINT      DEFAULT NULL   REFERENCES client.invl(id) ON DELETE RESTRICT,
  ri_cli_rmal      BIGINT      DEFAULT NULL   REFERENCES client.rmal(id) ON DELETE RESTRICT,
  ri_cli_excl      BIGINT      DEFAULT NULL   REFERENCES client.excl(id) ON DELETE RESTRICT,
  ri_cli_cdnl      BIGINT      DEFAULT NULL   REFERENCES client.cdnl(id) ON DELETE RESTRICT,
  ri_serialnb      BIGINT      DEFAULT NULL   REFERENCES item.serialnb(id) ON DELETE RESTRICT,
  LIKE tpl_table_footer INCLUDING DEFAULTS				
) WITH (OIDS=FALSE, FILLFACTOR=70);


NB: Toutes les colonnes sont indexées, avec séparation TRUE/FALSE pour les indexes des BOOLEAN
(qui seront Tpeu utilisés et correspondent aux sorties de stock (Galmt démarque) et consommation
interne.

Normalement, je n'aurais du chaîner qu'avec un seul doc fournisseur (dlo: delivery order: bon de réception, soit le premier de la chaîne) puis, lors d'une recherche, faire le chemin inverse pour retrouver tous les autres types de docs (mais au prix d'un nombre élevé de requêtes et join) et pareil pour les clients.
C'est donc une dérogation au modèle standard, mais qui me parait permettre de gagner beaucoup en terme de requêtes (et d'occupation serveur).  Est-ce bon ?
.
Second point: normalement, j'aurais du joindre les s/n aux divers docs fournisseurs et clients avec une table de liaison par type de doc
du type "type_de_doc_id---serialnb_id" (par conséquent, j'ai certaines RIs ici qui ne serviront pas et resteront donc définitivement à NULL); mais là aussi je pense gagner du temps et de l'occupation serveur en ayant tout sous la main; le tout au prix d'une occupation disque supérieure, mais qui n'a qu'une importance marginale aujourd'hui.  Sans compter le nombre d'indexes, puisque celui sur serialnb(id) serait répété à chaque table de liaison.
.
Mes impératifs sont: traçabilité totale, dont éléments de remplacement des RMA (retours matériels), d'où la self-RI, rapidité (+sieurs dizaines de milliards de rows minimum, accès à partir de n'importe quel doc fournisseur|client, reset facile en cas d'annulation|suppression de doc client, requêtes ultra-rapides lors de préparations/fabrications de commandes clients, recherches de S/N, etc.
.
Merci d'avance (PAS sur la tête!;)