Question

Je développe un système transactionnel et ce qui est ci-dessous est un scénario simplifié de mon problème.

  • Les utilisateurs saisissent des travaux dans un système.
  • Un utilisateur entre d'abord dans un travail avec un projet de statut (et le travail reçoit un projet de numéro)
  • Lorsque l'utilisateur soumet le travail, le statut est modifié en sumbitted (il reçoit un numéro réel)
  • Enfin, une fois le travail terminé, le statut est modifié en affiche.

Je pensais à créer 3 tables «Job» identifiques distinctes pour cela. Lorsqu'un emploi passe d'un brouillon à l'autre, je déplace les données. C'est principalement pour des raisons de performance. La plupart des requêtes seraient sur les emplois actuels et cela garantirait que sa table ne soit pas encombrée de tous les affichés. De plus, une telle division des tableaux fournirait une amélioration de la structure car je peux utiliser le numéro de travail comme clé principale. S'il y avait une seule table, le numéro de projet devrait être changé en un numéro réel. Et les clés primaires ne devraient jamais changer.

Maintenant, ma question est - mon approche a-t-elle un sens? Est-il habituel d'avoir des tables séparées? Si quelqu'un avait de l'expérience avec cela et peut fournir des commentaires, ce serait formidable.

Pas de solution correcte

Licencié sous: CC-BY-SA avec attribution
Non affilié à dba.stackexchange
scroll top