问动态需求的数据库结构

EN

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

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 DB同步。你能解释一下你对第二个问题的看法吗？

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

可以说我很老套，但我想我会建议使用常规的关系数据库。部分原因是，如果“变化的需求”实际上变化如此之大，以至于它们需要NoSQL解决方案而不是引用完整性和ACID属性，我会感到惊讶。部分原因是我知道，对于常规的RDBMS，有各种各样的报表解决方案可用。

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