【问题标题】:Better way to normalize these tables?标准化这些表的更好方法?
【发布时间】:2021-10-03 11:28:28
【问题描述】:

这更像是一个后端设计问题。我将使用以下 3 个表格来填充 Web 应用程序中的下拉菜单。

CREATE TABLE request_types(
    id INT AUTO_INCREMENT PRIMARY KEY,
    name as varchar(32) NOT NULL
);

CREATE TABLE citizenship_types(
    id INT AUTO_INCREMENT PRIMARY KEY,
    name as varchar(32) NOT NULL
);

CREATE TABLE designation_types(
    id INT AUTO_INCREMENT PRIMARY KEY,
    name as varchar(32) NOT NULL
);

所有 3 个表的设计都是相同的,所以我想知道将所有 3 个表的数据放入一个表中并使用另一个表来区分值属于哪个组,是否会是一个更好的做法到。

CREATE TABLE field_types(
    id INT AUTO_INCREMENT PRIMARY KEY,
    name as varchar(32) NOT NULL,
    category TINYINT NOT NULL
)


CREATE TABLE category_types(
    id INT AUTO_INCREMENT PRIMARY KEY,
    name as varchar(32) NOT NULL
)

category_types 的填充方式如下:

{
    1:"request",
    2:"citizenship",
    3:"designation"
}

【问题讨论】:

  • 这只有在其他表的列可以是任何类型的外键时才有用。您无法指定一列只能包含公民身份 ID。
  • 坚持现有的,并将名称设置为 UNIQUE。

标签: mysql database-design


【解决方案1】:

这实际上是没有标准化的。您无法说出任何会导致您采用这种设计的数据库规范化规则。

规范化规则之一是属性列必须依赖于表的键,而不是另一个属性列。在您的设计中,name 属性部分取决于非键列 category

我建议阅读像SQL and Relational Theory 这样的书。

【讨论】:

  • 我坚持第一选择。但是只是为了争论,使用 id 和 category 作为复合主键呢?
  • 我认为您正在尝试使用名为 One True Lookup Table 的反模式。这是一个古老的错误。
猜你喜欢
  • 2015-01-03
  • 1970-01-01
  • 2021-08-23
  • 1970-01-01
  • 2015-04-24
  • 2020-07-31
  • 2011-09-25
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多