Touches étrangères multiples mais mutuellement exclusives - est-ce la voie à suivre?

Un peu en retard, mais toutes les réponses existantes semblaient tomber un peu à cause de la marque:

• propriétaire du site Web est un 1: beaucoup code> relation li>
• Site Web au propriétaire est un 1: 1 code> relation li>
• Les tables des utilisateurs et des entreprises ne doivent pas avoir une clé étrangère dans la table des sites Web LI>
• Aucune des données de site Web, communes aux utilisateurs et aux entreprises ou non, devrait être dans les tableaux d'utilisateurs ou de sociétés li>
• Aucune information du propriétaire, commune ou non, devrait être dans la table des sites Web li>
• mysql ignore, silencieusement, vérifier code> des contraintes sur les tables (aucune application de l'intégrité référentielle) li>
• Le SGBD doit gérer la logique "Relation", pas l'application à l'aide de la base de données li> ul>

  Une partie de celle-ci est reconnue dans le Réponse de Onedaywhen , mais que La réponse a toujours manqué l'occasion de rendre MySQL faire la forte levée et d'appliquer l'intégrité référentielle. p>

  ---

  Un site Web ne peut avoir qu'un propriétaire, légalement, de toute façon. Une personne ou une entreprise, peut avoir un nombre quelconque de sites Web, y compris aucun. Un lien dans la base de données du propriétaire du site Web ne peut être que 1: 1 code> à n'importe quel niveau de normalisation. En réalité, la relation est 1: beaucoup code> et nécessiterait de disposer d'entrées de table multiples pour chaque propriétaire qui s'appuie sur plusieurs sites Web. Un lien du site Web au propriétaire est 1: 1 code> dans les deux termes de la base de données et en réalité. Avoir le lien du site Web au propriétaire représente le modèle mieux. Avec un index dans la table du site Web, faire le 1: nombre code> pour un propriétaire donné devient raisonnablement efficace. P>

  L'attribut cocher code> dans SQL serait Une excellente solution, si MySQL n'était pas arrivée à l'ignorer silencieusement. P>

  MySQL Docs 13.1.20 Créer une syntaxe de table SUB> P>

  La clause cocher code> est analysée mais ignorée par tous les moteurs de stockage. P> blockQuote>

  La fonctionnalité de MySQL offre deux solutions comme des contours pour mettre en œuvre le comportement de vérifier code> et conserver l'intégrité référentielle des données. Les déclencheurs avec des procédures stockées en sont une et fonctionne bien avec toutes sortes de contraintes. Plus facile à mettre en œuvre, bien que moins polyvalent, utilise une vue code> avec un avec l'option de contrôle code>, que mysql sera em> mise en œuvre. P> MYSQL DOCS 24.5.4 Vue avec option de contrôle Clause SUB> P>

  Le avec l'option de contrôle code> peut être donné pour une vue mise à jour pour empêcher les insertions des lignes pour lesquelles la clause où code> dans le select_statement code> em> n'est pas vrai. Il empêche également les mises à jour des lignes pour lesquelles le où la clause code> est vrai, mais la mise à jour ne serait pas vraie (en d'autres termes, elle empêche les lignes visibles d'être mises à jour sur des lignes non visibles). P > BlockQuote>

  Le site MySQLTutorial donne un bon exemple des deux options de leur Introduction à la contrainte de vérification SQL tutoriel. (Vous devez penser à la faute de frappe, mais bon sinon.) P>

  ---

  avoir trouvé cette question en essayant de résoudre une scission de clé étrangère mutuellement exclusive similaire et de développer une solution, avec des notes générées par les réponses. , il semble seulement de partager ma solution en retour. p>

  solution recommandée h2>

  pour l'impact minimum sur le schéma existant et l'application accédant aux données, conserver les utilisateurs code> et entreprises code> Tables tels qu'ils sont. Renommez les sites Web code> code> et remplacez-le par une vue nommée Sites Web code> que l'application peut continuer à accéder. Sauf lors de la gestion des informations de propriété, toutes les anciennes requêtes à Les sites Web CODE> doivent toujours fonctionner. Donc: P>

  la configuration h3> xxx pré>

  utilisation h3> xxx pré>

  niveau de normalisation UP H2>

  comme une note technique pour la normalisation, les informations de propriété pourraient être prises en compte sur la table des sites Web et une nouvelle table créée pour contenir les données de propriété, y compris la colonne IS_NORMAL. P>

  CREATE TABLE `Websites` (
      `id` SERIAL PRIMARY KEY,
      `name` VARCHAR(255),
      `owner` BIGINT UNSIGNED DEFAULT NULL,
      website_attributes,
      FOREIGN KEY `Website_Owner` (`owner`)
          REFERENCES `WebOwners` (id`)
              ON DELETE RESTRICT ON UPDATE CASCADE
  );
  
  CREATE TABLE `WebOwnersData` (
      `id` SERIAL PRIMARY KEY,
      `is_personal` BOOL,
      `user` BIGINT UNSIGNED DEFAULT NULL,
      `company` BIGINT UNSIGNED DEFAULT NULL,
      FOREIGN KEY `WebOwners_User` (`user`)
          REFERENCES `Users` (`id`)
              ON DELETE RESTRICT ON UPDATE CASCADE,
      FOREIGN KEY `WebOwners_Company` (`company`)
          REFERENCES `Companies` (`id`)
              ON DELETE RESTRICT ON UPDATE CASCADE,
  );
  
  CREATE VIEW `WebOwners` AS
  SELECT * FROM WebsitesData WHERE
      (`is_personal`=TRUE AND `user` IS NOT NULL AND `company` IS NULL) OR
      (`is_personal`=FALSE AND `user` IS NULL AND `company` IS NOT NULL)
  WITH CHECK OPTION;