|
|
1
1
创建“付款类型”表;这里没有真正的问题。这是正确的规范化和使用关系数据库的能力。这样做的原因之一是能够更新一种类型的付款记录,而不必接触用户表中的相关数据。您在两个表之间的连接将允许您的应用程序仅在1个位置更改付款信息,以查看更新的付款信息类型。 至于你的其他领域,它们可能没有那么清晰。问自己每个字段的问题是:“这个字段是否只与用户相关,或者它本身是否有意义和可能的用途?”。如果您无法想象在用户上下文之外有意义的字段,则可以将其安全地保留为用户表上的字段,否则,请执行主键-外键关系,并将信息放在自己的表中。 |
|
|
2
2
阅读本文” Database Normalization Basics “,如果还有问题请回来。这会有很大的帮助。 正如您将在本文中看到的,这些决策背后最基本的想法是,每个表应该只表示一个“事物”,并且每个字段应该直接并且只与该事物相关。 在您的付款类型示例中,如果您预期需要存储有关每种付款类型的附加信息,那么将其分解为单独的表可能是有意义的。 |
|
|
3
1
如果您正在构建具有变量输入的表单,我不建议将其构建为一个表。这是不灵活和肮脏的。 归一化 是键,但是如果您最终使用键/值设置,或者实际上是跨多个表的标量类型实现,并且无法缓存:
a)表格数据中的表格定义,以及
然后您可能会遇到性能边界。 在这个kvp设置中,您可能希望看到 CouchDB 或者是表驱动的存储格式。 如果您的内部数据与数据库中已有的其他数据有很大的关系,那么您可能还需要考虑更复杂的设置,如序列化对象存储和缓存表。 |
|
|
4
0
50根柱子太多了。您是否考虑过像属性表那样存储值的表?这只有在您不需要定期查询它包含的值时才有用。
|
|
|
5
0
我想我找到了解决这个问题的好方法。感谢我的一个朋友的建议! 我有三个表,field idfield、fieldname、fieldtype、fieldinput idinput、idfield、iduser和user iduser、username…等 这样就很容易看到用户的回答,解决方案具有一定的可扩展性,并且提供了一个很好的概述。我将在远离数据库的另一个层中约束备选方案。我认为这是值得做的权衡。 对此解决方案有什么建议或批评吗? |
|
|
developer · 带外键的SQL表设计 1 年前 |
|
|
relatively_random · 确保两个表之间一致的共同参考 1 年前 |
|
|
b126 · 在两种不同的Oracle模式上执行相同查询的速度差异很大 2 年前 |
|
|
robertspierre · 在多对多关系中自动删除未引用的行 2 年前 |
|
|
Michael Samuel · MYSQL在以下情况下自动创建索引 8 年前 |