Comment concevoir une base de données pour plusieurs domaines?

Question

Comment concevoir une base de données et organiser ses données si j’ai deux domaines ou plus et une base de données? Tous les sites à des fins de commerce électronique et un bien peuvent être en vente sur chaque site. Je n'ai donc que deux idées:

1. Je dois créer un champ supplémentaire (site_id) dans presque toutes les tables et dupliquer les données.
2. Je dois créer une table avec les informations id_site pour tous les autres champs des autres tables.

Les deux idées ont un énorme inconvénient. Des idées? Merci.

Answer 1

Il est probable qu’il existe une petite poignée de tables dans votre schéma qui soient liées à toutes vos autres tables. Ce sont ces tables dans lesquelles vous devez placer le site_id, pas toutes les tables de votre base de données.

Pour un exemple (très complexe), si mon schéma comprend une table Customers, une table Invoices et une table Éléments de ligne de facture, je n'ai pas besoin de site_id dans les trois tables. Je n'ai besoin que d'un site_id dans la table du client.

Answer 2

Il s'agit d'un problème classique lors de la création de systèmes multi-locataires. J'ai entendu différents avis sur cette question, mais ils se divisent en deux camps:

1. Utilisez l'ID du client hébergé ( site_id dans votre cas) sur chaque table contenant des données pour un client hébergé spécifique. Les défenseurs de cette approche citent la facilité avec laquelle il est facile d'identifier le locataire auquel les données appartiennent, ce qui constitue un avantage primordial, avec des implications sur la manière dont les données sont archivées (à savoir différents espaces de table pour différents clients).

2. Utilisez l'identifiant du locataire uniquement sur les tables de haut niveau. Les défenseurs de cette approche décrivent généralement les avantages d’une structure de base de données plus propre.

Je ne suis pas fan de la création de différentes tables physiques pour le même type de données provenant de différents clients. Cela a un certain nombre de conséquences défavorables:

• Il devient difficile de créer un modèle objet cohérent via un outil ORM
• Cette approche ne s'adapte pas avec un grand nombre de clients. Si vous avez 70 000 clients à desservir à partir d'une seule base de données, vous disposez de 70 000 ensembles de tables.
• Les noms de table doivent être générés dynamiquement pour les instructions SQL.

Answer 3

Je pense qu'une des approches utilisées par Wordpress et Drupal consiste à préfixer les tables avec un nom:

dom1_Customers
dom2_Customers

Ainsi, les tables ne deviennent pas disproportionnées et vous ne devez pas gérer un index supplémentaire de site_id. Cela dit, votre code doit le compenser, ce qui peut nécessiter une réinstrumentation (et les procédures stockées sont en gros sans fioritures).

Answer 4

Ma préférence est de créer des tables de mappage si nécessaire. Pensez qu'un produit peut exister pour le site 1, le site 2, etc. Les détails du produit ne changent pas d'un site à l'autre. Le prix des produits pourrait cependant! Dans ce cas, la table Prices peut nécessiter l'ID de site et l'ID de produit, l'ID de produit pouvant être répliqué pour chaque entrée sur les différents sites. Cela pourrait également être dit pour les utilisateurs, sauf que les utilisateurs peuvent trouver cela "grand frère". en sentiment. Donc, bien que cela puisse fonctionner pour les clients, je suggère généralement que les clients ont des comptes différents sur des sites différents! Parfois, ce qui fonctionnera physiquement ne signifie pas que cela fonctionnera logiquement. Placez le SiteID là où vous en aurez besoin plutôt que de le placer au hasard, partout. Gardez à l'esprit que vous pouvez avoir besoin de ce SiteID ailleurs que si votre application en a besoin ... pensez également aux requêtes hors ligne. Avoir à faire 5 jointures pour filtrer par le SiteID va sucer! Il est préférable de conserver les index que de rechercher le filtre!

En ce qui concerne le partitionnement horizontal au moyen de tables distinctes portant des noms similaires ... utilisez SQL Server 2005 et versions supérieures. Il dispose de fonctionnalités de partitionnement pour que le souci de la taille des données ne soit plus un problème.

Answer 5

La multi-base de données est-elle hors de question? Il semble que ce soit le plus facile et le plus propre, vous ne pouvez pas déranger les données d’un client avec un autre. Vous aurez besoin d’une base de données principale pour les informations sur les locataires et d’une base de données pour chaque titulaire.