Je ne sais pas pourquoi vous vous inquiétez du nombre de tables :avoir moins de tables ne signifie pas automatiquement que votre base de données est plus petite, plus efficace ou mieux conçue. Surtout si la réduction du nombre de tables augmente la complexité de vos requêtes, je ferais très attention à le faire.
Quoi qu'il en soit, j'opterais pour une table de traduction par table "de base". La raison principale est que votre deuxième solution n'est pas flexible :si la clé primaire n'est pas un entier unique, elle devient extrêmement difficile à implémenter et à utiliser. La recherche de traductions est également plus complexe et, selon la taille de la table et des données, il peut être difficile de l'indexer efficacement.
La raison pour laquelle vous avez un TranslationID n'est pas claire sur les Products table; généralement, la relation est inversée :
create table dbo.Products (
ProductCode char(10) not null primary key,
ProductName nvarchar(50) not null,
ProductDescription nvarchar(100) not null,
-- other columns
)
create table dbo.ProductsTranslations (
ProductCode char(10) not null,
LanguageCode char(2) not null,
ProductName nvarchar(50) not null,
ProductDescription nvarchar(100) not null,
-- other translations
constraint FK1 foreign key (ProductCode)
references dbo.Products (ProductCode),
constraint FK2 foreign key (LanguageCode)
references dbo.Languages (LanguageCode),
constraint PK primary key (ProductCode, LanguageCode)
)
En fonction de votre ensemble d'outils et de votre processus de déploiement, vous souhaiterez peut-être générer des tables de traduction directement à partir de celles de base dans le cadre de la création de votre base de données. Et vous pouvez utiliser des vues pour fournir une version pratique et "entièrement traduite" de la table de base.
Une question intéressante est de savoir quelle langue est utilisée pour les colonnes dans Products et s'ils peuvent être utilisés directement lorsqu'aucune traduction n'est requise. Ma suggestion serait que tout le code de production passe un paramètre de langue et prenne le texte de ProductsTranslations table uniquement, même pour l'anglais (ou quelle que soit la langue interne de votre entreprise). De cette façon, vous pouvez être sûr que tous les noms "officiels" se trouvent dans la même table, et les colonnes de la table de base sont là pour la clarté et l'exhaustivité du modèle de données ainsi que pour la commodité du développeur et (éventuellement) l'utilisation interne ad hoc rapports et ainsi de suite.
