Database 动态需求的数据库结构

在我们的票证系统中，根据不同的票证需求，我们需要不同的表结构来存储不同类型的票证字段。e、 g.客户投诉产品的票证，需要客户编号和产品id，但简单查询的票证不需要产品id。某些类型的票证可能也不需要客户编号

我们还需要该系统的分析和报告功能，包括产品详细信息和客户详细信息等动态详细信息

作为一种解决方案，我想到了非SQL数据库（这里是Cassandra），它可以支持动态数据库结构，并提高分析和报告功能的效率。但是我以前没有使用过任何非SQL数据库，所以我对这个解决方案不是很确定

---

有谁能为这个问题提出更好的解决方案或非SQL解决方案吗？

我建议的设计类似于我在面向对象语言中的设计。这将导致潜在复杂联接的开销和多个表的开销。我会这样布置我的数据库：

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
)   

在这种情况下，无SQL解决方案并不是您想要的，因为这个问题1）更适合关系数据库，2）我高度怀疑您记录的数据量是否与无SQL解决方案的数据量相同

更新

在报告特性方面，我仍然坚持使用关系数据库。实际上，您有一个需要解决的数据仓库问题。您要做的是拥有一系列的基表（这些表将最终构建您的报告）。从这些基表中，您将创建所谓的

物化视图

。这些

物化视图

将处理给定时间范围内（即您1月份的报告）计算后的所有数据

---

正如您所说，复杂联接和多个表的开销是主要的 我认为没有SQL解决方案的因素。SQL解决方案将增加 维护和降低性能。我想，票系统 没有紧密地绑定到其他系统和其他细节，例如 产品详细信息或客户详细信息，我们可能会在更改时从SQL DB同步 事件。你能解释一下你对第二个问题的看法吗

---

现在谈谈你留下的评论。SQL只有在写得不好时才会变慢，这就是笛卡尔连接和简单索引查找之间的区别。维护在所有这一切中起着很小的作用。但是，在谈到维护方面时，我必须看到域对象（在处理结果集之后初始化的类）。您的域可能需要修改为比现在更正确（不是说它不正确，只是它可能更正确）。保持多个系统同步将是您最不想做的事情之一

叫我老式，但我想我建议使用常规关系数据库。部分原因是，如果“变化的需求”实际上如此变化，那么我会感到惊讶，因为它们保证了NoSQL解决方案，而不是引用完整性和ACID属性。部分原因是我知道，对于常规的RDBMS，有各种各样的报告解决方案可用

---

我的意思是，你不能用可选字段（即可空字段）为票证建模，或者定义票证的几个子类型（即使用继承-请参见）。

定义票证的子类型会限制范围，因为从一年开始，我们会得到不同类型的票证，如果我们遵循每种类型的维护表，我们将需要创建许多表，这也将增加报告连接的复杂性。我不认为空字段对于这种变化的系统也是个好主意。正如你所说的，复杂连接和多个表的开销是我认为没有SQL解决方案的主要因素。SQL解决方案将增加维护并降低性能。我认为，票证系统并没有紧密地绑定到其他系统，对于其他详细信息，如产品详细信息或客户详细信息，我们可以在更改事件时从SQL DB同步。您能解释一下您对第二个问题的看法吗？@CoolZeroInfinity我已经更新了我的答案，以便给您更多反馈谢谢您的解释，很抱歉回复太晚。问题是，系统已经存在大约200种不同类型的票证，如您在这里给出的示例“FeatureTicket”和“ComplaintTicket”，旧的实现方法是这样的：以通常的方式存储所有与一般数据相关的票证，但对于其他不同的数据相关类型，票证以XML格式存储在单个字段中。这种方法限制了对这些数据的搜索和报告。在将来创建200个或更多的表是不可行的解决方案，搜索将过于复杂。你仍然建议使用SQL？