Comment Créer un véritable one-to-one relation dans SQL Server

J'ai deux tables tableA et tableB, j'ai mis tableB's de la clé primaire comme clé étrangère qui référence tableAprincipal. Mais quand j'utilise Entity Framework de base de données tout d'abord, le modèle est de 1 à 0..1.

Comment créer un one-to-one relation dans SQL Server?

  • Dans la pratique. Qui a besoin d'un "vrai" one-to-one relation? une relation de type 1 à 0..1 est Ok et plus de naturel et pratique. C'est comme l'ajout d'une colonne nullable à une table existante. Il suffit de faire une clé étrangère unique.
InformationsquelleAutor James | 2012-04-24
  1. 54

    Je suis sûr que c'est techniquement impossible dans SQL Server pour avoir un Vrai 1 pour 1 relation, cela signifierait que vous auriez ont pour insérer des enregistrements dans le même temps (sinon, vous obtiendrez une erreur de contrainte lors de l'insertion), dans les deux tables, avec deux tables ayant une relation de clé étrangère les uns des autres.

    Cela étant dit, votre conception de base de données décrit avec une clé étrangère est un 1 à 0..1 relation. Il n'est pas possible de contraindre qui nécessiterait un enregistrement dans la tableB. Vous pouvez avoir une pseudo-relation avec un déclencheur qui crée l'enregistrement dans la tableB.

    Il y a donc quelques pseudo-solutions

    Tout d'abord, le stockage de toutes les données dans une table unique. Ensuite, vous n'aurez pas de problèmes en EF.

    Ou, Deuxièmement, votre entité doit être assez intelligent pour ne pas permettre une insertion, sauf s'il est associé à un dossier.

    Ou, troisièmement, et le plus probable, vous avez un problème que vous essayez de résoudre, et vous nous demandez pourquoi votre solution ne fonctionne pas de la place du vrai problème que vous essayez de résoudre (XY Problème).

    Mise à JOUR

    À expliquer dans RÉALITÉ comment 1 à 1 les relations ne sont pas de travail, je vais utiliser l'analogie de la Poule ou de l'oeuf dilemme. Je n'ai pas l'intention de résoudre ce dilemme, mais si vous avez une contrainte qui dit afin d'ajouter un Œuf à l'Œuf de la table, la relation de la poule doit exister, et que le poulet doit exister dans la table, alors vous ne pouvez pas ajouter un Œuf à l'Œuf de la table. L'inverse est également vrai. Vous ne pouvez pas ajouter le Poulet et le Poulet de la table sans la relation à l'œuf et l'Œuf existant dans les Œufs de table. Donc pas de dossiers, qui peuvent être tout fait, dans une base de données sans rupture de l'une des règles/contraintes.

    Base de données nomenclature d'un one-to-one relation est trompeuse. Toutes les relations que j'ai vu (donc mon expérience) serait plus descriptif que l'un-à-(zéro ou un) relations.

    • "...cela signifierait que vous auriez à insérer des enregistrements dans le même temps" afin de "un à plusieurs" de la relation signifie que vous devez insérer tous les dossiers en même temps?
    • Non, parce qu'un un-à-plusieurs est en fait 1 à 0..(x). Il n'y a pas encore de disposer de tous les enregistrements dans la relation. 😀 (c'est précisément au sujet de comment EF décrit les relations, pas moi)
    • Aussi loin que je me souviens de mon université de fois (et c'était il y a bien longtemps 🙂 il ya une telle chose comme une relation dans la relation de la base de données de la théorie. Encore, je me trompe peut-être et encore il n'y a pas de façon explicite un-à-un les relations dans sql-server. Désolé, ce qui est EF?
    • Entity Framework
    • "Je suis sûr que c'est techniquement impossible dans SQL Server" -- êtes-vous sûr? Astuce: les contraintes pourraient être appliquées et les données gérées à l'aide du code de procédure (stockées procs, déclencheurs).
    • est une chose telle que le one-to-one relation dans le rapport de base de la théorie" -- si vous acceptez que de telles relations existent dans la réalité, alors nous avons besoin d'un moyen de modélisation (et si nos systèmes de base de données ne peut pas gérer leur bien alors nous devrions être en exigeant de nouveaux systèmes d'!) Chris Date a écrit une courte mais complète de papier sur le sujet de la nature des relations et justifie un classement des 10 types de relation: " Tous Pour Un, Un Pour Tous.
    • J'ai indiqué par exemple de 1 à 1 peut exister à l'aide de déclencheurs (ou de toute proc, qui peut même désactiver une contrainte, et puis l'activer), mais si vous devez désactiver une contrainte pour ajouter une ligne, vous êtes en contournant l'ensemble de l'intention de la contrainte dans la première place. Et s'il vous PLAÎT cesser de commenter sur la base de la théorie, je vais essayer d'expliquer comment cela fonctionne RÉELLEMENT, en particulier en ce qui concerne l'Entity Framework.
    • Votre answare n'est pas totalement vrai. Dans SQL SERVER, vous pouvez créer un 1-de-1 de la relation à l'aide seulement de clé primaire pour FK et un Index Unique sur les mêmes colonnes.
    • C'est un terme appelé 1-pour-1 cependant, il est techniquement de 1 à 0..1 ET en EF c' va générer une de 1 à 0..1 relation.

    InformationsquelleAutor Erik Philips
  2. 59

    Définir la clé étrangère comme clé primaire, puis définissez la relation sur les deux champs de clé primaire. Ça y est! Vous devriez voir une touche de signe sur les deux extrémités de la ligne de relation. Cela représente un à un.

    Comment Créer un véritable one-to-one relation dans SQL Server

    Vérifier : SQL Server Base de données de Conception avec une Relation

    • Cela donnera un 1 à 0..1 relation en EF.
    • Comment pouvons-nous parvenir par écrit une requête sans l'aide de diagrammes?
    • Que voulez-vous dire, par l'écriture d'une requête? Voulez-vous dire, comment puis-je créer deux tables avec la relation Pranay décrit en T-SQL?
    • oui je voulais dire que.
    • Puisque vous la question n'est pas liée à l'OP question, je vous recommande fortement de demander simplement en tant que nouvelle question (si vous ne l'avez pas déjà). Vous pouvez même inclure la même image.
    • Pourrait user_pers_id ont un même nom que pers_id? Est-il un réel besoin de se différencier des noms de colonne?
    • Donc, la raison n'est qu'un one-to-one relation, c'est que le champ de clé étrangère est aussi le champ de clé primaire -- donc il ne peut avoir ensemble particulier de valeurs (prévention de l'un-à-plusieurs): constraint PK_user1 primary key (user_pers_id), constraint FK_user1 foreign key (user_pers_id) references person(pers_id)
    • En fait, il n'y a pas de réel besoin d'utiliser la colonne de Clé Primaire d'une contrainte de Clé Étrangère pour atteindre 1 à 0..1 relation. La seule chose qui importe, c'est une contrainte UNIQUE sur la colonne de Clé Étrangère dans la seconde table. Btw, PK est toujours unique.
    • pour donner un exemple, oui, votre suggestion doit produire les mêmes résultats. Ainsi CONSTRAINT UQ_user__user_pers_id UNIQUE (user_pers_id) & CONSTRAINT FK_user__user_pers_id REFERENCES person(pers_id) doit être fonctionnellement égal à CONSTRAINT PK_user__user_pers_id PRIMARY KEY (user_pers_id) & CONSTRAINT FK_user__user_pers_id REFERENCES person(pers_id).
    • Parfait! une grande Aide, je cherchais quelque chose comme ça!

    InformationsquelleAutor Pranay Rana
  3. 23

    Cela peut être fait par la création d'une simple primaire clé étrangère de la relation et le réglage de la colonne de clé étrangère à l'unique de la manière suivante:

    CREATE TABLE [Employee] (
    [ID]    INT PRIMARY KEY
,   [Name]  VARCHAR(50)
);

CREATE TABLE [Salary] (
    [EmployeeID]    INT UNIQUE NOT NULL
,   [SalaryAmount]  INT 
);

ALTER TABLE [Salary]
ADD CONSTRAINT FK_Salary_Employee FOREIGN KEY([EmployeeID]) 
    REFERENCES [Employee]([ID]);

    Comment Créer un véritable one-to-one relation dans SQL Server

    INSERT INTO [Employee] (
    [ID]
,   [Name]
)
VALUES
    (1, 'Ram')
,   (2, 'Rahim')
,   (3, 'Pankaj')
,   (4, 'Mohan');

INSERT INTO [Salary] (
    [EmployeeID]
,   [SalaryAmount]
)
VALUES
    (1, 2000)
,   (2, 3000)
,   (3, 2500)
,   (4, 3000);

    Vérifier pour voir si tout va bien

    SELECT * FROM [Employee];
SELECT * FROM [Salary];

    Maintenant Généralement dans le Primaire Étrangères Relation (Un à plusieurs),
    vous pouvez entrer plusieurs fois EmployeeID,
    mais ici, une erreur sera levée

    INSERT INTO [Salary] (
    [EmployeeID]
,   [SalaryAmount]
)
VALUES
    (1, 3000);

    La déclaration ci-dessus va afficher le message d'erreur que

    Violation de la contrainte de CLÉ UNIQUE 'UQ__Salaire__7AD04FF0C044141D'.
    Impossible d'insérer une clé en double dans l'objet 'dbo.Salaire'. La valeur de clé en double est (1).

    • Cela donnera un 1 à 0..1 relation dans le Cadre de l'Entité. Vous avez créé un Employé sans Salaire déjà présents.
    • Je suis un Peu curieux sur ce dernier exemple. Si l'on vient d'ajouter le Salaire d'un objet dans la classe d'Employés, vais-je, sans plus de faire, en EF, juste être en mesure de dire dans le code: var salaire = Employé(Id).Salaire???
    • Indépendamment de l'EF - peut créer un Employé tous les jours sans salaire. C'est 1 à 0..1
    • Cela suppose d'être vérifié comme la MEILLEURE réponse! J'ai en œuvre exactement ce que @ashim a dit, j'en ai Une à Une relation de créer sur mon Serveur SQL MME Merci beaucoup!!!!
    InformationsquelleAutor ashim
  4. 4

    Il ya une façon que je sais comment réaliser un effet strictement* one-to-one relation sans l'aide de déclencheurs, des colonnes calculées, des tableaux supplémentaires, ou d'autres "exotique" de tours (seulement les clés étrangères et les contraintes unique), avec une petite mise en garde.

    Je vais emprunter le poulet et les œufs de la notion de la accepté de répondre pour m'aider à expliquer la mise en garde.

    Il est un fait que ce soit un poulet ou un oeuf doit venir en premier à la DBs courant de toute façon). Heureusement, cette solution ne permet pas d'obtenir de politique et de ne pas prescrire ce qui doit venir en premier - il laisse le maître d'œuvre.

    Le problème, c'est que la table qui permet un enregistrement de "venir en premier' techniquement, peuvent avoir un dossier créé sans l'enregistrement correspondant dans l'autre table; cependant, dans cette solution, un seul enregistrement est autorisé. Lorsqu'un enregistrement est créé (uniquement du poulet ou des oeufs), pas plus que les enregistrements puissent être ajouté à l'une des deux tables jusqu'à ce que le 'seul' enregistrement est supprimé ou un enregistrement correspondant est créé dans l'autre table.

    Solution:

    Ajouter des clés étrangères pour chaque table, la référence à l'autre, d'ajouter des contraintes uniques pour chaque clé étrangère, et d'en faire une clé étrangère nullable, l'autre pas les valeurs null et aussi une clé primaire. Pour que cela fonctionne, l'unique contraindre sur la colonne nullable ne doit permettre qu'un nul (c'est le cas dans SQL Server, vous ne savez pas sur d'autres bases de données).

    CREATE TABLE dbo.Egg (
    ID int identity(1,1) not null,
    Chicken int null,
    CONSTRAINT [PK_Egg] PRIMARY KEY CLUSTERED ([ID] ASC) ON [PRIMARY]
) ON [PRIMARY]
GO
CREATE TABLE dbo.Chicken (
    Egg int not null,
    CONSTRAINT [PK_Chicken] PRIMARY KEY CLUSTERED ([Egg] ASC) ON [PRIMARY]
) ON [PRIMARY]
GO
ALTER TABLE dbo.Egg  WITH NOCHECK ADD  CONSTRAINT [FK_Egg_Chicken] FOREIGN KEY([Chicken]) REFERENCES [dbo].[Chicken] ([Egg])
GO
ALTER TABLE dbo.Chicken  WITH NOCHECK ADD  CONSTRAINT [FK_Chicken_Egg] FOREIGN KEY([Egg]) REFERENCES [dbo].[Egg] ([ID])
GO
ALTER TABLE dbo.Egg WITH NOCHECK ADD CONSTRAINT [UQ_Egg_Chicken] UNIQUE([Chicken])
GO
ALTER TABLE dbo.Chicken WITH NOCHECK ADD CONSTRAINT [UQ_Chicken_Egg] UNIQUE([Egg])
GO

    À insérer, d'abord un œuf doit être inséré (avec la valeur null pour le Poulet). Aujourd'hui, le poulet peut être inséré et il doit faire référence à la "non réclamé" l'oeuf. Enfin, l'ajout d'œuf peuvent être mis à jour et il doit faire référence à la "non réclamé" le poulet. En aucun point, deux poulets être fait référence à la même œuf ou vice-versa.

    À supprimer, la même logique peut être suivi: mise à jour des œufs de Poulet à la valeur null, supprimer le nouveau "non réclamé" de poulet, de supprimer l'œuf.

    Cette solution permet également de permutation facilement. Fait intéressant, l'échange pourrait être l'argument le plus fort pour l'utilisation d'une telle solution, car il a un potentiel d'utilisation pratique. Normalement, dans la plupart des cas, un one-to-one relation de deux tables est mieux mis en œuvre par simplement refactoring les deux tables en une seule; toutefois, dans un scénario possible, les deux tables peuvent représenter réellement des entités distinctes, qui exigent une stricte one-to-one relation, mais il faut souvent swap "partenaires" ou être réorganisés en général, tout en conservant le one-to-one relation après la ré-arrangement. Si la plus commune de la solution ont été utilisés, toutes les colonnes de données de l'une des entités devraient être mises à jour ou remplacées pour toutes les paires de re-arrangé, par opposition à cette solution, où une seule colonne de clés étrangères besoin d'être ré-arrangé (le nullable colonne de clé étrangère).

    Bien, c'est le meilleur que j'ai pu faire à l'aide de la norme contraintes (ne pas juger 🙂 Peut-être que quelqu'un va trouver utile.

    • Cela donnera un 1 à 0..1 relation dans le Cadre de l'Entité.
    • Bien sûr, dans d'autres SQL Serveurs de bases de données comme Oracle ou PostgreSQL, cela ne peut en fait correctement avec reportable contraintes qui sont vérifiés lorsque la transaction est validée, pas quand la ligne est insérée, permettant ainsi d'éviter le dilemme de la poule et de l'oeuf problème. Étonnamment, MS a ignoré cette partie de la norme SQL-92, qui est maintenant âgé de 25 ans.
    • Un autre plus long terme sur la façon d'obtenir de vrais 1:1 relations dans MS SQL Server est par le vote de cette élément de connexion: connect.microsoft.com/SQLServer/feedback/details/124728/...
    • De toute façon - je vous remercie pour cette réponse - il semble que la meilleure façon de contourner pour ma base de données. Apprécié
    InformationsquelleAutor tomosius
  5. 1

    1 À 1 Relations dans SQL sont faites par la fusion du champ de la table dans une !

    Je sais que vous pouvez diviser un Tableau en deux entité avec un 1 à 1 de rapport. La plupart du temps vous utilisez ce parce que vous voulez utiliser lazy loading sur "lourd champ de données binaires dans un tableau".

    Exemple: Vous disposez d'une table contenant des images avec une colonne de nom (chaîne de caractères), peut-être certains de la colonne de métadonnées, une miniature de la colonne et de l'image elle-même varbinary(max). Dans votre application, vous aurez certainement s'affichent en premier, seulement le nom et la miniature dans un contrôle de collecte puis de charger le "tableau complet des données" seulement si nécessaire.

    Si c'est ce que vous cherchez. C'est quelque chose appelée "table de fendage" ou "le découpage horizontal".

    https://visualstudiomagazine.com/articles/2014/09/01/splitting-tables.aspx

    • Cela donnera un 1 à 0..1 relation dans le Cadre de l'Entité.
    InformationsquelleAutor Marco Guignard
  6. 0

    La façon la plus simple d'y parvenir est de créer seulement 1 table avec Table et les champs B NON NULS. De cette façon, il est impossible d'avoir l'un sans l'autre.

    • Cela donnera un 1 à 0..1 relation dans le Cadre de l'Entité.
    • c'est OK. Qui vous a dit que EF est correct à 100%?
    InformationsquelleAutor Jonathan Nappee
  7. 0

    Quoi à ce sujet ?

    create table dbo.[Address]
(
Id int identity not null,
City nvarchar(255) not null,
Street nvarchar(255) not null,
CONSTRAINT PK_Address PRIMARY KEY (Id)
)

create table dbo.[Person]
(
Id int identity not null,
AddressId int not null,
FirstName nvarchar(255) not null,
LastName nvarchar(255) not null,
CONSTRAINT PK_Person PRIMARY KEY (Id),
CONSTRAINT FK_Person_Address FOREIGN KEY (AddressId) REFERENCES dbo.[Address] (Id)
)
    • Est-ce lui poser une question ou proposer une réponse? C'est clairement un cas décrit dans d'autres réponses que de 1:0-ou-1. En fait, c'est le même insuffisante code comme décrit dans la question. Pourquoi est-ce qui ne ressort pas de toute façon? Vous pouvez avoir une adresse en ligne avec aucune personne ligne.
    • vous avez raison, je ne savais pas que la création d'adresses supplémentaires est un problème.
    • Si vous ne réalisez pas cela, je me demande ce que vous avez pensé la question était de savoir? "1:1" (Avez-vous lu toutes les réponses & commentaires?) PS Vous pouvez supprimer ce avant qu'il ne se downvoted. Qui peuvent influer sur votre permis de poster taux, si plus tard supprimé ou non. Cela mérite downvoting mais je n'ai pas parce que je suis arrivé ici par le biais de votre profil pour étudier la question de la qualité.
    • En SQL, j'ai toujours pensé que 1:1, mais je n'ai pas essayé en EF, où cette relation est traitée différemment. Je vais essayer de mieux la prochaine fois.
    • Ce n'est pas 1:1 en SQL, la table référencée peut avoir non référencées lignes. L'EF est reflétant le SQL. Et la question est à propos de SQL. Lire la question, les réponses & commentaires.
    • Dans ce code il y a peut être des adresses que personne ne l'a fait. Vous décrivez 1:0-ou-1. Je n'ai aucune idée de ce que vous voulez dire par "n'a pas d'importance" phrase de départ "point de vue". 1:1 dans la question des moyens contrained comme SQL PK FKs les uns aux autres. Encore une fois: la Lecture de la question, les réponses & commentaires. Etc.
    • Je ne sais pas comment il peut être 1-0 (même avec des non référencées adresses des enregistrements) mais je vais le laisser comme ça. Merci pour vos commentaires.
    • Si une adresse a un ou pas de personne & une personne a une adresse ensuite à l'adresse:personne 1:(0 ou 1) la relation. Bye.
    • Me semble étrange de définir une relation entre l'adresse et la personne lorsque l'adresse n'a pas de dossier de référence de la personne. C'est probablement source de confusion, je reçois votre point de maintenant.
    • Approches de la cardinalité peut être divisé en deux approches: pour décrire un n-aire relation/table vs décrivant l'un de ces plus les tables à colonne unique à partir de laquelle les valeurs sont tirées. (Aussi le schéma de la ligne de labels dans les 2 camps, regardez-ici & regardez-là.) Ceci est similaire pour les 2 approches de la fonction de la cardinalité--décrivant un ensemble de paires clé-valeur vs décrivant l'un de ces plus des ensembles de touches & les valeurs sont tirées & à l'égard de laquelle une fonction peut être totale ou partielle. (Les termes "domaine", "plage" & "co-domaine" n'ont même pas de sens normalisé & chaque présentation a pour clarifier son utilisation.)

    InformationsquelleAutor Muflix