问题标签 [rdbms-agnostic]

您经常看到数据库字段设置为 255 个字符，传统/历史原因是什么？我认为这与分页/内存限制和性能有关，但 255 和 256 之间的区别一直让我感到困惑。

考虑到这是容量或量级，而不是索引器，为什么 255 比 256 更受欢迎？是否为某种目的保留了一个字节（终止符或空值之类的）？

大概 varchar(0) 是胡说八道（容量为零）？在哪种情况下 2^8 的空间肯定应该是 256？

是否有其他数量级可以提供性能优势？例如，varchar(512) 的性能是否低于 varchar(511) 或 varchar(510)？

对于所有新旧关系数据库，此值是否相同？

免责声明- 我是一名开发人员而不是 DBA，我使用适合我的已知业务逻辑的字段大小和类型，但我想知道这种偏好的历史原因，即使它不再相关（但即使如果它仍然相关，则更多）。

编辑：

感谢您的回答，似乎有一些共识是使用一个字节来存储大小，但这并没有在我心中明确解决这个问题。

如果元数据（字符串长度）存储在同一个连续的内存/磁盘中，这是有道理的。1 个字节的元数据和 255 个字节的字符串数据，非常适合彼此，并且适合 256 个连续字节的存储，这大概是整洁的。

但是......如果元数据（字符串长度）与实际字符串数据（可能在主表中）分开存储，那么将字符串数据的长度限制为一个字节，只是因为只存储一个字节整数更容易元数据似乎有点奇怪。

在这两种情况下，这似乎是一个微妙之处，可能取决于数据库的实现。使用 255 的做法似乎很普遍，所以一开始一定有人在某个地方为它争论过一个好案例，有人能记得那个案例是什么吗？程序员不会无缘无故地采用任何新的做法，而且这一定是新的。

这是一些一直给我带来麻烦的基本数据库问题。我曾尝试使用 google 和 wiki，但不知何故我错过了理解功能而不是术语。

如果可能的话，如果有人可以使用一些具有代表性的视觉示例分享有关此问题的更多见解，我将不胜感激。

• 什么是钥匙？候选键？主键？备用钥匙？外键？

• 什么是索引，它如何帮助您的数据库？

• 有哪些可用的数据类型以及何时使用哪些数据类型？

当第二个表中没有匹配项时，我想从一个表中检索所有记录。

所以它有点与内部连接相反。

我正在开发一个用于质量控制清单的网络应用程序。我已经建立了一个表格，但我有一种预感，我们的模型是次优的，我可以获得更好的性能。请不要说我正在使用 mysql，所以我仅限于它的功能。

每个清单都有几十个，有时甚至是数百个问题。每个问题有 2 到 10 个可能的答案。每个问题都是一个 varchar 字符串，每个答案也是如此。完整的清单是当所有问题与其可能的答案之一相关联时 - 选择一个答案。

清单因不同的目的而有所不同，并且会随着时间而改变。因此，当我们想要更改新的清单时，为了防止已完成的清单不小心更改，我们有模板。模板、问题和答案是清单、问题和答案的镜像，代表清单的“当前版本”。

所以表层次结构看起来像这样

. 客户

• 模板
  • 模板问题
    • 模板问题答案
• 清单
  • 清单问题
    • 清单问题解答

因为我们不希望当前模板中的更改“回到过去”并更改已完成的清单，所以当用户开始新的清单时，数据会从模板复制到清单中。

你可以猜到，这会产生很多重复。在 ChecklistQuestionAnswers 中，在大约一百万行答案中，只有 4,000 个不同的答案。当然，TemplatesQuestionAnswers 也有重复，但没有那么糟糕。

所以我想我想做的是为清单模板创建一个版本控制系统，这样我就可以通过只存储具有唯一答案集的唯一问题来节省空间。这样，我就可以将清单与模板版本链接起来，而不是大量复制文本，然后清单集就是为哪个问题选择了哪个答案。

这是我到目前为止所勾勒出来的。

一个客户有很多模板。一个模板有许多修订版，但只有一个当前修订版。每个修订版都有很多问题，每个问题都有很多（2 到 10 个）答案。每个清单与一个模板相关。每个清单都有一组答案，指示在其模板版本中为每个问题选择的答案。

我被挂断的问题是保证 ChecklistAnswers 关联正确的问答对——存在于它的 Checklist 父级引用的模板版本中的关系。

换句话说，ChecklistAnswers 中的每一行都必须将来自 TemplateQuestions 的 question_id“镜像”到来自 TemplateQuestionAnswers 的一个子问题，形成 Checklists 中的 template_version。我正在尝试思考如何做到这一点，而我的思维过程在这里短路。这实际上是数据库的“可交付成果”——一份完整的清单——所以所有其他模板和一切都是附带的或抽象的。如果我不能让这个工作，我就错过了重点！

这似乎有点笨拙，所以我想知道我是否正在制定一个解决方案，其复杂性不值得我通过实施它节省空间。

另请注意，我已经简化了一点。还有其他方面的复杂性，例如用于对报告问题进行分组的类别系统，但我认为我们不需要在这里深入探讨。

我们能否得到一份基本优化技术的列表（从建模到查询、创建索引、视图到查询优化）。最好列出这些，每个答案一种技术。作为一个爱好者，我会发现这非常有用，谢谢。

为了不太模糊，假设我们正在使用主流数据库，例如 MySQL 或 Oracle，并且该数据库将包含大约 10 个表中的 500,000-1m 左右的记录，其中一些具有外键约束，全部使用最典型的存储引擎（例如：InnoDB for MySQL）。当然，还定义了诸如 PK 之类的基础知识以及 FK 约束。

我有一个类似这样的存储过程（伪代码）

很长一段时间都运行良好。突然，如果 param4 为“Y”，查询将永远运行。将代码更改为：

它会在预期参数内再次运行（40,000 多条记录需要 15 秒左右）。这是 SQL Server 2005 的问题。我的问题的要点是 SQL Server 特有的这个特殊“功能”，或者这是 RDBMS 中的一个常见功能，一般来说：

1. 随着数据的增长，运行良好两年的查询将停止工作。
2. “新”执行计划破坏了数据库服务器执行查询的能力，即使逻辑上等效的替代方案运行得很好？

这似乎是对 SQL Server 的咆哮，我想在某种程度上确实如此，但我真的很想知道其他人是否在使用 Oracle、DB2 或任何其他 RDBMS 时体验过这种现实。虽然我和别人有过一些经验，但是我只在SQL Server上看到过这种体积和复杂度，所以我很好奇其他拥有大型复杂数据库的人是否在其他产品中也有类似的经验。

假设我有一个包含 100 条记录的表 X，并且运行 aselect * from X需要 100 秒。

我应该期望查询需要多长时间select top 10 * from X？

我希望这种关系或多或少是线性的，所以 10 秒。这是正确的，还是关系在某种程度上是非线性的？

不用担心！它看起来比实际上更复杂！只是去喝酒！

TLDR-version：如何有效地查询和更新与其他实体有关系的实体？

这是一个有趣的数据建模场景，其中包含两个让我感到困惑的表：

AggregateEntityID并且ComponentEntityID是表的外键Entities。

给我一个血淋淋的例子

如果我们想获得血腥玛丽的酒精含量，我们会的SELECT * FROM DrinkIngredients WHERE CocktailID == 4。

相当标准；没有什么奇怪的。Lisa 喜欢通过添加一些 Passion 来让它更甜一点：

丽莎的妈妈已经品尝了很长时间，以至于她相信她已经找到了两者之间的终极融合：

添加更多这些由级别组成，我们有一个深度关系递归。唯一的限制是实体不能由自身组成。

这似乎形成了一个有向无环图。

RDBMS：“缓存”数据的一种方法是计算相关数据并将其存储在实体本身（或者可能在另一个表中）。在上面的示例中，血腥玛丽的酒精含量将在创建并存储在其酒精百分比字段中时计算一次。在这种情况下，更新变得昂贵，因为我们必须更新由更新的饮料组成的每一种饮料（以及整个依赖层次结构）。

问题

RDBMS：有没有更好的方法来获得叶值（不包含其他值的饮料）而不是在达到叶饮料之前获得“父”饮料？

RDBMS 和 NoSQL 都存在这样的问题：一种方式或另一种方式。

底线：这是否实际可行？

我需要的是一个反盗版

a) 我有 1000000 个域名

b) 每个域有大约 100000 个站点

c) 每个站点每天大约有 10000 次访问/（每天 5000 次独立访问）

d) 作为所有这些网站的所有者，我想查看在选定的时间段内我在选定的网站上有多少访问者，例如：

从 1987 年 12 月 4 日到 2010 年 4 月 23 日，mydomain.com/tutorials 上的唯一身份访问者有多少

从 1996 年 8 月 30 日到 2009 年 7 月 16 日，yourdomain.com/reference 上的唯一身份访问者有多少？

对于传统的 SQL 数据库来说，这是一种痛苦。

什么是最聪明的方法？使用什么存储引擎？

我只有 SQL 知识。非常感谢任何其他资源。

由于它可能导致的问题，这种情况发生的可能性对我来说似乎极不可能，但我想我还是会问这个问题......

想象一个涉及自动增量 ID 并分配值的事务。在 COMMIT 之前，涉及的代码会缓存分配的 ID 的副本以供以后参考。然后提交事务。

假设没有直接的客户干预（删除或更改记录），是否有任何数据库或情况会在提交后立即自动更改 ID 值，从而使缓存的 ID 不正确？在事务中缓存 ID 总是安全的吗？

我可以想象发生这种情况的一个假设情况是，如果某些 RDBMS 实现莫名其妙地决定有必要具有无间隙且与时间相关的自动增量值（因为我看到很多人想要这个的例子）。在这个假设的情况下，我可以想象可能会对 ID 进行一些神奇的洗牌，以填补由另一个事务（或其他间隙原因）中的后 ID 分配回滚引起的间隙。这将使缓存的值无效。

任何人都知道这样的实现，或其他缓存杀手？