我有两张看起来很相似的表,我正在考虑将它们组合起来,并且我想从每个人那里得到一些意见。 这是他们目前的样子:
问题
Id | IssueCategory | IssueType | Status | etc..
-------------------------------------------------
123 | Copier | Broken | Open |
124 | Hardware | Missing | Open |
CopierIssueDetails
Id | IssueId | SerialNumber | Make | Model | TonerNumber | LastCount
---------------------------------------------------------------------
1 | 123 | W12134 | Dell | X1234 | 12344555 | 500120
HardwareIssueDetails
Id | IssueId | EquipmentNumber | Make | Model | Location | Toner | Monitor | Mouse
-----------------------------------------------------------------------------------
1 | 124 | X1123113 | Dell | XXXX | 1st floor | 0 | 1 | 0
您如何将这两个表合并为一个。这是一个好主意还是最好让它们像这样分开?
答案 0 :(得分:2)
归根结底,问题归结为“这是一对一还是一对多的比例?”如果在给定表中有可能有两个或更多项与另一个表中的项相关,则将它们分开。如果没有,那么组合它们将简化您的查询。
答案 1 :(得分:1)
我需要一个令人信服的理由来组合它们,因为它们看起来并不相同。也许有一个令人信服的理由,但我没有看到提供的。
在机械设计中,人们决定两个部件是否足够相同,以便被相同的部件号调用,或者是否不同并且应该得到不同的PN。决定这个的规则是“形式,适合,功能”。
您可以尝试将此条件应用于您的架构。
答案 2 :(得分:1)
在这些情况下我考虑的一件事是“这些事情将如何发展?”。例如,如果您需要为Copiers添加新列,那么硬件需要同一列的可能性是多少?报告怎么样,您通常需要合并信息,还是通常有两种类型的单独报告?
如果这两件事似乎有可能发展/单独使用,那么我建议忽略它们看起来非常相似的事实;否则,您最终会在整个查询过程中遇到特殊情况。
答案 3 :(得分:0)
你当然可以,虽然你可能想考虑使列稍微更通用,这样你就没有多个空列。例如,您知道复印机没有显示器或鼠标,因此复印机行没有监视器/鼠标列。您可以将这些列更通用,方法是将其更改为名为“HardwareType”的列,其值为:
0 =监控,
1 =鼠标,
2 =监控&鼠标,
3 =复印机
(然后您可以将其放入查找表中,以跟踪您的ID)。
您要考虑的事项是:
1)虽然组合这些表可以提高应用程序的速度吗?
2)虽然组合这些表可以增加应用程序的维护吗?
如果表格非常大,并且用于不同的任务,则可能不明智。对于在概念方面“大致相同”的表,只要它不影响性能,并且只要避免大量仅对特定项目特定的不必要的列,那么将它们组合起来并不坏。不是其他人。
答案 4 :(得分:0)
嗯,这取决于你对未来这种复杂性的期望有多大。
如果它只是更少的几个特定字段并且具有许多公共字段的问题类型,则将它们全部组合成一个并将字段保留为空,这在特定情况下不适用。
其他方法可以是将所有公共字段组合到一个表中,并添加另一个常见的附加详细信息表,其结构如下:
IssueID
FieldName
FieldValue_Text
FieldValue_Number
FieldValue_Float
并且可能是包含以下列的其他字段名称的主表:
FieldID
FieldName
DataType
最后,我会说这个背景可以证明任何设计是合理的,而且如果不看完整的图片就很难断言你的问题。
答案 5 :(得分:0)
需要考虑的问题:
表格是否有不同的数据?我竭力避免制造过于通用的领域。在这种情况下,“序列号”和“设备号”听起来像它们可能几乎是一回事。但“最后计数”不适用于计算机,“监视器”和“鼠标”不适用于我所知道的任何复印机。是的,如果不适用,您可以将这些字段设为null。如果你合并,我强烈建议你不要创建一个字段,其中包含计算机的“鼠标”代码和复印机的计数。那种疯狂就是谎言。但是,您可以包含两组字段,并在不适用时将其保留为空。
表格的使用方式不同吗?如果你有一组你做或预期做的事情只能解决硬件问题,而另一组事情只适用于复印机问题,而且很少或根本不适用于两者,这是将它们分开的一个很好的理由。如果有许多操作同时处理这两个操作,并且您不断在两个表上编写UNION,那么这表明它们确实应该是一个表。虽然我认为原则上你的模式应该模拟你正在处理的现实世界,并且代码应该在模式之后,实际上,如果在编写代码时你反复看到不同的模式会更容易使用,这是一个强有力的线索,你不能准确地模拟你正在处理的现实世界。
您可能会创建哪些未来数据?你还会处理其他六种类型的“问题”,那么你很快会有9个表而不是3个表吗?如果是这样,那些携带的数据是什么?他们将如何使用?或者这可能是吗?
我认为表现最后。改变模式以提高性能应该只是在性能被证明是一个问题之后才能完成,或者当你做了一些实际的基准来证明它将会是这样。在数据库上进行了大量过早的性能优化,实际上在实践中很少或根本没有提高性能,但会导致非标准化和草率数据。