相关疑难解决方法(0)

我正在开发一项新服务，该服务需要提供各地区的报告数据。每个区域都会有自己的数据库表，每个数据库表都会有一些同名的列，例如ReportDate。不同的表将有很多不同/独特的列，这就是为什么我为每个区域创建一个单独的表。大约有 10 个区域表。

我正在考虑为我的存储过程使用动态 sql，这样我就可以编写一个简单的查询，然后对每个表通用地运行它。与编写针对所有表执行相同 SQL 的 10 个单独查询相比，这会更快、更容易编写和维护。

SS 是否经过了很好的优化来处理这种类型的实现？您是否发现任何潜在的性能问题？我应该采取任何具体步骤来优化此实施的性能吗？这里有人认为动态 sql 出于某种原因是“邪恶的”吗？我特指的是完全在 SS 内完成的动态 sql，而不是传递动态 sql 语句的外部应用程序。

我是DDD和OO原则的新手,抱歉我的知识不足.

我有CustomerDTO和Customer课程.

我存储在所有字段和属性DTO类,并把它作为基类的客户类.

使用DTO的主要目的是将其传递给View.我已经在Customer类中扩展它,不会重复属性.

这是做正确的方法还是有更好的OO解决方案？

我已经阅读了AutoMapper,但我想知道,如果有替代解决方案.

非常感谢任何帮助.

1)表格可以与多个表格保持一对一的关系!

为了澄清更多,如果我想进行插入,第一个表将受到影响,其他表中只有一个会受到影响.

2)如果是这样,主键将如何？

3)此外,如果我想从这些表中检索大量记录,查询会是什么样子？

谢谢 .

介绍

我一直在阅读有关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, …