我对数据库设计比较陌生，我决定制作自己的假设数据库以进行实践。但是，我无法对其进行建模和规范化，因为我认为存在许多多对多 (M:N) 关系。

一般场景描述

该数据库旨在保留有关在塞尔达系列中工作过的各种人物的数据。我想跟踪的控制台（S） ，一个游戏可以玩上，员工是曾在部分游戏的发展，乔布斯的员工有（很多员工在不同的工作职位在多个游戏等）

商业规则

• 多个员工可以在多个游戏上工作。
• 多个游戏可以在同一个控制台上。
• 多个控制台可以是同一个游戏的平台。
• 多个员工可以拥有相同的Job。
• 一个Employee可以有多个Jobs。
• 一个游戏可以有多个员工。
• 一个游戏在它的开发过程中可以有多种类型的工作
• 多个游戏可以附加相同类型的工作。
• 一个控制台可以有多个人在处理它。
• 一个人可以在多个控制台上工作。

属性名称和样本值

• Employee Name，可以分为First …

在我们上一次每周例会上，一个没有数据库管理背景经验的人提出了这个问题：

“会不会有一种情况证明将数据存储在行（字符串）而不是多行中是合理的？”

让我们假设有一个表，称为countryStates我们想要存储一个国家的州的位置；我将在这个例子中使用美国，为了懒惰，不会列出所有的州。

在那里我们会有两列；一个叫Country，另一个叫States。正如这里所讨论的，以及@srutzky 的回答所提出的，这PK将是ISO 3166-1 alpha-3定义的代码。

我们的表看起来像这样：

+---------+-----------------------+-------------------------------------------------------+
| Country | States                | StateName                                             |
+---------+-----------------------+-------------------------------------------------------+
| USA     | AL, CA, FL,OH, NY, WY | Alabama, California, Florida, Ohio, New York, Wyoming |
+---------+-----------------------+-------------------------------------------------------+

当向一位开发人员朋友提出同样的问题时，他说从数据流量大小的角度来看，这可能有用，但如果我们需要操纵这些数据，则不是。在这种情况下，应用程序代码必须有智能，可以在列表中转换此字符串（假设有权访问此表的软件需要创建一个组合框）。

我们得出的结论是这个模型不是很有用，但我怀疑可能有办法让它有用。

我想问的是，你们中是否有人已经以真正有效的方式看到、听到或做过这样的事情。

我正在与我工作的公司的开发人员进行永久讨论，因为他们说最好摆脱关系数据库中的关系强制（通过 FOREIGN KEY 约束定义）以加快大型查询并获得更好的结果表现。

考虑的平台是MySQL 5.x，没有设置FOREIGN KEY，甚至缺少相关表的一些PRIMARY KEY约束，至少对我来说是不合理的。也许他们是对的，我是错的，但我没有足够的论据来讨论这种情况。

三年来，这一直是首选方法。我是这家公司的新人（只有一个月），但是，随着产品“有效”，我对增强数据库犹豫不决；尽管如此，我注意到的第一件事是加载一个页面需要 1 分钟（是的，60 秒！）。

当前状况背后的说法之一是“非规范化”数据库比规范化数据库更快，但我不相信这是真的。

大多数相关查询都包括 JOIN 操作，这使得它们在处理大量数据（数据库包含数百万行）时运行非常非常缓慢。

通常，“CRUD”操作的处理是在应用程序代码级别实现的；例如，为了删除一些数据，让我们说TableA：

• 有必要先检查在运行，如果有排之间的一些关系TableA和TableB，
• 如果“检测到”所述关系，则应用程序代码将不允许删除相关行，但是
• 如果由于某种原因应用程序代码失败，那么 DELETE 操作将“成功”，无论涉及的行和表是否存在任何关系。

题

你能帮我详细阐述一个好的、准确的和可靠的答案来丰富辩论吗？

_{注意：以前可能有人问过（并回答过）类似的问题，但我无法通过 Google 找到任何内容。}

我的 DBA 经验只是简单的存储 + CMS 样式数据的检索 - 所以这可能是一个愚蠢的问题，我不知道！

我有一个问题，我需要查找或计算特定组大小和特定时间段内特定天数的假期价格。例如：

1 月任何时候 2 人 4 晚的酒店房间多少钱？

例如，我有 5000 家酒店的定价和可用性数据，如下所示：

Hotel ID | Date | Spaces | Price PP
-----------------------------------
     123 | Jan1 | 5      | 100
     123 | Jan2 | 7      | 100
     123 | Jan3 | 5      | 100
     123 | Jan4 | 3      | 100
     123 | Jan5 | 5      | 100
     123 | Jan6 | 7      | 110
     456 | Jan1 | 5      | 120
     456 | Jan2 …

我想存储发票数据，如人员地址。但问题是地址会随着时间的推移而改变——例如，有人会搬出去改变他的地址。存储此类数据的问题出现了，因为我们无法更改某些发票上引用的数据。

我有 3 个表：（AddressInfo包含 StreetAddress 等），Person它们与AddressInfo, 和Invoice表具有一对多关系。

我有两个解决方案，但我不确定哪个方向是正确的方法：

• 创建AddressInfo并使其可软删除，添加一些类似的列IsActive，IsDeleted以便我的Invoice表可以通过其 ID 引用此地址信息，并且保证保持不变，除非有人在不使用我的应用程序的情况下直接更改此数据。

  因此，当有人更改他的地址时，我会软删除（也许应该称为软更新？）当前地址并添加新地址，而根本不会触及旧记录。最好先检查一下发票上是否引用了它以防止污染。

  我的Invoice桌子看起来有点像：

  | InvoiceId | AddressInfoId |

• 将所需的列添加AddressInfo到我的Invoice表中。每次创建新发票时，我都必须复制数据，地址不会经常更改，重复记录会稍微污染我的数据库。

  我的Invoice表看起来有点像（大大简化）：

  | InvoiceId | StreetAddress |

您是否有使用解决此特定问题的数据库（可能是某些 ERP 软件）的经验？

有趣的朗读：

https://martinfowler.com/eaaDev/timeNarrative.html

编辑: 这个问题是关于如何处理在整个系统设计中出现的许多问题，这使得系统的某些部分偏离了通用标准。例如，使用自己的程序代码管理业务模型中的所有内容，甚至关系完整性。这给数据库和持久层带来了一种糟糕设计的味道，将其用作“将某些内容转入并以某种方式再次取出”的地方，而不是结构化存储。我问了这个问题，因为在我看来，NoSQL 文档存储就像一个选项，可以将已经无模式（或非常松散的模式）数据库移动到默认情况下没有模式的数据库。此外，我必须指出，尽管这里描述了一些缺陷，但整个系统根本不是一个坏系统。此外，一些问题，例如版本控制，已经有了解决方案或已经实施。

想想你看到的一个软件系统，基于经典的关系数据库（SQL Server、Oracle）、NHibernate作为对象关系映射器（ORM）、顶部的业务逻辑模型层和大量模块（几百个） ，主要是基于 .NET 的服务和一些 Web 服务（带有客户端，每个系统/客户最多约 100 个，公司网络，非公共）。操作方式主要是OLTP，写/CUD访问是工作负载的重要组成部分。生产数据库通常大约为 10GB，但大小总是远低于 100GB（因此没有“大数据”）。它确实工作得很好，但对我来说，数据库和 ORM 实现有几种反模式（对于关系数据库）的味道。也许这些实现对于另一种数据库会更好——面向文档（“NoSQL”）或内存数据库。

1. 省略了许多关系数据库和支持 ORM 的功能：表被强烈反规范化，外键关系丢失或不可能，例如由于元数据表引用不同的主表，列如IdInTable INT, OwnerTable INT. NHibernate 几乎没有映射对象关系（并且通常存在不适合它的表结构的问题）。相反，这些是在业务逻辑中实现的（有时会导致孤立的子对象或低效的数据库访问，见下文）。

2. 基础之下的非规范化：增加非 1st NF 数据的使用：带有 XML、逗号分隔列表或复合数值列的 nclob/nvarchar(max) 列（例如，任务类型 123 的 123、10123、40123，但模块配置不同由 0,1,4 * 10000 标识）。前两个包含数据库相关、逻辑“外键”和数据模型相关值，例如<UserType>AdminUser</UserType>（要检查LIKE '%...%'）。这主要是由于许多快速发布、短暂存在和自定义的值不应该进入主模式，或者更容易通过 XML 值实现。

3. 非 2nd NF 数据，包括由触发器、后续存储过程或应用程序复制到其他表中的表内容。例如，将表列值复制到“垂直”元数据表，这再次复制到元数据的“水平”或“旋转”表示（每个元数据类型为一列），因为某些应用程序只能使用元数据或水平元数据. 经常要求使用“垃圾箱结构”（将从各种来源收集的数据转储到一个 nclob/nvarchar(max)“垃圾箱”列中，并让应用程序搜索它，而不是许多不同的来源）。

4. 业务逻辑模型和应用程序中的“单一对象疾病”： 单个对象的迭代和立即加载/保存：业务层主要使用 Load/Save() 方法来处理单个对象和少量基于批量/集合的操作。一个常见的工作是通过 SQL 或者它的 NHibernate 表示来获取对象 ID，然后遍历所有检索到的 Id 并以foreach (oneId in Ids) { myObjects.Add( BizModel.GetMyObjectById(oneId) ); }. 这包括所有元数据、依赖对象集合等，这是典型的 SELECT N+1 情况。此外，大多数 NHibernate …

在过去的几年里，我一直试图了解哪种方式适合存储地址。我一直在“一路规范化”，但也“尽可能地去规范化”，我只是无法决定什么对我的项目有好处。

很快，我的项目将涉及大量用户（10 万+），并且所有用户都将存储 1-3 个地址（个人、企业和计费）。这意味着我可以有 100k+ * 3 个地址记录。此外，我将通过邮政编码进行大量查找（获取将地址注册到邮政编码中的用户）。我只会有美国地址。

我对用户到地址表及其与我的项目的关系感到满意。然而，没有关系的表格让我发疯。

（我在图像中显示的表格是这样的，只是为了让我更好地了解我需要什么以及如何处理。我知道有很多冗余字段，所以请不要按原样接受它们。）

有没有人有关于如何设计的任何提示？
有没有人有大公司（UPS、USPS 等）使用的模式或类似模式的链接或其他内容？

我非常仔细地问过表设计师为什么他选择在多个表中创建 CSV 列。

设计师的回答是，将 CSV 列拆分为单独的表是“不必要的复杂”。

在隐式连接中使用一个 CSV 列来计算 CSV 列中众多值中的一个值已被使用的次数。

where绑定两个表的原因使用了一个like % | table_b.csv_column | %操作。

我阅读并了解到，如果有充分的理由，并不总是需要规范化。
但是，我不知道什么是不正常化的充分理由。

这是（避免“复杂化”）不强制执行第一范式（1NF）的一个很好的理由吗？

桌子： TB_DISASTER_CAUSE_CATE

CATEGORY_ID   CATEGORY_N CATEGORY_L L
------------- ---------- ---------- -
DC006001002   ****                3 Y
DC006001003   ****                3 Y
DC006002001   ****                3 Y
DC007001001   ****                3 Y
DC007002001   ****                3 Y
DC007002002   ****                3 Y
DC007003001   ****                3 Y
DC007003002   ****                3 Y
DC007003003   ****                3 Y

桌子： TB_DISASTER_HISTORY

SEQ DISASTER_TYPE DISASTER_CAUSE                                             
----- ------------- ------------------------------------------------------------
   32 DT001003002   DC001001004|DC002001002|DC003001001|DC007002001 …

因此，在工作场所，我们目前将审计日志存储在不同的表中，具体取决于它是什么，例如登录/访问信息、配置更改等。

这些都是独立的数据，没有外键或任何关系。一些列是相似的，例如 ID（显然）、日期时间、进行更改的用户名等，而其他列则不同。

最近，我被要求将所有表合并为一个，其中相似的列将被保留，而不同的列将在 JSON 中，存储在一个 CLOB 列中。

有人告诉我，这个过程称为“规范化”——我们正在将许多表转换为“规范形式”。

现在，我不是数据库专家，但这似乎与我在数据库介绍课程中学到的关于规范化的知识不符。还是我只是无知？

我正在尝试为记录事件的表格优化表格布局。

日志表包含三个相关的列：Timestamp, ItemId, LocationId
每行表示在给定的time，item已经在某个 看到了某个location。

2017-01-01 10:00    Item A has been seen at location 1
2017-01-01 10:01    Item A has been seen at location 1
2017-01-01 11:00    Item B has been seen at location 1
2017-01-01 11:01    Item B has been seen at location 2
2017-01-01 11:02    Item A has been seen at location 2
2017-01-01 11:03    Item B has been seen at location 1

大约有 100 个不同的位置、每天 20.000 个新项目、每天一百万个事件和 14 天的日志。 …

在面试时，我的面试官问了我一个关于表的非规范化及其在应用程序中的使用的问题。

我猜测，我回答说，是的，可能是。作为非规范化，您将所有列都放在一个表中，您不需要任何类型的连接，因此如果给出适当的查找条件，您最大的优点将是性能。您可以在报告中使用非规范化表。

我回答的对吗？