MS SQL Server
  1. MS SQL Server
  3. key primaire composite vs substitut
Intereting Posts
comment convertir une requête de correspondance complète de sql en ef La connection n'a pas été fermée, l'état actuel de Connection est une erreur ouverte dans la boucle foreach Se connecter à LocalDB avec le nouveau pilote ODBC pour SQL Server joindre plusieurs requêtes aboutissent à séparer les colonnes EF Code First – Timeout a expiré. Le timeout d'expiration s'est écoulé avant la fin Calculer des années de service Sélectionnez une requête avec joindre plusieurs tables dans SQL Server "Grouper par *" dans une requête SQL Server 2008? SQL Server: drop table en cascade équivalent? Trouver la valeur non-contiguë la plus basse Quel type de données doit être utilisé pour stocker les numéros de téléphone dans SQL Server 2005? Dois-je me débarrasser des index clusterisés sur les colonnes Guid? SQL Sont-ils les mêmes? Barre oblique dans le nom de colonne renvoyant une syntaxe incorrecte "/" Comment puis-je avoir une key étrangère qui pointe vers une colonne calculée?

key primaire composite vs substitut

Je suis en train de concevoir une database avec les exigences suivantes:

  • Une organisation peut exister seule
  • Une organisation peut avoir n'importe quel nombre de termes distincts (plage de dates)
  • Une organisation peut avoir un nombre quelconque de types d'enquête (étudiant, enseignant, parent, etc.)
  • Un formulaire d'enquête est associé à un terme et à un type d'enquête

Une structure pour cela pourrait être:

Organisation 

- OrganizationId INT IDENTITY(1,1) NOT NULL PRIMARY KEY

Terme 

  - TermId INT IDENTITY(1,1) NOT NULL PRIMARY KEY - OrganizationId INT NOT NULL REFERENCES Organization(OrganizationId)

SurveyType 

  - SurveyTypeId IDENTITY(1,1) NOT NULL PRIMARY KEY - OrganizationId INT NOT NULL REFERENCES Organization(OrganizationId)

SurveyForm 

  - SurveyFormId INT IDENTITY(1,1) NOT NULL PRIMARY KEY - SurveyTypeId INT NOT NULL REFERENCES SurveyType(SurveyTypeId) - TermId INT NOT NULL REFERENCES Term(TermId)

Cette structure rest avec ce qui semble être un accent populaire sur une seule key primaire de substitution. Cependant, cette structure sacrifie l'intégrité des données, car il est très facile pour un logging SurveyForm d'avoir un TermId ou SurveyTypeId provenant de différentes Organization .

Pour traiter l'intégrité des données, il semblerait que vous deviez append OrganizationId et l'utiliser dans les keys composites (OrganizationId, SurveyTypeId) et (OrganizationId, TermId) . C'est un peu tolérable dans cet exemple, mais à mesure que le schéma devient plus complet, les tailles des touches composites augmentent.

Donc ma question est, comment les gens approchent-ils généralement ceci maintenant (la plupart des references en ligne sont à partir de 2008 quand je pense qu'il était possible qu'il y avait des soucis différents de design de database)? En corollaire, quand est-il acceptable d'append des foreign keys à une table pour réduire le nombre de tables jointes pour des expressions communes?

Sur le plan académique, vous pouvez migrer la key d'organisation le long des deux lignées. C'est juste 4 octets, après tout: 

 create table dbo.Organization ( OrganizationId INT IDENTITY(1,1) PRIMARY KEY ); go create table dbo.Term ( TermId INT IDENTITY(1,1) NOT NULL, OrganizationId INT NOT NULL REFERENCES dbo.Organization(OrganizationId), primary key (OrganizationId, TermId) ); go create table dbo.SurveyType ( SurveyTypeId int IDENTITY(1,1) NOT NULL, OrganizationId INT NOT NULL REFERENCES dbo.Organization(OrganizationId), primary key (OrganizationId, SurveyTypeId) ); go create table dbo.SurveyForm ( SurveyFormId INT IDENTITY(1,1) NOT NULL, OrganizationId int not null, SurveyTypeId INT NOT NULL, TermId INT NOT NULL, primary key (OrganizationId, SurveyTypeId, TermId), foreign key (OrganizationId, TermId) references dbo.Term (OrganizationId, TermId), foreign key (OrganizationId, SurveyTypeId) references dbo.SurveyType (OrganizationId, SurveyTypeId) ); go

Ces tables violent clairement certains NFs, je ne me souviens pas lequel exactement, mais je suis sûr que vous pouvez le manipuler vous-même.

Bien que cette approche de design puisse presque être considérée comme un must pour un entrepôt (surtout si vous regroupez des données provenant de différentes sources), je ne le reorderais jamais pour un OLTP réel. Une solution beaucoup plus simple serait:

  • Effectuer toutes les modifications via une procédure stockée, qui aura des vérifications appropriées contre ce genre de divergence possible.
  • Assurez-vous qu'aucun user ne soit autorisé à append / modifier directement des données dans dbo.SurveyForm, contournant ainsi les règles métier implémentées dans le SP mentionné ci-dessus.

Je pense qu'il pourrait y avoir un moyen d'éviter les references circulaires, d'abord en définissant qui dépend réellement de qui et en supprimant les dependencies redondantes.

La question est la suivante: les Organization peuvent-elles être associées de façon random à des Term sans se préoccuper d'une association de Survey ? Je me request si les Organization doivent vraiment être associées à un Term directement ou indirectement par le biais d' Survey . Si, par exemple, une Organization ne peut pas être associée à un Term qui n'est pas associé à l' Survey l'organisation, la relation organisation-terme est inutile, si c'est l'inverse, alors l'organisation-type d'enquête n'est pas nécessaire