问题标签 [schema-design]

在 Solr 中，如果我们在 schema 中有一个字段为 stored="true"，并且我们更改了与该字段关联的分析器，是否可以只更新该字段而不重新索引所有文档？这是否可以在不返回原始数据源的情况下使用新分析器的字段“存储”值来完成？

我正在升级我不久前创建的支付管理系统。它目前对于它可以接受的每种付款类型都有一个表。它仅限于只能支付一件事，这次升级是为了缓解。我一直在寻求有关如何设计它的建议，并且我有以下基本想法可供参考：

1. 每种付款类型都有一个表格，每个表格都有一些常见的列。（当前设计）
2. 使用一个中央表协调所有付款，该表采用公共列（统一付款 ID，无论类型如何），并标识另一个表和行 ID，该表和行 ID 具有专门用于该付款类型的列。
3. 为所有支付类型设置一个表，并将未用于任何给定类型的列清空。
4. 使用中心表思想，但将专用列存储在键/值表中。

我的目标是：不要太慢，尽可能地自我记录，并在保持其他目标的同时最大限度地提高灵活性。

我不太喜欢 1，因为每个表中都有重复的列。它反映了支付类型类继承了一个基类，该基类为所有支付类型提供功能...... ORM 反过来？

我最倾向于 2，因为它与当前设计一样“类型安全”和自我记录。但是，与 1 一样，要添加新的付款类型，我需要添加一个新表。

我不喜欢 3，因为它“浪费空间”，而且还不清楚哪些列用于哪些支付类型。文档可以在一定程度上减轻这种痛苦，但是我公司的内部工具没有存储/查找技术文档的有效方法。

我对 4 给出的论点是，它可以减少在添加新支付方式时更改数据库的需要，但由于缺乏明确性，它比 3 更糟糕。目前，更改数据库不是问题，但如果我们决定开始让客户保留自己的数据库，这可能会成为后勤方面的噩梦。

所以，我当然有我的偏见。有没有人有更好的想法？你认为哪种设计最合适？我应该根据什么标准做出决定？

由于 SQLite 引擎不会截断您存储在文本列中的数据，因此在定义架构时指定列大小是否有任何优势？有人会喜欢这个吗：

对此：

为什么？

不具体有好处吗？

我正在开发一个论坛项目，该项目允许用户从他的网络中关注某些主题的问题。

用户的新闻源墙仅包含由他的联系人发布并标记在关注的主题上的那些问题。我很困惑什么数据库的数据模型最适合这样的应用程序。到目前为止，我一直在研究 Cassandra 和 MySQL 解决方案。

在我研究了 Cassandra 之后，我意识到通过对用户的所有关注者执行关于用户帖子的快速写入，使用 Cassandra 可以轻松设计显示所有来自网络的帖子的简单新闻提要设计。但是对于我这种有“关注主题”的附加过滤器的应用程序，我无法用 Cassandra 中的良好模式设计来说服自己。我希望如果我因为对 cassandra 的了解不足而错过了什么，也许你能帮我提出如何在 Cassandra 中实现这个新闻提要的建议吗？

我有以下表格；它将保存有关各种类型文章的信息。我需要一些帮助来为此提出适当的架构。

表格是：

插入测试数据：

由于这个 math_articles.title = 'fibonacci sequences' 提到了文章 'Leonardo of Pisa' 我的程序将在 other_articles 表中插入以下数据：

关于表引用的架构问题

由于表 other_articles.title = 'Leonardo of Pisa' 在表 math_articles.title = 'fibonacci sequences' 中被引用，我将在引用表中保存此引用，如下所示：

不确定/问题插入参考表

保存这些参考的最佳方法是什么？

我对引用表架构的问题！

• article_from_table_name 和 article_to_table_name 两列的数据类型是文本，但它们是我数据库中的实际表。
• from_id 和 to_id 应该是它们各自表的外键 from_id = article_from_table_name.id 和 to_id = article_to_table_name.id 我不知道如何在模式中定义它。

• 如果我删除文章 math_articles.title = 'fibonacci sequences' 那么引用表也将被更新，我知道我应该使用某种“ON DELETE CASCADE”触发器。

  • 问候

我有一个具有非常简单架构的 MySQL 数据库。有parent,child和access表。

parent存储 51 个字段varchar（长度范围从 16 到 512），除了 4 个longtext字段和主键是 a bigint。除了主键之外，还有其他 3 个字段的索引。一个以便child表可以将其作为外键引用。

child存储 23 个字段，其中大部分是varchar一些text字段。varchar(256)字段用作外键以将其链接到父级。不过，外键字段的实际内容都应少于 60 个字符。

accesss有一个bigint字段和一个varchar字段共同构成主键，该bigint字段是链接它的外键parent。

该access表用于指定哪些用户可以访问 中的哪些记录parent。可能有多个用户应该有权访问任何记录。

在parent （因此access）中有大约 2e6 行，在.中大约有 2e7 行child。编辑：对不起，access有 5329840 行。access即 . 中的每一行都有一行或多行parent。

上述架构基于我们希望迁移到 MySQL 的旧 FileMaker 数据库。我确信这并不理想，但我不知道具体原因。

根据参数，查询快或慢。因此，例如，如果有多个记录可以bob访问，则以下查询将需要一两秒钟。bob但是，如果没有用户可以访问的记录（例如，如果没有用户调用） ，查询将需要几分钟（例如 12 分钟bob）：

以下是EXPLAIN关于查询的内容：

那么，有什么方法可以加快不匹配的查询吗？这可能是由于对所有内容都使用 varchar/text 字段引起的吗？使用 varchar(256) 字段作为外键会导致问题（尽管在上面的查询中没有使用）？或者是查询的责任？

编辑：我刚刚意识到桌子上PRIMARY KEY ("RecordID", "UserName")的. 我已经在 UserName 列上创建了一个索引，这似乎已经解决了这个问题。如果有人有建议，我仍然会很感激。accessSELECT ... FROM access WHERE UserName = 'blah'

当前输出EXPLAIN：

编辑：@DRapp 的建议确实有很大的不同。无论是否使用 access.UserName 上的索引，查询都很快。如果我删除索引并尝试不带 DRapp 的查询STRAIGHT_JOIN，那么它又会变慢。

DRapp 的查询没有关于 access.UserName 的索引：

与索引相同的查询access.UserName：

access.UserName没有索引和没有索引的相同查询STRAIGHT_JOIN：

我试图弄清楚如何最好地将 MongoDB 用于一个非常小而简单的用例，但发现文档有些令人困惑。我的文档应该代表一个用户可以拥有许多电子邮件的事实。如果我遵循文档，最明显和最简单的解决方案是使用嵌入。问题是当我想验证电子邮件地址的唯一性时，这是 AFAIK 无法使用嵌入的（当然我可以使用 map/reduce，但这似乎是一个非常糟糕的选择）。

我绝对觉得电子邮件不值得拥有自己的收藏，但显然嵌入式对象不允许我进行验证（如果确实如此，我真的不相信它会有效）。在这种情况下，您将如何设计架构？

对具有多个一对多关系的 1 个表进行建模的最佳方法是什么。

使用上述模式，如果 Report 包含 1 行，Grant 2 行和 Donation 12。当我将这三者连接在一起时，我最终得到一个笛卡尔积和 24 的结果集。 Report 加入 Grant 并创建 2 行，然后 Donation 加入该行做24行。

有没有更好的方法来模拟这个以避免caresian product？

示例代码

更新 1 2011-03-07 15:20

为到目前为止的反馈干杯，为了添加到这个场景中，还有 15 个其他的一对多关系来自一个报告表。由于各种业务原因，这些表不能组合在一起。

我有一个存储“比赛”的表格，这些比赛有以下列：MatchId、TeamA、TeamB、Wager、Winner

我希望能够让 TeamA 和 TeamB 返回每支球队的球员名单。每个人的数量都可以是任意的，这可能甚至实用吗？我想不出任何其他的设计方式。有没有更好的模式呢？球员将是 UserId 的，用户不绑定到球队，球队只是相对于比赛。

编辑：例如，玩家 A、B、C、D、E、F

第一场比赛：3v3 ABC vs DEF

比赛2：3v3 DAB vs FEC

玩家不应绑定到任何特定的 TeamId，因为它仅取决于比赛。玩家可以在比赛中与他或她想要的任何人组队。

我有一个现有的成熟模式，我们需要向其中添加一些新的产品属性。例如，我们有 Products.Flavor，现在需要添加新的属性，如重量、香味等。与其继续扩大 Products 表，我正在考虑其他几个选项。首先是一个新的 Attributes 表，它将有效地成为任意属性的属性包，以及一个 ProductsAttributes 表，用于存储特定产品属性的映射（和值）。这是实体-属性-值 (EAV) 模式，正如我所理解的那样。另一个选项是向 Products 表中添加一个名为 Attributes 的新列，该列是 XML 类型的。在这里，我们可以在不添加新表的情况下，任意给任何产品实例添加属性。

每种方法的优点/缺点是什么？我正在使用 SQL Server 2008 和 ASP.NET 4.0。