相关疑难解决方法(0)

我正在考虑如何在SQL Server数据库中表示复杂的结构.

考虑一个需要存储一系列对象细节的应用程序,这些对象共享一些属性,但有许多其他属性不常见.例如,商业保险计划可能包括同一保单内的责任,汽车,财产和赔偿保险.

在C#等中实现它是微不足道的,因为您可以创建一个带有Sections集合的Policy,其中Section是根据各种类型的封面所需继承的.但是,关系数据库似乎不容易这样做.

我可以看到有两个主要选择:

1. 为所有可能的变体创建一个Policy表,然后是一个Sections表,其中包含所需的所有字段,其中大部分都是null.

2. 创建一个Policy表和许多Section表,每个表对应一种封面.

这两种替代方案似乎都不令人满意,特别是因为必须在所有Sections中编写查询,这将涉及大量连接或大量空检查.

这种情况的最佳做法是什么？

刚刚发现以下声明作为利益 immutable object

不可变对象总是具有"失败原子性"(Joshua Bloch使用的术语):如果不可变对象抛出异常,它永远不会处于不合需要或不确定状态.

任何人都可以更详细地解释它,为什么会这样呢？

介绍

我一直在阅读有关EAV数据库的信息，大多数缺点似乎都与真的，真的，错误的EAV设计或从数据生成报告的难度有关。

通常，当您看到人们抱怨EAV时，他们使用少于三个的表来尝试复制RDBMS中单独的表+列的功能。有时，这意味着将所有内容（从小数到字符串）都存储在单个TEXT值列中。EAV还会破坏数据完整性的安全保护措施，如果您不小心的话，这可能会很糟糕。

但是，EAV确实提供了一种轻松的方式来跟踪历史数据，并允许我们在SQL和键值存储系统之间来回移动系统的某些部分。

如果我们根据类型区分不同的实体属性该怎么办。除了与特定属性和实体相关的正确索引值之外，这还使我们仍然可以处理belongsTo，Has，HasMany和HasManyThrough关系。

考虑以下两个基本实体

products (price -> decimal, title -> string, desc -> text, etc...)
    attributes
        options
            [...]
        int
        datetime
        string
        text
        decimal
        relation
            [id,foreign_key]

users (gender -> options, age -> int, username -> string, etc...)
    attributes
        options
            [...]
        int
        datetime
        string
        text
        decimal
        relation
            [id,foreign_key]

RDBMS架构设计

众所周知，用户资料和产品是世界上最多样化的产品。每个公司处理它们的方式都不一样，并且针对他们的需求具有不同的“列”或“属性”。

以下是如何处理多个（嵌套和/或关系）实体的视图。

想法是，对于每个实体都有此主属性表，然后该主表指定如何查找和解释这些值。这使我们能够处理特殊情况，例如指向其他实体的外键以及诸如“选项”或十进制数字之类的东西。

entity_type {id，type，//即“博客”，“用户”，“产品”等。created_at}

entity {
    id,
    entity_type_id, 
    created_at
}

    attr {
        id,
        entity_id,
        type,
        name,
        created_at
    }

        option {
            id,
            attr_id, …