结合数据库表

我有两张看起来很相似的表格，我在考虑将它们结合起来，并认为我会从每个人那里得到一些输入。这里是他们现在的样子：结合数据库表

问题

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

您如何看待这两个表合并成一个什么。这是一个好主意还是让它们保持这种分离状态更好？

来源

2010-05-12 zSynopsis

您是否可以获得CopierIssueDetails记录*没有* HardwareTicketDetails记录的同一个问题ID或者他们是否在该方向配对？（我假设可以拥有HardwareTicketDetails记录而没有关联的CopierIssueDetails记录） – 2010-05-12 16:02:18

是的。当前系统确定选择的类别插入哪个表格，并且每个问题只能选择一个类别。 – zSynopsis 2010-05-12 16:05:12

最终问题归结为“这是一对一还是一对多的比例？”如果有可能在给定的表中有两个或更多项目与另一个表格中的项目有关，请将它们分开。如果没有，那么将它们组合起来将简化您的查询。

来源

2010-05-12 16:02:12 JYelton

我应该提到，对于适用于某种类型问题但不适用于另一类问题的字段，请确保您的应用程序有一些处理空数据或其他不适用数据的其他占位符的方法。 – JYelton 2010-05-12 16:03:57

+1正确。这不是唯一的考虑因素，但它是一个关键。 – Smandoli 2010-05-12 16:11:26

你当然可以，但你可能想考虑使列更通用一些，这样你就不会有空列。例如，您知道复印机没有显示器或鼠标，因此复印机行有显示器/鼠标列是没有意义的。你可以把这些列更通用的，通过将其更改为所谓的 “HardwareType” 与值一列：

0 =监控，

1 =鼠标，

2 =监控&鼠标，

3 =复印机

（然后，您可以将它放在查找表中，以跟踪您的ID）。

要考虑的事情是：

1）虽然结合这些表增加应用的速度？

2）虽然结合这些表增加了应用程序的维护？

如果表格都非常大，并用于不同的任务，它可能不明智。对于概念上“大致相同”的表格，只要不影响性能就可以将它们结合起来并不错，只要避免了仅针对特定项目的大量不必要的列，但是不是别人。

来源

2010-05-12 16:05:26 AlishahNovin

那么，这取决于你期望这种复杂性在未来有多大。

如果仅仅只有少数几个具体领域不同且具有许多共同领域的问题类型，将它们组合成一个并将这些领域置于null并不适用于特定情况是有意义的。

其他方法可能是将所有的公共字段合并为一个表，并添加另一种常见的其他详细信息的表状结构：

IssueID 
FieldName 
FieldValue_Text 
FieldValue_Number 
FieldValue_Float

，并且可以附加字段名称主表中包含列：

FieldID 
FieldName 
DataType

最后，我会说这是一个上下文，它可以证明任何设计的合理性，并且在不查看完整图片的情况下很难断言您的问题。

来源

2010-05-12 16:05:59

我需要一个令人信服的理由来合并它们，因为它们看起来不一样。也许有一个令人信服的理由，但我没有看到一个提供的。

在机械设计中，我们需要决定两个零件是否足够相同以便被相同的零件号调用，或者是不同的并且应该具有不同的PN。决定这一点的规则是“Form，Fit，Function”。

形式：它们“是否一样？”
适合：它们可以互换吗？
功能：他们是否执行相同的的目的，满足相同的需求？

您可以尝试将此条件应用于您的模式。

来源

2010-05-12 16:08:17 Smandoli

补充说明：您可能已经注意到“Form”有点含糊。我猜，这就是一位工程师可以放大他们的风格偏好的地方。 – Smandoli 2010-05-12 16:10:01

要考虑的问题：

执行表具有不同的数据？我竭力避免制作过于通用的字段。在这种情况下，“序列号”和“设备编号”听起来像他们可能是几乎相同的东西。但是“Last Count”不适用于电脑，“Monitor”和“Mouse”不适用于我知道的任何复印机。是的，如果不适用，您可以让这些字段为空。如果结合使用，我强烈建议您不要创建一个包含计算机“鼠标”代码和复印机计数的字段。这样疯狂的谎言。但是，您可以包含两组字段，并在不适用时将它们留空。
这些表的使用方式是否有所不同？如果你有一套你只做硬件问题的工作，或者预计只做硬件问题的一套工作，另一套工作只对复印机问题起作用，而对于两者都起作用的很少或没有任何工作，这是将它们分开的一个很好的理由。如果有很多操作同时处理这两个表，并且您不断在两个表上编写UNION，那么这表示它们应该是一张表。虽然我相信原则上你的模式应该模拟你正在处理的真实世界，并且代码应该在模式之后，实际上，如果在编写代码时你反复看到不同的模式会更容易处理，这是一个强大的线索，你不能准确地模拟你正在处理的真实世界。
您可能创建什么未来数据？是否还有其他六种类型的“问题”会与您打交道，因此您将不再使用3个表格，而是9个？如果是这样，那些数据将携带？他们将如何使用？或者这可能吗？

我会考虑最后的表现。改变你的模式以提高性能应该是只有在性能被证明是一个问题之后，或者你已经做了一些实际的基准来证明它会是的时候。在数据库上进行了许多过早的性能优化，实际上在提高性能的过程中很少或根本没有提高性能，但导致数据不规范和不严格。

来源

2010-05-12 16:24:49 Jay

我在这些情况下考虑的一件事是“这些事情将如何演变？”。例如，如果您需要为复印机添加新列，那么硬件可能需要同一列的可能性是多少？关于报告，你通常需要结合这些信息，还是通常有两种类型的报告？

如果这两件事看起来可能会发展/单独使用，那么我会建议忽略它们看起来非常相似的事实;否则，最终会遇到在您的查询中散布的特殊情况。

来源

2010-05-12 16:25:10

结合数据库表

回答

相关问题