la conception de base de données - question sur (qualité de la conception et générale) efficacité

Question

Je crains que je ne sais pas ce que je fais.

1

J'ai une table appelée ticket qui a une colonne appelée total. Lorsque le total est mis à jour je veux garder une trace de celui-ci (vieux au total, etc), donc j'ai décidé de supprimer la colonne de total et de créer une table appelée ticket_total avec des colonnes ticket_id, total et datetime (le plus récent est bien sûr la totale "courant").

ou

2

Alors je réalisais que je veux plus tard donner à mes clients la possibilité de trier les billets par total, ou des rapports de traction qui regroupent les totaux, etc. Donc, j'ai décidé au lieu de remettre la colonne total sur ticket et au changement la colonne total directement lorsque le total est mis à jour, mais d'abord créer une ligne de ticket_total comme un enregistrement de la total précédente.

Il semble que la version 2 serait très efficace parce que je ne aurais pas besoin d'interroger la table de ticket_total associée autant, mais je me demande ce que vous DB gourous là-bas pensent. Je suis juste la conception de base de données d'apprentissage et de peur que je ne vais jamais être bon.

Answer 1

Je voudrais aller avec l'option 2 que vous avez suggéré.

Assurez-vous que vous faites la mise à jour (du ticket) + Inser (en ticket_total) dans une transaction pour garantir que l'intégrité est maintenue.

Answer 2

Votre seconde alternative est plus rapide, mais si vous voulez créer des rapports sur les valeurs historiques du total, vous devriez devrait avoir une table séparée où vous stockez la valeur que vous remplacez ensemble avec un horodatage. Ce type de table est appelée une table de vérification .

Answer 3

Re: « l'efficacité » - Le mieux est de vous inquiétez pas trop sur l'efficacité de base de données au début d'un projet. L'optimisation prématurée est une erreur commune à éviter.

Mieux vaut se concentrer sur vos besoins et la conception pour eux. Par la suite, vous pouvez tester pour voir si les goulots d'étranglement de performance sont et travailler pour les résoudre.

Pour les bases de données plus petites (des dizaines de milliers de lignes), même les requêtes « inefficaces » vont souvent les serveurs d'aujourd'hui très rapide données et logiciels.

Keep it simple Je vous suggère d'éviter les clés de combinaison et la surcharge sémantique de table, sauf si vous avez vraiment besoin.

Proposition Vous avez deux types de données:. Renseignements sur les billets en cours, et une table d'historique pour les vieilles valeurs "totales"

Ainsi, votre ver 2 serait préférable.

ticket
  id
  field_a
  field_b
  total    # current_total

ticket_total  # history of ticket total field
  id
  ticket_id
  total
  create_time

aussi sons "total" comme une agrégation de quelque chose. Je suggère que vous essayez de trouver un nom de domaine qui est plus descriptif. - Quel est le champ total? "Total_worktime"?

Ajouté N'oubliez pas d'ajouter des index pour les tables. Index par tout ce que vous utilisez pour les découvertes. Par exemple, la table ne de billets ont une customer_id? Assurez-vous qu'il est indexé.

Answer 4

Je voudrais faire ticket_total une vue, pas une table. Je voudrais créer une autre vue ticket_current où je filtrer les billets par la dernière date qui est si la table de billets est double calée sur TICKET_ID et datetime. Dans le cas contraire, ignorer cette dernière partie.