【问题标题】:Using auto_increments to join MyISAM tables in MySQL在 MySQL 中使用 auto_increments 连接 MyISAM 表
【发布时间】:2011-01-08 21:16:55
【问题描述】:

虽然我写 php 已经有很长时间了,但这始终是我自学的技能,我刚刚遇到了关于表连接的小信心危机!

假设 MySQL 数据库 auth 包含 MyISAM 表 userspermissions

users
- id (auto increment)
- email

permissions
- id (auto increment)
- name

要以多对多(或一对多)的方式连接这些表,我一直使用这样的桥接表:

user_permissions
- id (auto increment)
- user_id
- permission_id

(我知道 innoDB 能够建立关系,但它也更复杂并且占用更多内存,因此出于 q 的目的,我想留在 myISAM)

我的特殊问题是:使用自动递增键加入表是否明智,还是应该生成自己的附加键?

我知道如果表损坏并且我必须重建,或者如果我开始镜像到两个数据库并且密钥不同步,则可能会出现问题。

我还知道,如果我为每一行生成一个唯一的哈希(用于连接),那么在每次插入数据之前生成一个哈希并检查它是否是新的都会产生开销。

其他人是如何做到的?这些问题是您在实际情况中看到的吗?

感谢您的宝贵时间!

亚当

【问题讨论】:

    标签: mysql join auto-increment myisam


    【解决方案1】:

    权限和用户的加入会是这样的:

    SELECT      u.*, p.*
    FROM        user_permissions up
    INNER JOIN  users            u
    ON          up.user_id = u.id
    INNER JOIN  permissions      p
    ON          up.permission_id = p.id
    

    user_permission 中的id 列并不是真正需要的,除非您想从另一个表中引用它。如果您不考虑该 id,则 (user_id, permission_id) 将是主键(在这种情况下不会自动递增)。如果你有他单独的 id 列,那么你绝对应该在 (user_id, permission_id) 上添加 UNIQUE 约束

    【讨论】:

    • 谢谢,我知道如何执行 SQL - 问题更多是关于在连接中安全使用 auto_increments。
    • 我想我不明白这个问题。 “安全”是什么意思?自动递增与加入有什么关系?
    • 根据问题,如果数据库损坏或镜像失败,如果关系建立在 auto_incremented 值上,我是否有失去关系的风险?
    • 你可以说,如果你已经为用户(比如用户名)、权限(比如权限动词)和 user_permission(用户名、权限动词)使用了自然键,那么如果你会失去用户或权限表,您仍然可以通过查看 user_permission 中的内容来重新创建(部分)它们。这是你的问题吗?
    【解决方案2】:

    这通常是在使用代理键(组成或自动分配的值,除了唯一性之外没有任何意义)和自然键(对于所存储的实体具有某种语义意义的键,如名称, 或银行帐户 #)。

    在您的情况下,尚不清楚是否有任何自然键可以工作(用户表的每个方面都可能更改 - 结婚后姓名更改等)。如果在保持关系的同时密钥不可能变形,那么您将需要一个自然密钥。例如,元素周期表中的元素名称(Au, He, Es 等)(除了添加新元素之外不太可能发生变化,但是嘿,任何事情都可能发生......)。

    至于数据损坏,备份确实是最好的保护,因为任何东西都可能损坏。在典型操作中,您可以在迁移或同步时始终保留主键。使用精心复杂的代理键而不是数据库提供的自动增量会更有风险,因为它会使插入复杂化(您必须确保其唯一性,并可能以事务安全的方式处理冲突)......而且确实是精心生成的代理key 在数据损坏的情况下无济于事(无法将其与记录关联)。

    一个自然的 PK 说用户的电子邮件将是很多开销 - 每当电子邮件更改时必须更新每个关系,在 2 个帐户之间交换电子邮件地址很复杂,索引在宽值而不是整数上的效率要低得多。权衡倾向于自动递增键。

    这里有一篇好文章:

    http://decipherinfosys.wordpress.com/2007/02/01/surrogate-keys-vs-natural-keys-for-primary-key/

    【讨论】:

      猜你喜欢
      • 2019-06-20
      • 1970-01-01
      • 2011-07-25
      • 2014-03-01
      • 1970-01-01
      • 2010-12-29
      • 2017-02-15
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多