问题标签 [database-agnostic]

如果我有两个具有多对多关系的对象，我通常会在我的数据库模式中使用多对多表对它们进行建模以将两者关联起来。但是该多对多表（或“连接表”）是否应该有自己的主键（整数自动递增）？

例如，我可能有表 A 和 B，每个表都有一个 ID，还有一个名为 A_B 的表，其外键元组为 (A_ID, B_ID)。但是 A_B 是否应该有一个自己的主键自动递增 ID 列？

添加它的优点和缺点是什么？我个人喜欢多对多连接的自然键。但是主键会增加什么额外的好处呢？

我在这里很困惑。

我有 2 个表，我将第一个（大约 50 万条记录）与第二个（大约 220 万条记录）连接起来，以便找出哪些记录在第一个而不是第二个。（典型的“b.attribute is null”废话）

为什么（如何）在第一个表上使用索引？无论如何，它必须遍历第一个表中的每条记录，但是当我尝试在第一个表上没有任何索引（或主键..不需要，因为这只是 ETL）的情况下进行此连接时，它会爬行。

顺便说一句，使用innodb。

帮助？

编辑：第二张表被索引。第一个不是。

Hibernate 的CriteriaAPI 具有Restrictions.ilike以下功能：

不区分大小写的“like”，类似于 Postgres ilike 运算符

这很酷。但是同一个类也有like功能，合同更加模糊：

对命名属性应用“like”约束

例子

现在它生成像

它是非常特定于 SQL Server 的。我想创建一个每个人都可以使用的脚本，与数据库无关。我有非常简单的数据类型 - varchars、数字、日期、位（布尔值）。

我认为

应该适用于所有 DBMS，对吧？

我有一堆产品，每个产品都有一堆不同的可能属性。例如，产品 A 有名称、尺寸、颜色、形状。产品 B 有名称、卡路里、糖分等。解决此问题的一种方法是：

1) 创建表

这允许最大的灵活性，但我听说很多人反对这样做，尽管我不知道为什么。我的意思是，如果这些表被称为 Teams、Players、Team_Players，我们都会同意这是正确的关系设计。

每个向我解释为什么这很糟糕的人都是在完全灵活的关系设计的上下文中这样做的，在这种设计中，您永远不会通过基本的几个基本初始表（例如 object、attribute、object_attribute）创建真正的表——我认为我们所有人都同意是坏的。但这是一个更受限制和包含的版本（只有产品，而不是系统中的每个对象），所以我认为将这两种架构组合在一起是不公平的。

你遇到了什么问题（经验或理论）使这个设计如此糟糕？

2）解决这个问题的另一种方法是创建一个 Product 表，其中包含一堆列，如大小、颜色、形状、重量、糖等，然后在最后包含一些额外的列，以给我们一些灵活性。这将创建通常由 NULL 填充的稀疏行。人们倾向于喜欢这种方法，但我的问题是，在这种方法失去其性能优势之前，您可以拥有多少列？如果你有 200 列，我想这不再是明智之举，但是 100 列呢？50列？25列？

3) 我知道的最后一种方法是将所有属性作为 blob（也许是 JSON）存储在 Products 表的单个列中。我喜欢这种方法，但感觉不对。查询很难。而且，如果您希望以后能够轻松更改属性的名称，则必须单独解析每条记录，或者通过某个 id 将它们键入您的 blob。如果您使用 id 路径，那么您将需要另一个表 Attributes 并且事情开始看起来像上面的方法＃1，除了您将无法将 attribute_id 与您的 blob 连接，所以我希望您不想查询任何内容按属性名称。

我喜欢这种方法的地方在于您可以查询一个产品，并且在您的代码中您可以轻松地访问它拥有的所有属性——快速。而且，如果您删除了一个产品，您就不必清理其他表——很容易保持一致。

4) 我已经阅读了一些关于能够在某些 RDBMS 中索引强类型 xml 格式的内容，但老实说，我对这种方法知之甚少。

我被困住了。我觉得方法 #1 是最好的选择，但我读到的所有内容都这么说很臭。思考这个问题的正确方法是什么，以便能够决定在给定情况下什么是最佳方法？显然欢迎比我列出的更多的想法！

我有一个工作得很好的方法（使用 rails 3 和 PostgreSQL）；我只是想知道是否有可能使其与数据库无关：

据我了解，从日期中提取一周 ISO 编号的方法始终是特定于数据库的。

我可以使用虚拟属性 :week 之类的东西，如此处所示，但似乎 :group 选项只接受原始 SQL。我也看到了这个解决方案，但它不符合我的需求。另一种方法是使用数据库视图，甚至添加一个由回调方法填充的 :week 列 - 但我不想弄乱我的模式。

那么，有什么线索吗？

在数据库中存储枚举类型有两种方法：作为字符串或作为整数。

将枚举 ( sex = {male,female}, account_type = {regular,pro,admin}, 等 ) 保存为字符串可以使内容更具可读性，但比整数需要更多空间。

另一方面，整数需要将枚举映射进出数据库。作为一个好处，区分大小写是在数据库之外用整数处理的。

假设两者都被索引，那么进行整数转换通常值得吗？使用整数查找要快多少？

例子

也许一个具体的例子可以帮助可视化事物。让我们将上面的 account_type 与 100,000 个用户的数据库一起使用。

字符串枚举

假设 8 位固定长度 CHAR 类型

整数枚举

假设 8 位 TINYINT 整数

似乎大小几乎是整数枚举的一半。还需要考虑索引。

我在我的一个模型中定义了以下默认范围

它在我运行 MySQL 的开发机器上运行良好，但在部署到我们使用 postgres 的生产环境时出现故障。有没有办法使用 Arel 而不是直接 SQL 来编写它？FORMATS[:wide]返回一个整数，但它可能没有任何特定的顺序。我只想format先返回具有该特定内容的记录。

我知道以前有人问过这类问题，但我找不到一个可以比较我想到的选项的问题。所以我把它们贴在这里，如果有重复，请发布链接。

这已经结束了一个相当长的帖子，如果你有时间请阅读它，因为问题在最后

EDIT2：我已经接受了一个答案，因为我认为这将是目前最好的解决方案。但我想我想回答我关于连接数字的查询的另外两个问题。它们可以在这里找到：结合两个整数来创建一个唯一的数字&在 C# 中连接整数。如果我要尝试对数字进行编码（如下所示，如 51122222），我认为这会很有用。虽然对于我的小型应用程序来说，也许只是在 c# 中使用类似 String.Format 之类的东西就足够快了。

我目前正在尝试找到一种方法来设置分布式应用程序，这些应用程序使用相同的数据库模式，并且可以与一个主数据库同步，所有其他数据库也与之同步。

我目前计划的程序将作为一个相当简单的程序来跟踪信息。第一个版本可能包含两个表：Items 和 ItemHistory。这是可能字段的示例：

物品
ItemID(PK) ?
名称字符串
内容字符串

ItemHistory
ItemHistoryID (PK) ?
物品 ID (FK) ?
EventName String
CreatedOn 日期时间

我已经列出了字段名称和类型，这个问题是关于 PK 类型使用什么，所以它们丢失了。

第一个版本将是一个标准的桌面应用程序，我目前正计划将 C# 与 WPF 前端和 SQLite 用于数据库。最后，我还想创建一个可以在我的 Android 手机上运行的版本。这就是分布式部分的用武之地。我并不总是有信号，因此需要应用程序离线运行并在再次在线时允许同步。

以下是我目前关于如何处理 ID 的想法：

1. 对 ID 使用 UUID，这样就不会发生合并冲突
2. 使用自动增量字段并以某种增量设置每个版本的应用程序的起始编号，例如，第一个应用程序为 1，第二个应用程序为 10000，第三个应用程序为 20000，等等
3. 使用带有偏移值的自动增量字段来避免数字之间没有大间隙的冲突（mysql为此具有auto_increment_increment和auto_increment_offset）
4. 生成我自己的 ID，为每个数据库编码一个 ID，这样它们就可以有自己的自动增量值而不会引起冲突。我发现其他人也有同样的想法：ID 列推荐使用哪种数据类型？

虽然选项 1 会起作用并且我过去曾使用过它，但我想看看其他选项的可能性以避免 UUID 的问题。我想要一个在调试时更易于阅读且可排序的解决方案。

选项 2 会起作用，但它确实会限制记录的数量。我知道在我的小型应用程序中它几乎永远不会超过那么多，但我想尝试看看是否有不需要这样限制的解决方案。选项 3 通过使用交替数字来避免限制，但我认为您需要知道要使用多少个数据库，否则您可能会填写所有数字。在 DB1 上使用 1 开头和 1 增量，在 DB2 上使用 2 开头和 2 增量将交替使用每个数字。您可以使用 50 作为增量，但您只有另一个限制，但现在是可以使用它的应用程序数量。我再次知道它的限制在我的情况下不会受到影响，但在突然变得非常流行的应用程序中可能是一个问题。

选项 4 似乎可以为我解决问题，但我不确定它在实践中是否有效。我的一个想法是允许在每个应用程序上设置一个前缀，然后可以将其与自动递增值一起使用。例如，PC1、PC2 用于 PC 上的记录，可能 PHONE1、PHONE2 等用于来自 Android 的记录。这会起作用，但在字符串中使用数字会导致排序问题，1、11、100 彼此相邻显示，即使用较少的前导零，然后再次返回到有限数量的记录。

我想知道是否可以为 DB ID 和自动增量使用一个数字。例如，PC = 1 和 PHONE = 2。然后我们有 11、12、13 等用于 PC，第 11 条记录可能有 111，而 PHONE 上的第 304 条记录可能有 2304。但我不知道这将如何完成，或者是否可以轻松完成并且不会导致产生价值的额外开销。

在工作中，他们使用了类似的编号系统，他们使用类似 51122222 的东西。5 指的是应用程序的实例，然后是 2 位数的年份，最后是自动递增的数字。我还没有一个明确的答案，如果我们在一年内超过 99999 条记录会发生什么。我认为他们可能认为这不会发生，并且很高兴他们已经计算了风险。

所以最后一个问题，有没有办法为分布式应用程序创建一个主键系统，允许排序并且不强制限制（除了数据类型本身的大小，例如最大整数）？

编辑：这是我计划编写的应用程序的更多信息。我想创建一些东西，让我可以存储我可能获得的任何类型的信息，系统将包括标记条目的能力，以便我可以搜索一个主题。到目前为止，我看到的信息类型可能是关于书籍、dvd、网站等的推荐。或者可能是我居住地的本地提示。一个总体思路是停止让这些信息以不同的格式分布在多台计算机/笔记本电脑/手机上。

如果我做

这两个字段在两列中是否总是相同的？

同上

所有四个数据库条目是否都具有相同的值，或者 row1 <> row2 是否可能？

请注意，这是一个理论问题，而不是一个work-around问题。
我真的很想知道如何以及为什么。