Question

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

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

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

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

Answer 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将在计算给定时间范围（即您的1月份报告）后处理所有数据。

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

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

Answer 2

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

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

动态需求的数据库结构

2 个答案: