Conception de table de base de données

Question

Je conçois les tables comme ci-dessous pour le système
qui ressemble à un système de livraison de paquets.

Par exemple, après que l'utilisateur a reçu le paquet, postier doit enregistrer dans le système,
et l'état (tableau historique) est « livré », et l'opérateur est ce facteur,
l'état actuel (table d'état) est de bien sûr « livré »

history table: 
+---------------+--------------------------+ 
| Field  |  Desc    | 
+---------------+--------------------------+ 
| id   | PRIMARY KEY   | 
+---------------+--------------------------+ 
| package_id | package_tacking_id | 
+---------------+--------------------------+ 
| state  |  package_state  | 
+---------------+--------------------------+  
| operators | operators    | 
+---------------+--------------------------+ 
| create_time| create_time   | 
+---------------+--------------------------+ 

state table: 
+---------------+--------------------------+ 
| Field  |  Desc    | 
+---------------+--------------------------+ 
| id   | PRIMARY KEY   | 
+---------------+--------------------------+ 
| package_id | package_tacking_id | 
+---------------+--------------------------+ 
| state  | latest_package_state | 
+---------------+--------------------------+ 

au-dessus est juste les informations de base pour enregistrer, d'autres informations (comme
facture, destination, ...) doivent être enregistrées aussi bien.
Mais il existe différents types de services tels que s1 et s2, s1 il n'est pas nécessaire
pour enregistrer la facture, mais s1 besoin, et peut-être s1 besoin d'autres informations pour enregistrer
(comme tel de l'utilisateur final). Après tout, à la livraison des stations de chemin, il y a des informations supplémentaires à enregistrer,
et pour différents types de services, le type d'information est différent.

Mes questions:

1. Pour différents types de service, aurais-je besoin de déclarer différentes tables (option A) ou tout simplement
   une grande table qui permet d'enregistrer toutes les informations pour tous les types (option B)?
2. Si l'option A, étant donné que l'information de base ci-dessus est DOIT, comment
   peut empêcher de déclarer qu'il y a des champs dupliqués dans des tables différentes?

Answer 1

Je n'ai aucune réponse terminée pour votre problème, mais vous pouvez essayer modèle d'héritage dans la conception de la table.

Service Table(service) : used to put common or not-null columns in all kinds of services. 
sv_id - internal key(PK) 
sv_data_1, sv_data_2, ... 

Service 1 Table : dedicated attributes to service 1 and 'inherited from service'. 
sv1_id - internal key(PK) and foreign key to service(sv_id) 
sv1_data_1, sv1_data_2, ... 

Et ainsi de suite à autre table de service dédié ...

1. Pour plus de commodité (et les performances), l'ajout d'une colonne 'sv_type' pour représenter la 'table sous-type' exacte de servcie si vous avez besoin d'énumérer toutes sortes de services.
2. Sinon, utilisez simplement 'jointure interne' pour obtenir le type de service spécifique.

Bien que nous devions utiliser 'join' pour obtenir tous les attributs d'un type spécifique de service, mais le schéma montré construirait la solution 'null-free' pour votre problème.

Si vous vous souciez du problème de performance, il y a une chose positive: joindre des tables pour un type spécifique de service est accompli avec deux clés primaires. Pour en savoir plus sur les performances, vous pouvez créer des tables mises en cache avec des tables de base jointes lorsque vous avez besoin d'une requête plus rapide et ne vous souciez pas du problème d'erreur nulle et de type erreur des services.