标签: data-modeling

我有四张桌子

create table entities{
integer id;
string name;
}

create table users{
integer id;//fk to entities
string email;
}

create table groups{
integer id;//fk to entities
}

create table group_members{
integer group_id; //fk to group
integer entity_id;//fk to entity
}

我想创建一个查询,直接或间接返回用户所属的所有组.显而易见的解决方案是在应用程序级别进行递归.我想知道我可以对我的数据模型进行哪些更改以减少数据库访问,从而获得更好的性能.

我设计的数据库有3个主要的表:BOOKS,ARTICLES,NOTES.
每本书或文章都可以有多个笔记,我的原始设计就是这样,这意味着书上的注释和文章上的注释都会出现在"笔记"表中.以下是NOTES表格的列:

• note_id
• note_type
• note_type_id
• note_content

NOTE_TYPE可以是"书"或"文章"; NOTE_TYPE_ID是FK的book_id 如果该note_type是"书" 或一篇文章的ID如果note_type是"文章".

现在我开始怀疑这是否是正确的(或最佳标准化的)设计.另一种方法是使用5个表

书籍/文章/笔记/ book_notes/article_notes

通过这种方式,我可以分别保留书籍笔记和文章笔记,列就像

'notes'{note_id,note_content}'book_notes'{book_id,note_id}'article_notes'{articel_id,note_id}

哪一个更正或更好？

我有一个包含两个表的数据库:

• 项
• 标签

条目表包含每个都有一个或多个标签的帖子.问题是,每个帖子可以有任意数量的标签.换句话说,我不能拥有'tag1','tag2'等列并执行LEFT JOIN.

我应该如何设置条目,以便每个帖子可以有任意数量的标签？

我想知道这三种模式之间有什么区别.

据我所理解:

• 代理仅用于延迟加载实体
• 存储库用于向模型添加逻辑(宽度为DQL语句的一些快捷方法)
• 服务用于依赖模型和控制器

对于这最后的服务,我不支持Doctrine 2项目作为存储库而不知道后面的持久系统,因为它使用ORM和DBAL.

我读过代理可以用来为实体添加逻辑,那么与存储库的区别是什么？

顺便说一下,我的实体是否只包含公共getter/setter属性,只有那个？这是对的吗？

我有点迷失在这里.

你有什么具体的例子吗？

我在MySQL中有两个已经拥有数据的数据库.他们有完全相同的架构.我想将这两个数据库合并为一个.我试过了:

mysqldump -u root -p --databases database1 database2 database3 > database1_database2_da

但是,当我尝试打开时database1_database2_da,我最终只得到一个数据库中的数据,但不是所有数据库中的数据.我还想提一下,这两个数据库的记录从1开始,因为它们是自动生成的.您是否认为有一种方法可以合并这两个数据库而不会丢失任何数据？

这个问题不一定是Couchbase 2.0开发的具体预览,但我认为它可能会帮助人们调查新的Couchbase产品.

我正在寻找有关数据建模的建议.我们正在调查Couchbase,以便将其用于实时分析.

但是,我找不到任何关于如何最好地模拟现实世界数据的文档.

我将提出一个场景,如果社区可以帮助我或讨论如何建模的一些想法,那将非常有用吗？

请注意,这不代表我们的产品,我不是要求人们为我们解决我们的建模问题更倾向于讨论

让我们假设客户在特定日期/时间做出产品购买,产品与他们的信息,如ID,名称,描述和价格,购买时的日期进行.

最初的要求是能够计算两个日期之间的所有购买.任何1天的购买量可能超过10万 - 这是一项非常大的业务;)

如果任何语法不正确请告诉我 - 欢迎所有建议/帮助.

如果我们将数据建模为类似的东西(可能完全不正确):

购买产品

{
    "_id" : "purchase_1",
    "_rev" : "1-1212afdd126126128ae",
    "products" :  [
        "prod_1" : {
            "name" : "Milk",
            "desc" : "Semi-skimmed 1ltr",
            "price" : "0.89"
        },
        "prod_7568" : {
            "name" : "Crisps", 
            "desc" : "Salt and Vinegar",
            "price: "0.85"
        }
    ]
    "date" : "2012-01-14 14:24:33"
}

{
    "_id" : "purchase_2",
    "_rev" : "1-1212afdd126126128ae",
    "products" :  [
        "prod_89001" : {
            "name" : "Bread", 
            "desc" : "White thick sliced", …

我被要求描述这个数据结构的错误,以及我将如何改进它.

这是数据结构:

这是我到目前为止:

• 汽车价格只有在汽车在陈列室中时才会设定,将汽车价格放在汽车表中会更有意义

• 将NULL数据存储在Car Table中是没有意义的,最好有一个类似于此的布局:

  

• 需要有一个数量标题来显示有多少特定的汽车在陈列室中,因为一些展厅有多辆相同的汽车

我制作的新表格仍然有重复的数据,我依旧记得在绘制数据结构时是不是没有,所以我想我需要制作第3张表格？我真的不确定......

我只需要帮助解决当前数据结构的问题,如果有任何方法可以改进它,那么任何帮助都会受到赞赏.

有一段时间我现在在精神上受到两种物理系统建模设计理念的冲突的困扰,我想知道社区为此提出了什么样的解决方案.

对于复杂(呃)模拟,我喜欢为对象创建类的抽象,以及如何使用我想要研究的真实对象来识别类的对象实例,以及对象的某些属性如何表示现实生活对象的物理特征.让我们把弹道粒子系统作为一个简单的例子:

class Particle(object):
    def __init__(self, x=0, y=0, z=0):
        self.x = x
        self.y = y
        self.z = z
    def __repr__(self):
        return "x={}\ny={}\nz={}".format(self.x, self.y, self.z)
    def apply_lateral_wind(self, dx, dy):
        self.x += dx
        self.y += dy

如果我用一百万个值初始化它,我可能会这样做:

start_values = np.random.random((int(1e6),3))

particles = [Particle(*i) for i in start_values]

现在,让我们假设我需要对我的所有粒子做一个特定的事情,比如添加一个横向风向量,只为这个特定的操作导致ax,y shift,因为我只有一堆(列表)我的所有粒子,我需要遍历所有粒子才能做到这一点,这需要花费这么多时间:

%timeit _ = [p.apply_lateral_wind(0.5, 1.2) for p in particles]
1 loop, best of 3: 551 ms per loop

现在,相反的明显范式,显然更有效,是保持在numpy水平,只是直接在数组上进行数学运算,速度超过10倍:

%timeit start_values[...,:2] += np.array([0.5,1.2])
10 loops, best of 3: 20.3 ms per …

我是商店的新手key-value。我的目标是使用嵌入式键值存储来保持持久数据模型。如果使用传统的 RDBMS 设计，数据模型将包含很少的相关表。我正在查看一篇关于为键值存储建模表的中等文章。尽管本文使用 Level DB 和 Java，但我计划在我的工作中使用 Level DBRocksDB或FASTERC++。

它使用一种方案，其中每行的每个属性都使用一个键，如下例所示。

$table_name:$primary_key_value:$attribute_name = $value

当用户代码确切地知道要获取哪个键时，上面的内容对于点查找来说是很好的。但也有一些场景，比如搜索具有相同电子邮件地址的用户，或者搜索超过一定年龄的用户，或者搜索某一特定性别的用户。在搜索场景中，文章对所有键执行线性扫描。在每次迭代中，它都会检查键的模式，并在找到具有匹配模式的键后应用业务逻辑（检查匹配的值）。

看来，这种类型的搜索效率很低，在最坏的情况下需要遍历整个商店。为了解决这个问题，需要一个反向查找表。我的问题是

如何建模反向查找表？这是某种轮子的重新发明吗？有什么替代方法吗？

很容易想到的一个解决方案是separate ?为每个可索引属性建立一个存储，如下所示。

$table_name:$attribute_name:$value_1 = $primary_key_value 

采用这种方法，迫在眉睫的问题是

如何处理这个反向查找表中的冲突？因为多个$primary_keys 可能与同一个值相关联。

作为直接的解决方案，可以不存储单个值，而是array存储多个主键，如下所示。

$table_name:$attribute_name:$value_1 = [$primary_key_value_1, ... , $primary_key_value_N]

但是这种类型的建模需要用户代码从字符串解析数组，并在多次操作后再次将其序列化为字符串（假设底层键值存储不知道数组值）。

将多个键存储为数组值是否有效？或者存在一些供应商提供的有效方法？

假设类似字符串化的数组设计有效，每个可索引属性都必须有这样的索引。因此，这提供了对索引什么和不索引什么的细粒度控制。想到的下一个设计决策是这些索引将存储在哪里？

索引应该存储在单独的存储/文件中吗？或者在实际数据所属的同一存储/文件中？每个房产是否应该有不同的商店？

对于这个问题，我没有任何线索，因为这两种方法都需要或多或少相同数量的 I/O。然而，如果数据文件较大，则磁盘上的内容较多，内存上的内容较少（因此 I/O 较多），而对于多个文件，内存上的内容较多，因此页面错误较少。根据特定键值存储的架构，这种假设可能是完全错误的。同时，文件太多会成为管理复杂文件结构的问题。此外，维护索引需要插入、更新和删除操作的事务。拥有多个文件会导致多个树中的单个更新，而拥有单个文件会导致单个树中的多个更新。

交易是否更具体地支持涉及多个存储/文件的交易？

不仅是索引，还有表的一些元信息也需要与表数据一起保存。要生成新的主键（自动递增），需要先了解最后生成的行号或最后一个主键，因为类似 a 的东西COUNT(*)不起作用。另外，由于未对所有键建立索引，因此该meta信息可包括对哪些属性建立索引以及对哪些属性未建立索引。

如何存储每个表的元信息？

同样的一组问题也出现在元表中。例如元应该是一个单独的存储/文件吗？此外，我们注意到并非所有属性都被索引，我们甚至可能决定将每一行作为 JSON 编码值存储在数据存储中，并将其与索引存储一起保存。底层键值存储供应商会将该 JSON 视为字符串值，如下所示。

$table_name:data:$primary_key_value = {$attr_1_name: $attr_1_value, ..., $attr_N_name: $attr_N_value}
...
$table_name:index:$attribute_name = [$primary1, ..., $primaryN] …

我确信之前已经研究过这个主题，我不确定它叫什么或者我还应该研究什么技术，因此我为什么在这里。我主要在 Python 和 Pandas 中运行它，但它不仅限于这些语言/技术。

举个例子，让我们假设我有这个数据集：

| PID | A    | B    | C    |
| --- | ---- | ---- | ---- |
| 508 | 0.85 | 0.51 | 0.05 |
| 400 | 0.97 | 0.61 | 0.30 |
| 251 | 0.01 | 0.97 | 0.29 |
| 414 | 0.25 | 0.04 | 0.83 |
| 706 | 0.37 | 0.32 | 0.33 |
| 65  | 0.78 | 0.62 | 0.25 |
| 533 …