问题标签 [datamodel]

我有一个关于我想与 CoreData 一起使用的相当高级的 DataModel 的问题。

在详细介绍我到目前为止所做的事情之前，我将描述我想要做的事情。

我有一份入住一个房间并有偏好的酒店客人名单。一旦准备就绪，用户应该选择一个客人并查看数据，还应该能够添加新客人，选择房间（也由应用程序维护）并选择他们的偏好（用户还可以添加新的偏好）。客人可以没有或有很多偏好。

这就是我到目前为止所拥有的。我创建了 3 个实体： - 带有房间号的房间 - 带有名称的首选项 - 带有名称的 GuestInfo -> 带有这些关系房间（目标房间）和首选项（具有“多对关系”的目标偏好）

现在，我完成了所有这些并创建了托管对象类。到现在为止还挺好。问题是我收到了一些警告。

1. GuestInfo.room -- 关系没有逆关系
2. GuestInfo.prefs -- 多对多关系没有反向关系：这是一个高级设置（对于特定关系，没有对象可以位于多个目标中）

这只是我可以忽略的警告吗？我的意思是对于房间，每个客人总是只有一个房间号，但是一个房间可以有更多的客人，所以不能在这里放置任何反比关系。同样对于偏好，每位客人可以没有或更多偏好。

我们在数据模型图中指定的关系是什么？我也有一个疑问，我有三张桌子

表 A (emp Id(pk) ,name) 表 B (empId(pkfk),depno(pk),department) 表 C -( 包含办公室中的部门列表)

在表 B 创建中，我将 Fk 称为 empid.so 我绘制了表 A 和表 B 之间的关系。但是在表 B 部门是一个下拉列表，它包含表 c 中的部门列表。是否有必要指定表 b 和 c 之间的关系在层次结构数据模型中。

我试图确定在构建数据层时使用对象到关系映射层（如休眠或 Microsoft Entity 框架）是否有任何优势或劣势。

从长远来看，是手动使用 sql 和映射对象更好，还是利用其中一种映射技术更好？

对于简单的应用程序来说，额外的映射层似乎是有利的，因为该工具可以处理简单的映射和 sql，因此可以节省一些时间，但是当您的对象模型变得更加复杂时呢？

如果有的话，还有什么性能影响？

感谢您提供的任何见解。

我如何使用价值从 Cassandra 获取数据

我使用帖子ID获取帖子我可以获取与某些用户相关的帖子吗

我的意思是获取与 user_id=4 相关的帖子，例如示例（使用 user_id 属性查询）

毕业生

我的一位同事设计了一个表模式，在其中一个表中，列可以引用不同表中的主键取决于另一列的值。我知道这是不同的错误，但找不到支持我的理论。他的架构是这样的：

当item_type='V', 那么 item_id 是表视频的 id 并且item_type='A'当然后 item_id 是表视频的 id

( item_type, item_id) 的组合是唯一的，但实际上它根本不是外键，你不能将它定义为外键，因为它不指向单个表。DDL 语法不允许这样做。

有人可以找出这里违反了哪些原则或规则吗？

我正在研究不同类型的 NoSQL 数据库类型，并试图围绕列族存储的数据模型，例如 Bigtable、HBase 和 Cassandra。

第一个模型

有些人将列族描述为行的集合，其中每一行包含列^{[ 1 ]、[ 2 ]}。此模型的一个示例（列族为大写）：

第二个模型

其他网站将列族描述为一行 ^{[ 3 ]、[ 4 ]}中的一组相关列。上一个示例中的数据，以这种方式建模：

第一个模型背后的一个可能理由是，并非所有列族都具有 likeUSER和BOOKMARKdo 的关系。这意味着并非所有列族都包含相同的键。从这个角度来看，将列族放置在外层感觉更自然。

“列族”这个名称意味着一组列。这正是第二个模型中列族的呈现方式。

两种模型都是数据的有效表示。我意识到这些表示仅用于将数据传达给人类；应用程序不会以这种方式“思考”数据。

问题

列族的“标准”定义是什么？它是行的集合，还是一行中的一组相关列？

我必须写一篇关于这个主题的论文，所以我也对人们通常如何向其他人解释“列族”概念感兴趣。这两种模式似乎相互矛盾。我想使用“正确”或普遍接受的模型来描述列族商店。

更新

我已经决定使用第二种模型来解释我论文中的数据模型。我仍然对您如何向其他人解释列族商店的数据模型感兴趣。

我需要为类似 Amazon S3 的应用程序设计一个数据模型。让我们将问题简化为 3 个关键概念——用户、存储桶和对象。有很多方法可以设计这个模型——我将列出两种。

1. 三种类型 - 用户、存储桶和对象。每个 Object 都有一个 Bucket 作为其父对象。每个 Bucket 都有一个 User 作为其父级。用户是根。

2. 动态种类 - 用户存储在用户种类中，存储桶存储在桶种类中 - 与 #1 相同。但是，存储桶中的对象存储在名为“<BucketID>_Object”的动态类型中。桶和对象实体之间不再有父/子关系。这种关系是由对象种类的名称建立的。

#1 当然是更直观和传统的模型。有人可以说#2 是激进的，而其他人可能会说荒谬。

我为什么要考虑#2？- 在我的应用程序中，对象上定义的属性可能因存储桶而异。这些属性由用户在创建存储桶时指定。此外，对象的所有属性都必须是可查询的。每个桶的动态对象类型允许我支持这些要求。此外，因为我的对象种类现在是根种类，我不再需要应用祖先过滤器，这意味着我可以免费获得每个对象属性的索引。在模型 #1 中，我被迫应用祖先过滤器，这意味着我需要为每个要查询的属性创建一个自定义索引。

对于令人费解的解释，我深表歉意。如果不清楚，我会尝试更好。

我的问题是 - #2 是一个完全离谱的模型吗？使用#2，我的种类可能会达到成千上万。那样行吗？我了解自定义索引的数量是有限制的。但是我没有在我的动态类型上创建自定义索引，而只是依赖于自动索引。

谢谢， 凯尔

我正在为 PenWag.com 进行从 MySQL 到 Cassandra 的转换。在 Cassandra 中，我存储的是使用 GUID 键控的用户，但用户使用他们的电子邮件登录，而不是 GUID（显然）。GUID 作为用户的键对我来说比电子邮件更有意义，原因有两个。从实际的角度来看，更改或删除/添加包含所有 SuperColumns 的行似乎太麻烦了。从理论上讲，它仍然是同一个用户，为什么他们的密钥要改变？

不过，这是我的问题：我在单独的 ColumnFamily 中构建索引，映射电子邮件-> GUID 以支持登录。这是一个标准类型的 CF，其中列名是电子邮件，值是 GUID。避免为每个映射加载整个 SC 是标准的，而不是超级的。支持“更改电子邮件”很容易，它只是一个列删除/添加。但似乎另一种方法是将索引存储为行而不是列，其中行键是电子邮件，列保存 GUID。删除/添加这些行不会很麻烦，因为只有列（GUID）要管理。

似乎这两种方法都有效。各自的优缺点是什么？有最佳实践吗？

这是 Drew Sears 对此讨论的回答的后续问题：

App Engine 数据存储区 - 数据模型问题

如果我将存储桶建模为对象类型中的参考属性，并说我想查询存储桶 1234 中大小 > 1000 的对象。我的查询将类似于“其中存储桶 = key('Bucket', 1234) 和大小 > 1000” .

我假设这将需要对存储桶和大小属性的自定义索引。这个假设是错误的吗？如果不是，那么原始问题（动态类型）中的模型#2 是使其与自动索引一起使用的唯一方法吗？我希望有另一种方式。

谢谢， 凯尔

JSON 对于数据交换仍然变得越来越重要，但JSON 规范在某些方面相当松懈：

对象中的名称应该是唯一的。

一个实现可以对它接受的文本的大小设置限制。实现可以对最大嵌套深度设置限制。实现可以对数字范围设置限制。实现可以对字符串的长度和字符内容设置限制。

我认为大多数 JSON 解析器会忽略重复的对象键，并且不区分负零 (-0) 和零。大多数还可能将数字限制为 32 位浮点数或有符号整数。此外，JSON 允许包含无效的 Unicode 代码点的字符（请参阅此问题）。而且我敢打赌，在基本多语言平面（U+0000 到 U+FFFF）之上的 Unicode 字符可能会出现问题。但是 JSON 规范也不是这样，CouchDB、MongoDB、Persevere/Dojo 等 JSON 数据库也增加了限制：我怀疑您是否可以在所有 JSON 存储中使用对象键（如id、_id和） $ref，因为它们在每个系统中可能具有特殊含义。

这有点令人沮丧：JSON 应该很容易，但越仔细看，就会发现越多的障碍。是否有一个通用的（不太严格的）JSON 子集可以安全地在所有解析器和数据库中使用，或者 NoSQL 运动会添加越来越多的扩展和不应该在 JSON 文档中使用的特殊结构吗？