标签: database-design

我需要创建一个表来保存保存的电子邮件以供将来发送（收件人、发件人、消息、预定发送日期等）。

这里的问题是，直到发送当天我才知道谁应该收到电子邮件。

我的意思是，创建电子邮件是为了发送给某些选定的组织，但该组织的“成员”将不断加入和离开，因此，如果有人创建下个月要发送的电子邮件，则要发送的成员电子邮件地址列表到那时就会有所不同。

所以，我需要在表中保存的是电子邮件应该发送到的组织列表，以便我在实际发送电子邮件时可以查询最新的成员电子邮件地址列表。希望这是有道理的。

无论如何，我的问题是：什么被认为是“正确的设计”？

我最初的想法是只保存以逗号分隔的组织 ID 列表。

我知道我永远不必搜索列表中的组织，所以我不在乎它是否不可查询，而且我知道我可以将其标准化为每个接收组织一行，但这似乎是不必要的重复无目的的数据，特别是因为我只查询发件人而不是收件人。

那么，ID 列表只是一件可怕的、没有好处的、只有新手才会想到的坏事吗？或者说在某些情况下可以使用吗？或者还有其他我不知道的方法可以做到这一点？我确信我不是唯一一个遇到过这种情况的人！

我一直想知道以下方法是否不好或真的非常糟糕:)。

问题＃1：我们可以使用和表indicator_id中的数据进行合并（不使用）[我们知道我们可以，因为我们这样做了，但是它可以接受吗:)]？indicator_valuesindicator_detailsFOREIGN KEY

问题#2：如果我们决定使用indicator_id（indicator_details表中不是PK），它会对性能产生重要影响吗？

正确理解 SQL 方法，最好的选择是在表中使用iid( iidas FOREIGN KEY)indicator_values而不是indicator_id，但项目总是有一些限制（比如用户插入数据的方式 - 下面详细介绍），因此我们试图找到一个折衷的解决方案。

我知道这可能会导致数据完整性问题，但是没有 FK 的解决方案将非常用户友好（因为用户不必担心插入indicator_values表中正确的行 - 具有正确的行iid），特别是在我们的情况下，数据完整性是并不重要。此外，如果用户插入数据的唯一方法（在我们的例子中）是先从表中删除所有行，则使用 FK 的方法将导致在表更新ON DELETE期间从指标值中删除所有行（由...引起）indicator_details（再次 - 更新）意味着：删除所有行然后插入新数据），所以这会很耗时。

D B：

指标值表

+----------+--------------+------+-------+
| vid (PK) | indicator_id | year | value |
+----------+--------------+------+-------+
|     1    | AACA         | 2001 |    10 |
|     2    | bbb          | 2001 | …

我正在使用 PostgreSQL 10。我想要一个表，允许在列中使用相同的值，但不允许在行中使用。我创建的表：

CREATE TABLE teams
(
  team_id SERIAL PRIMARY KEY
  team_lead character varying(250) NOT NULL,  
  member1 character varying(250) NOT NULL,
  member2 character varying(250),
  member3 character varying(250)
  )

这将被允许：

CREATE TABLE teams
(
  team_id SERIAL PRIMARY KEY
  team_lead character varying(250) NOT NULL,  
  member1 character varying(250) NOT NULL,
  member2 character varying(250),
  member3 character varying(250)
  )

这不会：

| team_lead     |  member1     | member2       |
------------------------------------------------
| Jane Doe      | Bill Smith   | Shirley Green |
| Jane Doe      | Carol Lewis  | …

我试图理解退化维度。但是我经常在事务表中遇到术语“订单行”作为粒度。有人可以解释一下订单和订单行之间的区别吗？

我们正在做一个新的数据库设计，我们预先设置一些规则。我不知道制定这些规则有多大意义，

1. 每个表名和列名都应该有意义。它应该提供有关表或列用途的信息。

2. 表名不应超过 27 个字符，列名不应超过 30 个字符。

3. 表名是复数。例如：COMPANIES, EMPLOYEES, PERSONS, GENDERS, RELIGIONS, COUNTRIES, ...

4. 每个表都有一个主键，table_name_ID即NUMBER(15). 表名在主键列中用作单数。示例：该USER_REQUESTS表的主键为USER_REQUEST_ID。

5. 如果表名或列​​名超出限制，则使用合适的缩写。示例：CMS_EXEMPTIONS是保留内容管理系统豁免的表。

6. 保留事务数据的表应以_TRANS. 示例：COMPANY_TRANS是保存公司相关交易数据的表。

7. 每个表有 4 个 WHO 列，如下所示：

   CREATE_USER        NUMBER(15)
   CREATE_DATE        DATE
   MODIFY_USER        NUMBER(15)
   MODIFY_DATE        DATE
   

   Run Code Online (Sandbox Code Playgroud)

8. 作为外键关系的列被命名为被引用表的主键。示例：如果一个表有对该COUNTRIES表的引用，则引用列也被命名COUNTRY_ID为该COUNTRIES表的主键。

9. 如果由于第一条规则（有意义的名称），引用列的含义应该不同于第 8 条规则，则应用有意义的名称规则。例如：COUNTRIES如果它用于保持一个人的国籍而不是命名为 ，那么nationality 和 country 列都与table有关系NATIONALITY_ID。

10. 如果该表有多个与同一个表相关，则它们会被赋予不同的名称，例如BIRTH_COUNTRY_ID，PASSPORT_ISSUE_COUNTRY_ID

11. 如果表是表之间的关系表，则表名包含两个表名。

给有意义的名字一直是我们命名的第一条规则。

我们公司在一个大型 Excel 工作簿中有用户数据（姓名、电子邮件、电话号码、访问系统、AD 用户名）。由于 Excel 工作簿中包含 1000 多个条目，因此变得非常缓慢，我们正在寻找替代解决方案。

我认为 Microsoft Access 是因为它的易用性和快速制作表格和报告的能力，但我的老板担心 Access 很快就会过时。有人对此有其他解决方案吗？我知道一点 SQL，所以这是一个选项，但不是首选选项。

我有一种感觉，这肯定被问过多次，但我只是找不到解决方案，甚至可能因为难以解释而提出问题。

我们都知道内连接基本上给出了两个表的“交集”。因此多个内连接给出了所有表的交集。但是，我希望获得一个内部连接，该连接获得表 B 与 A或表 C 与 A的交集。

对于获得所有组织的请求，我要么是主持人，要么是管理员。

SELECT *
FROM organization
INNER JOIN moderator_organization
  ON organization.id = moderator_organization.organization AND moderator_organization.user = 10
INNER JOIN admin_organization
  ON organization.id = admin_organization.organization AND admin_organization.user = 10

然而，上面只会选择用户（ID 为 10）既是管理员又是组织者的组织，而不是其中任何一个都为真的组织。要在图表中可视化，我想：

红色区域是我想要请求的地方。

最近我正在学习事务数据库中的并发控制技术。但是，我对操作系统和事务数据库中的并发控制之间的差异感到非常困惑。

在我的理解中，数据库文献中介绍的并发控制技术可以用在多线程程序中，它的线程彼此共享一些变量，反之亦然。多线程程序中用于在线程之间共享变量的技术也可用于数据库中的并发控制。

为什么我们要费心在数据库文献和操作系统中以不同的方式介绍这一点？

下面来自维基百科的引用（这里）说这READ COMMITTED不会导致序列化失败！你能解释一下原因吗？哪些隔离级别会导致序列化失败？

在多版本并发控制下，在 SERIALIZABLE 隔离级别，两个 SELECT 查询都会看到在事务 1 开始时拍摄的数据库快照。因此，它们返回相同的数据。但是，如果随后事务 2 也尝试更新该行，则会发生序列化失败并且事务 1 将被迫回滚。

在 READ COMMITTED 隔离级别，每个查询都会看到在每个查询开始时拍摄的数据库快照。因此，他们每个人都会看到更新行的不同数据。在这种模式下不可能出现序列化失败（因为没有承诺可序列化），并且事务 1 将不必重试。

观看此视频，对 dbms 还很陌生。
演讲者解释说，在面向行的数据库中，行是按块读取的。
所以，我的理解是，如果我有字段较少的行，更多的行可以放入一个块中，当我查询表时，它应该进行更少的 IO 操作，从而获得更好的性能..我对吗？

我可以提取规则，我不应该根据它们代表的实体设计表格，而是根据我阅读或更新这些字段的频率吗？

例如：表雇主：

• ID
• 名称（常用）
• 徽章编号（经常使用）
• 出生日期（很少使用）
• 出生地（很少使用）
  
  我应该把桌子一分为二吗？
• tbl1: ID | 姓名 | 徽章编号
• tbl2: ID | 出生日期 | 出生地