动态需求的数据库结构

时间:2012-11-05 10:16:20

标签: database database-design data-structures

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

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

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

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

2 个答案:

答案 0 :(得分: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只会很慢,这是笛卡尔连接和简单索引查找之间的区别。维护确实在所有这些中发挥了一小部分作用。但是,如果没有看到域对象(处理结果集后初始化的类),我就无法与维护方面说话。您的域可能需要修改为更正确而不是现在(不是说它不正确,只是它可能更正确)。保持多个系统同步将是您想要做的最后一件事。

答案 1 :(得分:0)

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

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

相关问题