代码之家  ›  专栏  ›  技术社区  ›  Phil

SQL设计问题-是否有多个表?

  •  0
  • Phil  · 技术社区  · 15 年前

    数据库设计的15个ECTS学分。我真的无法为我的问题找到最好的设计解决方案。

    这就是:基本上我正在制作一个工具,它收集了很多关于用户的信息。用户最多可以填写50个数据字段,从简单的复选框到文本输入。我现在正在设计数据库(使用MySQL),无法决定是将单个用户表与所有这些字段一起使用,还是为每个输入类别都提供一个表。

    例如“付款类型”。这一个有三个选项,如果我使用“table”的方式,我将添加一个表payment type,并为每个付款类型提供二进制字段。然后,我需要和id表来标识用户选择了哪个paymenttype,而如果我使用一个用户表,那么数据就已经存在了。

    这个网站可能会看到很多用户(电视、互联网和无线电营销),所以我担心哪种选择是最好的。

    如果你需要更多的信息来做决定,我很乐意提供更多的细节。

    谢谢你的阅读。

    5 回复  |  直到 15 年前
        1
  •  1
  •   Tahbaza    15 年前

    创建“付款类型”表;这里没有真正的问题。这是正确的规范化和使用关系数据库的能力。这样做的原因之一是能够更新一种类型的付款记录,而不必接触用户表中的相关数据。您在两个表之间的连接将允许您的应用程序仅在1个位置更改付款信息,以查看更新的付款信息类型。

    至于你的其他领域,它们可能没有那么清晰。问自己每个字段的问题是:“这个字段是否只与用户相关,或者它本身是否有意义和可能的用途?”。如果您无法想象在用户上下文之外有意义的字段,则可以将其安全地保留为用户表上的字段,否则,请执行主键-外键关系,并将信息放在自己的表中。

        2
  •  2
  •   JohnFx    15 年前

    阅读本文” Database Normalization Basics “,如果还有问题请回来。这会有很大的帮助。

    正如您将在本文中看到的,这些决策背后最基本的想法是,每个表应该只表示一个“事物”,并且每个字段应该直接并且只与该事物相关。

    在您的付款类型示例中,如果您预期需要存储有关每种付款类型的附加信息,那么将其分解为单独的表可能是有意义的。

        3
  •  1
  •   Aiden Bell    15 年前

    如果您正在构建具有变量输入的表单,我不建议将其构建为一个表。这是不灵活和肮脏的。

    归一化 是键,但是如果您最终使用键/值设置,或者实际上是跨多个表的标量类型实现,并且无法缓存:

    a)表格数据中的表格定义,以及
    b)存储的联接结果(缓存视图或其他视图)
    c)或不在适当的碎片中建立

    然后您可能会遇到性能边界。

    在这个kvp设置中,您可能希望看到 CouchDB 或者是表驱动的存储格式。

    如果您的内部数据与数据库中已有的其他数据有很大的关系,那么您可能还需要考虑更复杂的设置,如序列化对象存储和缓存表。

        4
  •  0
  •   BC.    15 年前

    50根柱子太多了。您是否考虑过像属性表那样存储值的表?这只有在您不需要定期查询它包含的值时才有用。

    INSERT INTO UserProperty(UserID, Name, Value)
         VALUES(1, 'PaymentType', 'Visa')
    
    INSERT INTO UserProperty(UserID, Name, Value)
         VALUES(1, 'TrafficSource', 'TV')
    
        5
  •  0
  •   Phil    15 年前

    我想我找到了解决这个问题的好方法。感谢我的一个朋友的建议!

    我有三个表,field idfield、fieldname、fieldtype、fieldinput idinput、idfield、iduser和user iduser、username…等

    这样就很容易看到用户的回答,解决方案具有一定的可扩展性,并且提供了一个很好的概述。我将在远离数据库的另一个层中约束备选方案。我认为这是值得做的权衡。

    对此解决方案有什么建议或批评吗?