数据库设计 - 多个文本字段

我有一张桌子,上面有几种语言的产品和描述。现在表格结构是这样的

tblProducts </强>

productId INT PK AI
productDesc_en VARCHAR
productDesc_de VARCHAR
productDesc_it VARCHAR

等等。 en表示英语,de表示德语

所以访客根据他的语言设置,看到他的语言描述。

只是想知道,存储这样的数据有什么好处吗?

tblProducts </强>

productId INT PK AI

tblProductDesc_en </强>

descId INT PK AI
tblProducts_productId INT FK
description VARCHAR

tblProductDesc_de </强>

descId INT PK AI
tblProducts_productId INT FK
description VARCHAR

tblProductDesc_it </强>

descId INT PK AI
tblProducts_productId INT FK
description VARCHAR

我在这个解决方案中看到的专业人士:

  1. 从数据库角度更容易维护
  2. 从DB记录中实例化对象时使用的内存较少(因为只需要语言) 将存储在一个对象中)

con:s:

  1. 必须使用JOIN来获取可能会影响性能的所需数据;
  2. 类中更复杂的getter和setter

还要别的吗?

谢谢!

0
为什么不只有一个 tblProductDesc ,并为 tblProductDesc_lang 添加一列?并为每种语言保存一个新行?
额外 作者 Jared Farrish,
通过第二个解决方案,你指的是你问题中的一个?您正在谈论具有相同精确列的多个表,唯一的区别是关于行(语言)的属性。您不必拥有任何空行(不确定您为什么这么认为)。保存说明时,请为每种可用语言添加一行。
额外 作者 Jared Farrish,
@JaredFarrish,它与第二个解决方案有什么区别?我仍然需要使用join来获取正确的结果。此外,我将不得不存储大量的空列,其中没有特定语言的描述。
额外 作者 paulus,

2 答案

我认为只有一个带有该语言标志的额外表格将是一个非常接近标准化的好解决方案,在添加新语言时提供更加可靠的数据库模式。

它会是这样的:

CREATE TABLE `language` (
  `prodID`  INT UNSIGNED NOT NULL  ,
  `desc` varchar(30) null  ,
  `lang`  char(2) NOT NULL,
  PRIMARY KEY  (`prodID`,`lang`),
  CONSTRAINT `fk0` FOREIGN KEY (`prodID`)
        REFERENCES `product` (`prodID`)
        ON DELETE CASCADE
) ENGINE=InnoDB ROW_FORMAT=COMPACT;

当产品被删除时,外键将提供完整性,并且仅在产品存在时允许插入。

复合主键将使语言和产品的描述仅存储一次。

在依赖性方面,这个主键对我来说很好,回想一下db的讲座是好的,因为非主键字段依赖于主键的两个部分,我的意思是需要识别两个部分。

你有一个相同的字段作为主键和外键的一部分,就像借用这部分主键。

==========编辑1(上面没有任何改变)============== 我会在desc字段上用 Not Null 替换 Null 。然后,如果产品存在且描述不是这意味着没有可用的描述。我认为没有理由允许上面的null desc。

2
额外

您现有情况的最大特点是需要添加语言时。当您将语言分离出来时,您当前解决方案的更改可能会更广泛,更脆弱。

在您的两个建议之间有一个替代解决方案,它可以减少您建议的解决方案的影响。这是在产品描述中使用一种语言作为默认语言,并在单独的表中使用替代语言。这确实假设大多数用户将使用一种语言访问您的数据库。

0
额外
使用您的解决方案 - 这假设我在构造函数方法中获取描述?然后,如果描述与语言不匹配,我将不得不调用单独的方法来获取正确的描述,或者以某种方式创建动态查询以在构造函数执行期间检测语言。我担心,这会使它变得更复杂。我在第二种方法中看到的另一个专业是,我不必从构造函数中获取描述(我通常尝试给构造函数提供尽可能少的参数),而是根据语言从单独的方法获取描述。
额外 作者 paulus,