在我们的工单系统中，根据工单的不同需求，我们需要不同的表结构来为每种工单存储不同类型的字段。例如客户投诉产品的票证，需要客户编号。和产品ID，但简单查询的票证不需要产品ID。某些类型的票可能不需要客户编号。还。
我们还需要此系统的分析和报告功能，其中包括产品详细信息和客户详细信息等动态详细信息。
作为解决方案，我想到了非 SQL 数据库（此处为 Cassandra），它可以支持动态数据库结构并提高分析和报告功能的效率。但是我之前没有使用过任何非 SQL 数据库，所以我不太确定这个解决方案。
任何人都可以提出任何更好的解决方案或对这个问题的非 SQL 解决方案有所了解吗？
【问题讨论】：
标签： database database-design data-structures
我推荐的设计类似于我在面向对象语言中的做法。这将产生潜在复杂连接的开销和多个表的开销。我会像这样布置我的数据库：
Table GeneralTickets
(
ticket_id number,
customer_id number,
... other fields that are **common to all tickets**
)
Table ComplaintTickets
(
complaint_id number,
ticket_id number (FK to GeneralTickets#ticket_id),
product_id number,
... other fields
)
Table FeatureTickets
(
feature_id number,
ticket_id number (FK to GeneralTickets#ticket_id),
... other fields
)
在这种情况下，您正在寻找的不是 No-SQL 解决方案，因为这个问题 1) 更适合关系数据库，2) 我非常怀疑您记录的数据量是否适合 No- SQL 解决方案。
更新
在报告功能方面，我仍然坚持使用关系数据库。您基本上有一个需要解决的数据仓库问题。您想要做的是拥有一系列基表（这些将是最终构建您的报告的表）。从这些基表中，您将创建所谓的materialized views。这些materialized views 将处理给定时间范围内的所有数据（即您的 1 月份报告）。
正如您所说，复杂连接和多个表的开销是主要的 因素我正在考虑 No-SQL 解决方案。 SQL 解决方案会增加 维护和降低性能也。我想，票务系统 不与其他系统紧密绑定，对于其他细节，如 产品详细信息或客户详细信息，我们可能会在更改时从 SQL DB 同步 事件。你能解释一下你如何看待第二个问题吗？
现在到您留下的评论。只有写得不好，SQL才会变慢，这就是笛卡尔连接和简单索引查找之间的区别。维护在所有这一切中都只占很小的一部分。但是，如果没有看到您的域对象（在您处理结果集后初始化的类），我就无法谈论维护方面。您的域可能需要修改为比现在更正确（不是说它不正确，只是它可能更正确）。保持多个系统同步将是您最不想做的事情之一。
【讨论】：
称我为老式的，但我认为我会建议使用常规的关系数据库。部分原因是如果“变化的要求”实际上是变化的，我会感到惊讶，他们需要 NoSQL 解决方案而不是引用完整性和 ACID 属性。部分原因是我知道对于常规 RDBMS，有各种各样的报告解决方案可用。
我的意思是，您不能只使用可选（即可为空）字段为工单建模，或定义多个工单子类型（即使用继承 - 请参阅 http://blogs.microsoft.co.il/blogs/bursteg/archive/2007/09/30/how-to-model-inheritance-in-databases.aspx）。
【讨论】：