将数据存储为行而不是列

Question

这是我存储数据的典型方式（显然不是以纯文本形式存储密码）

    用户表

    | 用户名 | 用户名 | 全名 | 电子邮件 | 密码 |
    |--------|----------|----------|---------|-------- --|
    |1 |userAAA |用户 Aaa |aa@aa.com|aAaaA |
    |1 |userBBB |用户 Bbb |bb@bb.com|bBbbB |
    |1 |userCCC |用户抄送 |cc@cc.com|cCccC |
    |--------|----------|----------|---------|-------- --|

以以下方式存储它有什么问题吗？

    用户表属性表

    | 用户名 | 用户名 | |属性ID | 属性 |
    |--------|----------| |------------|-----------|
    |1 |用户AAA | |1 |全名 |
    |1 |用户BBB | |2 |电子邮件 |
    |1 |用户CCC | |3 |密码 |
    |--------|----------| |------------|-----------|

    属性值表

    |用户ID | 属性ID | 属性值 |
    |-------|-------------------------|----------------|
    |1 | 1 |用户 Aaa |
    |1 | 2 |aa@aa.com |
    |1 | 3 |aAaaA |
    |2 | 1 |用户Bbb |
    |2 | 2 |bb@bb.com |
    |2 | 3 | bBbbB |
    |3 | 1 |用户抄送 |
    |3 | 2 |cc@cc.com |
    |3 | 3 |ccccC |
    |-------|-------------------------|----------------|

我在这里看到的巨大好处是能够轻松地向用户添加其他属性。但我真的很想就此获得另一种意见。

Answer 1

这称为实体-属性-值设计。有关优点和缺点的详细讨论，请参阅性能和可扩展性语义数据建模的最佳实践。

主要问题是查询在设计时变得难以表达并且在运行时表现不佳。

更好的方法是为已知属性拥有一个真正的模式，正确索引，并允许 EAV 用于未来的、未知的、自定义的、非搜索关键属性。

像MongoDB这样的无模式数据库也是 EAV 的替代品。