标签: database-design

我正在与其他人一起创建 SQL Server 数据库。其中一个表很小（6 行），其中的数据可能会保持不变。添加新行的可能性很小。该表看起来像这样：

CREATE TABLE someTable (
    id int primary key identity(1,1) not null,
    name varchar(128) not null unique
    );
INSERT INTO someTable values ('alice', 'bob something', 'charles can dance', 'dugan was here');

我正在查看该name列的字符长度，我认为它的值可能永远不会大于 32 个字符，甚至可能不会大于 24。我将此列更改为，有什么好处，例如，varchar(32)？

另外，将默认列大小保持为 4、8、32 等的倍数有什么好处吗？

我们有一种情况，我们可以 (A) 使用表前缀在一个 MySQL 数据库中部署应用程序的实例，或者 (B) 为应用程序的每个实例使用不同的 MySQL 数据库，例如，

设置“A”：

central_database
  app1_table1
  app1_table2
  app1_tablen
...
  appn_table1
  appn_table2
  appn_tablen

最终结果是一个包含许多表的大数据库。

设置“B”：

app1_db
  table1
  table2
  tablen

...

appn_db
  table1
  table2
  tablen

最终结果是许多带有一些表的数据库。

所有条件都相同（例如，数据量、应用程序实例数量等），使用这两种方法的优缺点是什么？什么会对数据库性能和维护有害？该应用程序基于 PHP 5，在 Apache 2.x 上运行，我们运行的是 MySQL 5.x。

非常感谢您的时间和想法！

我正在考虑将基于 VB 的本地（本地安装）应用程序（发票+库存）重写为面向小型企业客户的基于 Web 的 Clojure 应用程序。我打算将其作为 SaaS 应用程序提供给类似行业的客户。

我正在查看数据库选项：我的选择是 RDBMS：Postgresql/MySQL。我可能会在第一年扩大到 400 个用户，通常每个用户每天 20-40 个页面浏览量 - 主要用于交易而不是静态浏览。每个视图都将涉及获取数据和更新数据。符合 ACID 是必要的（或者我认为）。所以交易量并不大。

根据我的偏好选择其中任何一个是不费吹灰之力的，但对于这一要求，我认为这是 SaaS 应用程序的典型特征：随着我添加更多客户/用户以及每个客户的需求，架构将发生变化不断变化的业务需求（我将提供一些有限的灵活性，只是在开始时）。由于我不是数据库专家，根据我能想到和读到的内容，我可以通过多种方式处理这个问题：

1. 在 MySQl/Postgresql 中有一个传统的 RDBMS 模式设计，单个 DB 托管多个租户。并在每个表中添加足够的“自由浮动”列，以便在我添加更多客户或为现有客户进行更改时进行更改。每次对架构进行小的更改时，这可能会带来将更改传播到数据库的缺点。我记得在 Postgresql 中读到可以在不锁定的情况下实时更新模式。但不确定在这个用例中它有多痛苦或有多实用。而且，由于架构更改也可能会引入新的/次要的 SQL 更改。
2. 拥有 RDBMS，但以灵活的方式设计数据库模式：接近实体属性值或仅作为键值存储。（例如工作日，FriendFeed）
3. 将整个事物作为对象存储在内存中，并定期将它们存储在日志文件中。（例如，edval、lmax）
4. 选择像 MongoDB 或 Redis 这样的 NoSQL DB。但是根据我所能收集到的信息，它们不适合这个用例并且不完全符合 ACID。
5. 选择一些 NewSQL Dbs，如 VoltDb 或 JustoneDb（基于云的），它们保留了 SQL 和 ACID 兼容行为并且是“新一代”RDBMS。
6. 我查看了 neo4j(graphdb)，但不确定它是否适合这个用例

在我的用例中，不仅仅是可扩展性或分布式计算，我正在寻找一种更好的方法来实现“架构的灵活性 + ACID + 一些合理的性能”。我在网上可以找到的大多数文章都将模式的灵活性作为导致性能（在 NoSQL DB 的情况下）和可伸缩性的原因，同时忽略了 ACID/事务方面。

这是“架构灵活性与 ACID”事务的“非此即彼”案例还是有更好的出路？

我有一个很长的 html 页面，几组问题分为小部分（一页大约有 15 个子部分），问题总数约为 100 个问题：从输入、多选、复选框、单选按钮、文本区域、和文件上传。一个问题可以包含许多答案，这些答案可以从一组复选框、一组选择列表、一组多选或所有这些组合成一个答案中获得。我以为我会在下面使用这个数据库设计，但最近发现这毕竟不是一个好方法。

1. 一个客户只能有一组问题：每 100 个问题就有一个客户。
2. 对于旧方法，我不会在数据库中保留问题，而是在 PHP 编码中指定为常量。问题是我必须比较 PHP 中的问题才能使其与数据库中的答案同步。如果某个问题已从 PHP 中更改/删除/移动，我肯定会迷失在将其与问卷数据库中的答案匹配的情况下。更好的解决方案？
3. 我能否将从表单中的多个元素获得的多个答案保存在一个字段中作为一个答案？如何检索此字段并再次显示以供客户在表单上查看？
4. 我应该选择下面的哪个选项？

选项 1：旧方法（1 桌）

表格：问卷

• 身份证（PK）
• 顾客ID
• 地位
• A1
• A2
• A3
• .
• .
• .
• A100

选项 2：新方法（2 个表）

表格：问题

• QID（PK）
• 问题（varchar）

表：答案

• 援助（PK）
• 顾客ID
• QID（整数）
• 答案（varchar）

还是选项3？

我已经开始处理一个现有项目，之前的开发人员已将一个表拆分为 10 个单独的表，这些表具有相同的模式但数据不同。

表格如下所示：

[tableName_0]
[tableName_1]
[tableName_2]
[tableName_3]
[tableName_4]
[tableName_5]
[tableName_6]
[tableName_7]
[tableName_8]
[tableName_9]

主键是一个整数id字段。该应用程序使用哈希算法 ( idmod 10) 来了解在进行查找时要访问的表。例如id= 10 将导致[tableName_0].

结合起来，这些表大约有 100,000 行，增长率相对较低。

所以，我的问题是这是否是一个可行的解决方案，或者它是否在任何情况下都是一个很好的做法。我的理论是推动将它们结合起来，因为它会使事情变得更容易UNION，等等。主要的缺点是更改所有应用程序代码以及从长远来看是否值得。

我从政府机构的信息系统中请求概念图式用于我的研究。我的请求因存在安全风险而被拒绝。

我真的没有丰富的数据库经验，所以我无法验证这个说法。公开你的架构真的有那么大的安全风险吗？我的意思是，这些非常抽象，并且与硬件和软件实现脱节。对攻击者如何利用概念模式的解释将不胜感激。谢谢。

array列有上限吗？

插入数组字段时出现此错误 -

PG::Error: ERROR:  index row size 3480 exceeds maximum 2712 for index "ix_data"

这是我的表定义 -

create table test_array(id varchar(50), data text[]);

ALTER TABLE test_array ADD PRIMARY KEY (id);

CREATE INDEX ix_data ON test_array USING GIN (data);

我需要数组字段的索引，因为我正在对它进行一些查找。

表之间的外键是否应该链接到自然键或代理键是否有最佳实践？我真正找到的唯一讨论（除非我的 google-fu 缺失）是Jack Douglas 在这个问题中的回答，他的推理对我来说似乎是合理的。我知道除了规则改变之外的讨论，但这在任何情况下都需要考虑。

提出这个问题的主要原因是我有一个遗留应用程序，它使用带有自然键的 FK，但是开发人员强烈推动转向 OR/M（在我们的例子中是 NHibernate），并且一个 fork 已经产生了一些破坏性更改，因此我希望使用自然键将它们推回正轨，或者移动旧应用程序以使用 FK 的代理键。我的直觉告诉我要恢复原始的 FK，但老实说，我不确定这是否真的是正确的道路。

我们的大多数表都已经定义了代理键和自然键（尽管是唯一约束和 PK），因此在这种情况下，必须添加额外的列对我们来说不是问题。我们使用的是 SQL Server 2008，但我希望这对于任何数据库都足够通用。

假设我有一个包含用户信息的大表和另一个包含多个位置的表。然后我使用另一个包含 user_id 和 location_id 的表。

为了检索数据，我必须使用 Left Join 查询。与将所有内容放在一张桌子中相比，这不是使整个过程更长的检索时间吗？例如，我可以将位置作为文本放在同一张桌子上。

编辑：这是一个例子。

CREATE TABLE  `user` (
`id` int(11) NOT NULL,
  `name` varchar(45) DEFAULT NULL,
  `gender` enum('M','F') DEFAULT NULL
);

CREATE TABLE `user_location` (
  `user_id` int(11) NOT NULL,
  `location_id` int(11) NOT NULL
);

CREATE TABLE `location` (
`id` int(11) NOT NULL,
  `location` varchar(45),
  `parent_id` varchar(45) 
);

注意：请假设所有相关字段都在它们之间正确索引。

编辑：我目前有一个大型数据库，用户通过如上所述的连接表检索他们的位置。我被要求优化数据库，因为搜索结果很慢。我添加了memcache它并且它有了显着的改进，但现在我只是想知道左连接。

例如，当前查询是这样的：

SELECT * FROM users 
LEFT JOIN user_location 
ON user_location.user_id = user.id 
LEFT JOIN location
ON location.id = user_location.location_id;

这只是为了获取位置。它们还有其他几个通过联结检索的字段，并且都需要它们来查看用户的个人资料。我们的电话号码、地址、密码、出生日期和许多其他信息都在不同的表格中。

为了让我为用户配置文件创建一个页面，我必须向服务器发送一个大型查询。现在在第一次被缓存之后就可以了。但我只是想知道为什么有人会像这样构建他们的数据库？

考虑一个prices包含这些列的表：

id         integer primary key
product_id integer -- foreign key
start_date date not null
end_date   date not null
quantity   integer
price      numeric

我希望数据库强制执行这样的规则，即产品在日期范围内（通过where <date> BETWEEN start_date AND end_date）的特定数量只能有一个价格。

这种基于范围的约束可行吗？