密钥重复的成本

Question

我有一个存储在SQL中的地址簿（好吧，事实是我有一些比地址簿更复杂的东西，但我的问题适用于地址簿:)）。它将名称映射到电话号码。为了便于讨论，我们假设我们使用固定大小的字段，并且一行占用磁盘上的100个字节。 现在，我发现自己需要多个地址簿，每个应用程序的用户一个。用户由16字节GUID标识。我想我应该在“地址簿”表中添加一列，以便我有“UserID，Name，PhoneNumber”。 我关心磁盘上数据库的大小，我相信添加UerID列会使DB的大小增加16％。对于单个用户，这似乎很愚蠢（在DB的每一行上重复相同的UserID）。

典型的SQL实现是否可以做任何事情来避免在表中的多行上重复相同值的成本？ 是否有更好的方法来布局数据以避免成本？

Answer 1

您的问题是关于磁盘上的存储。唉，这取决于数据库。通常，数据库将使用16个字节存储GUID。如果GUID是一个字符串，那么一些数据库可能会进行某种压缩＆＃34;压缩＆＃34;在重复值只存储一次的页面上。列式数据库可能会在任何有价值的时间进行压缩。您没有指定您正在使用的数据库，因此其中一个可能适用。

表占用磁盘的空间量可能与您的需求无关。大多数数据库为表预先分配表空间。空间分为页面，表空间中有许多未使用的页面。数据库的关键之一是管理这个内存层次结构。我不担心每条记录增加16个字节。好吧，如果附加数据是一组适合1或2个字节的标志，我可能会有数以千万计的记录。然后开销会很多。虽然有些SQL引擎使用的模型中每个表都在一个单独的文件中（MS Access），但是有很多更强大的免费引擎（MySQL，SQLite，Postgres，SQL Server Express，Oracle Express，毫无疑问是其他引擎）。

如果由于某种原因，你真的关心磁盘空间的物理使用，我建议使用像ParAccel或Vertica这样的柱状数据库。

对于内部数据库结构，通常建议使用整数键。它们对连接更有效，并且占用更少的空间。如果每个用户有多个地址簿，那么我建议您将单个表分成两个表：Users和UserAddressBooks。第一个将自动递增的id列存储为整数。第二个将此id作为列以及您想要的其他信息。我会稍微推荐一下性能，但更多是因为它更好地实现了逻辑数据模型。