问题标签 [database-design]

假设我有可能与Bravo或 Charlie 的事物相关或无关的 Alpha 事物。

这些是一对一的关系：没有任何 Alpha 与一个以上的 Bravo 相关。没有 Bravo 与不止一个 Alpha 相关。

我有几个目标：

• 一个易于学习和维护的系统。
• 在我的数据库中强制执行数据完整性。
• 与我的数据的真实逻辑组织相匹配的模式。
• 我的编程中可以很好地映射到数据库表的类/对象（à la Linq to SQL）
• 快速的读写操作
• 有效利用空间（少数空字段）

我有三个想法……

一张包含许多 nullalbe 字段的表（平面文件）...

许多具有零 nullalbe 字段的表...

两者中最好的（或最坏的）：许多表的许多空外键......

如果 Alpha 必须是 Bravo 或 Charlie，但不能两者兼而有之怎么办？

如果不只是 Bravos 和 Charlies，Alphas 还可以是 Deltas、Echos、Foxtrots 或 Golfs 等中的任何一个……？

编辑：这是问题的一部分：哪个是我导航的最佳数据库模式？

在 SQL Server 中设置外键时，在什么情况下应该在删除或更新时级联，其背后的原因是什么？

这可能也适用于其他数据库。

我最关注的是每种场景的具体示例，最好是来自成功使用它们的人。

一位前同事坚持认为，具有更多表且每列更少的数据库比具有更少表且每列更多的数据库要好。例如，不是包含名称、地址、城市、州、邮编等列的客户表，而是名称表、地址表、城市表等。

他认为这种设计更加高效和灵活。也许它更灵活，但我没有资格评论它的效率。即使它更有效，我认为这些收益可能会被增加的复杂性所抵消。

那么，与具有更多列的更少表相比，具有更少列的更多表有什么显着的好处吗？

如果您熟悉“建造一个扔掉”这个短语，那么我们似乎已经做到了；我们正在达到我们在线应用程序版本 1 的限制。是时候清理一下了：

• 重新组织代码和 UI
• 统一 UI 流程
• 添加更多功能
• 为未来而建
• 修改我们的数据库结构以处理上述所有问题

实现这种转变的最佳方式是什么？

我们希望避免将所有用户都扔给一个新系统（一旦完成）......他们会吓坏了，我们无法处理呼叫负载。我们的用户涵盖范围广泛，从技术熟练的用于编写软件的类型到那些不知道 HTML 是什么的用户。

在我们确保这个新设计充分解决了版本 1 的足够问题之后，我们是否应该开始一个新的系统“安装”并逐渐将用户转移到它？

我们是否应该（以某种方式）逐步更改系统的每个模块并进行阶段化？这可能很困难，因为数据库布局会发生变化，导致必须调整“核心代码”和几个周围模块的代码。

拥有一组使用尖端版本的应用程序的受信任、耐心、“beta 测试员”客户是否很常见？（这里的目标是获得反馈并测试新系统上的错误）

还有什么建议吗？第一手经验？

这是我正在做的一个例子：

请注意，Uncle-Child 关系没有 ON DELETE CASCADE；即删除 Child 不会删除其 Uncle，反之亦然。

当我有同一个孩子的父母和叔叔时，我删除了父母，似乎InnoDB 应该能够“弄清楚”并让级联在整个家庭中涟漪（即删除父母删除叔叔和孩子也是如此）。但是，相反，我得到以下信息：

InnoDB 正在尝试在引用它的 Uncle 之前级联删除 Child。

我错过了什么吗？这是否应该由于某种我不明白的原因而失败？或者是否有一些技巧可以让它工作（或者它是 MySQL 中的一个错误）？

在系统中处理用户帐户管理的最佳方法是什么，而不让您的员工有权访问数据库来访问帐户。

例子：

1. 在数据库中存储用户名/密码。这是一个坏主意，因为任何有权访问数据库的人都可以看到用户名和密码。因此使用它。

2. 存储用户名/密码哈希。这是一种更好的方法，但是可以通过将数据库中的密码哈希替换为您知道其身份验证信息的另一个帐户的哈希来访问该帐户。然后在授予访问权限后将其还原回数据库。

windows/*nix 是如何处理这个问题的？

我们正在用 VB.NET 和 SQL Server 重写我们的旧会计系统。我们引入了一个新的 .NET/SQL 程序员团队来进行重写。大多数系统已经使用浮点数完成了美元金额。我编程的遗留系统语言没有浮点数，所以我可能会使用小数。

你的建议是什么？

是否应该将浮点数或小数数据类型用于美元金额？

两者都有哪些优点和缺点？

在我们的每日例会中提到的一个缺点是，当您计算返回超过两位小数的结果的金额时，您必须小心。听起来您必须将金额四舍五入到小数点后两位。

另一个缺点是所有显示和打印的金额都必须有一个格式声明，显示两位小数。我注意到有几次没有这样做，而且金额看起来不正确。（即 10.2 或 10.2546）

专业人士是仅浮点方法在磁盘上占用 8 个字节，而十进制将占用 9 个字节（十进制 12,2）。

我们又来了，旧的争论仍然存在......

我们最好有一个业务键作为主键，还是我们宁愿有一个代理 id（即 SQL Server 标识）对业务键字段具有唯一约束？

请提供例子或证据来支持你的理论。

假设您有一个实体，例如您正在捕获其详细信息的车辆。您要捕捉的汽车被涂成红色、黑色和白色。前轮胎为普利司通 275/35-18，后轮胎为 325/30-19。有时您可能只有两个轮胎（是的，这将被视为摩托车，这是一种车辆），有时可能只有 18 个轮胎。然后有一些字段总是单值的，比如引擎大小（如果我们让我们的想象力疯狂，我们可以想到多引擎车辆，但我试图保持简单）。

我们目前处理这个问题的策略是为每个可以有多个值的字段创建一个表。这将产生大量的表（我们有一堆不同的实体有这个要求）并且闻起来有点难闻。这是最好的策略吗？如果不是，什么会更好？

为动态逻辑数据库模式提供存储的推荐架构是什么？

澄清一下：如果系统需要为其模式在生产中可能由其用户扩展或更改的模型提供存储，有哪些好的技术、数据库模型或存储引擎可以实现这一点？

几个可能性来说明：

• 通过动态生成的 DML 创建/更改数据库对象
• 创建具有大量稀疏物理列的表并仅使用“覆盖”逻辑模式所需的表
• 创建一个“长而窄”的表，将动态列值存储为行，然后需要对其进行透视以创建一个包含特定实体的所有值的“短而宽”行集
• 使用 BigTable/SimpleDB PropertyBag 类型系统

任何基于现实世界经验的答案将不胜感激