【问题标题】:How is foreign keys stored when not having an ID-column?没有 ID 列时如何存储外键?
【发布时间】:2014-02-26 19:12:43
【问题描述】:

我想知道在 MySQL 中拆分表时理论上是否可以删除 ID 列。

假设我有一张包含这些信息的表格:

+-----------+------------+ +------------+---------+ |姓名 |国家ID | |国家ID |国家 | +-----------+------------+ +------------+---------+ |特蕾莎 | 1 | | 1 |美国 | |奇基塔 | 1 | +------------+---------+ |哈兰 | 1 | |万达 | 1 | |达德利 | 1 | |凯瑟琳 | 1 | |泰德 | 1 | |达西 | 1 | |安东内特 | 1 | |雷内塔 | 1 | |阿拉 | 1 | |金刚砂 | 1 | |阿拉 | 1 | |安东内塔 | 1 | +-----------+------------+ +------------+---------+ +------------+ |姓名 |国家 | |国家 | +------------+---------+ +------------+ |特蕾莎 |美国 | |美国 | |奇基塔 |美国 | +----------+ |哈兰 |美国 | |万达 |美国 | |达德利 |美国 | |凯瑟琳 |美国 | |泰德 |美国 | |达西 |美国 | |安东内特 |美国 | |雷内塔 |美国 | |阿拉 |美国 | |金刚砂 |美国 | |阿拉 |美国 | |安东内塔 |美国 | +------------+---------+

下表会比上表占用更少的空间吗?外键是否会“理解” Person-table 中的“America”链接到一个 Country-table,占用的空间比 ID-version 少,因为它已经引用了另一个 table。

我很困惑,所以我希望你们中的一些人能理解我的问题。

【问题讨论】:

  • 您不必担心空间问题。外键不“理解”任何东西。外键所做的是强制完整性(主要目的,它们做得更多)。这意味着如果另一个表中不存在随机数据,如果它们是通过 FK 引用的,则您不能在该表中插入随机数据。现在,至于图像-您对第一张图像所做的事情是正确的。你对第二个的所作所为是犯罪,你应该被监禁并禁止发展,永远。在空间方面,数据库使用各种机制来优化使用的空间,您永远不必担心。
  • 这是古老的自然与替代关键辩论的化身,它不像 @N.B. 那样明确。会让你相信。使用自然键并没有犯罪:确实,在某些情况下,这确实是一个非常明智的举动 - 然而,这种情况是例外而不是常态,所以我建议任何新手数据库设计要避免它们,直到他们意识到潜在的陷阱。
  • 关于存储,见Data Type Storage RequirementsVARCHAR(255) CHARACTER SET utf8 列对于包含字符串'America' 的每条记录将需要8 个字节的存储空间;而TINYINT UNSIGNED 列对于每条记录只需要 1 个字节的存储空间。因此,您的后一个示例将消耗比前一个示例多 8 倍的存储空间;在Country 列上加入表会相应地变慢,因为需要更长的比较时间,但在这种情况下通常需要更少的连接。
  • @eggyal 自然与替代的关键论点确实是不幸和大量加班的黑暗深渊。无论如何,如果应用得当,它们都是强大的概念。
  • 然而,在我之前的评论中解释的存储和性能问题在大多数情况下可以忽略不计,应该很少影响一个人的架构设计决策。记住 Knuth 的格言:“过早的优化是万恶之源”。

标签: mysql database normalization


【解决方案1】:

想象一个智能数据库用任意指针替换字符串“America”。此解决方案需要有一个带有数字 ID 的列,并且它是相同的

使用 int ID。即使不是真正的问题,它也会节省空间。它将使索引更快地工作并为您节省很多问题。假设有人写“America”与“AMERICA”。字符串比它们看起来更复杂。国家在不同的语言中有不同的名称。国家有没有特别的地方。 “西班牙”对“西班牙”。

附:如果您想要一个清晰的主键,请使用 ISO 代码。例如“美国”。

【讨论】:

    猜你喜欢
    • 2012-11-27
    • 2015-11-21
    • 2016-12-11
    • 2020-10-15
    • 2018-01-29
    • 1970-01-01
    • 1970-01-01
    • 2022-01-22
    • 1970-01-01
    相关资源
    最近更新 更多