0

在我们的工单系统中，根据工单的不同需求，我们需要不同的表结构来为每种工单存储不同类型的字段。例如，客户投诉产品的票证，需要客户编号。和产品ID，但简单查询的票证不需要产品ID。某些类型的票可能不需要客户编号。还。

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

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

任何人都可以提出任何更好的解决方案或对这个问题的非 SQL 解决方案有所了解吗？

4

2 回答 2

1

我推荐的设计类似于我在面向对象语言中的做法。这将产生潜在复杂连接的开销和多个表的开销。我会像这样布置我的数据库： 

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将处理给定时间范围内的所有数据（即您的一月份报告）。

正如您所说，复杂联接和多个表的开销是我考虑 No-SQL 解决方案的主要因素。SQL 解决方案会增加维护并降低性能。我认为，工单系统与其他系统没有紧密绑定，对于产品详细信息或客户详细信息等其他详细信息，我们可以从 SQL DB 同步更改事件。你能解释一下你如何看待第二个问题吗？

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

于 2012-11-05T20:07:02.480 回答
0

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

我的意思是，您不能只使用可选（即可为空）字段对票证建模，或者定义票证的几种子类型（即使用继承 - 请参阅http://blogs.microsoft.co.il/blogs/bursteg/archive/2007 /09/30/how-to-model-inheritance-in-databases.aspx）。

于 2012-11-05T21:07:11.783 回答