标签: database-design

我正在尝试为将成为 Delphi UI 应用程序后端的 MS SQL Server 数据库建模用户身份验证模块。基本上，我想拥有用户只属于一个组的用户帐户。一个组可以拥有“n”个权限。

我还想向数据库添加密码历史记录，因为用户将需要根据应用程序设置（例如，每 90 天）更改其密码。

我还想在每次用户登录和退出时记录一个事件。我可能会将其扩展到未来的其他活动。

下面你会发现我的第一个破解。请让我知道任何改进它的建议，因为这是我第一次这样做。

您是否认为需要针对基于角色的安全性和密码规则/到期期限的约束的其他属性？

我有一个没有被另一个实体定义就不能存在的实体，我希望这个实体参与多对多关系。

例子：一个艺人有一张专辑（没有艺人就不能存在专辑），专辑也有很多曲目，但同一曲目可以存在于多个专辑中。

所以我们在专辑和曲目之间有一个多对多的关系。

如果专辑是弱实体，则其主键是引用艺术家的外键，因此它不能是表示多对多关系的另一个表的外键。

问题是：SQL中是否可以有这种关系，如果可以，我该如何表达？

我正在寻找有关以下情况的表/索引设计的建议：

我有一个带有复合主键（assetid (int),date (date)）的大表（股票价格历史数据、InnoDB、3500 万行并且还在增长）。除了定价信息之外，我还有 200 个双值需要对应于每条记录。

CREATE TABLE `mytable` (
`assetid` int(11) NOT NULL,
`date` date NOT NULL,
`close` double NOT NULL,
`f1` double DEFAULT NULL,   
`f2` double DEFAULT NULL,
`f3` double DEFAULT NULL,   
`f4` double DEFAULT NULL,
 ... skip a few …
`f200` double DEFAULT NULL, 
PRIMARY KEY (`assetid`, `date`)) ENGINE=`InnoDB` DEFAULT CHARACTER SET latin1 COLLATE
    latin1_swedish_ci ROW_FORMAT=COMPACT CHECKSUM=0 DELAY_KEY_WRITE=0 
    PARTITION BY RANGE COLUMNS(`date`) PARTITIONS 51;

为了便于更新和检索，我最初将 200 个双列直接存储在该表中，这一直工作正常，因为在该表上进行的唯一查询是通过资产 ID 和日期（这些都被虔诚地包含在针对该表的任何查询中） )，并且只读取了 200 个双列。我的数据库大小约为 45 Gig

但是，现在我需要能够通过这 200 …

我有一个表设计方案，并且作为非 DBA 类型，希望对哪个更可扩展提出意见。

假设您被要求记录一个都市区的房屋信息，从一个小社区（200 所房屋）开始，但最终增长到 5000000 多所房屋。

您需要存储基本信息：ID#（我们可以用作唯一索引的唯一批次 #）、地址、城市、州、邮编。很好，简单的表会处理它。

但是每一年，你都会被要求记录所有房子的额外信息——每年都有哪些信息会发生变化。因此，例如，第一年，您需要记录所有者的姓氏和面积。第二年，你被要求保留姓氏，但丢弃平方英尺，而是开始收集业主的名字。

最后 - 每年额外列的数量都会改变。可能从 2 个额外的列开始，然后到明年的 6 个，然后回到 2 个。

因此，一种表格方法是尝试将自定义信息添加为房屋表格中的列，因此只有一张表格。

但是我有一种情况，有人为此将表格布置为：

“房屋表”列：ID、地址、城市、州、邮编 - 每所房屋一行

ID   Addr              City     State  Zip 
-------------------------------------------
1    10 Maple Street   Boston      MA  11203

2    144 South Street  Chelmsford  MA  11304

3    1 Main Avenue     Lowell      MA  11280

“自定义信息表”列：ID、名称、值 - 表格如下所示：

ID   Name             Value

1    Last Name        Smith

2    Last Name        Harrison

3    Last Name        Markey

1    Square Footage   1200

2    Square Footage   1930

3    Square Footage …

是的，我知道数据规范化应该是我的首要任务（因为它是）。

1. 我有一个表，65列存储与列车辆数据：used_vehicle，color，doors，mileage，price等等，总共65。
2. 现在，我可以将它分开并有一个Vehicle表，VehicleInterior, VehicleExterior, VehicleTechnical, VehicleExtra（与主Vehicle表一一对应）。

假设我将有大约 500 万行（车辆）。

在SELECT一个WHERE条款：请问性能会更好，通过搜索（至少索引的这两种情况下IDs）：

1. Vehicle 具有 65 列的表或
2. Vehicle表与JOINS其他四个表（均具有 500 万行）以返回与Vehicle?

（根据数据库引擎，考虑 PostgreSQL 和/或 MySQL）。

真的很感激您从以前的经验中可能获得的任何详细见解吗？

如果有的话，更新将很少见，并且选择将主要针对搜索结果列表的所有列（车辆详细信息页面）和主要信息（几列），实际上也许最好的解决方案是两个表：一个包含主要信息（很少列）和另一个表以及其余的列。

我知道这里和这里有人问过这个问题，但我有不同的可能实现的相同想法，我需要一些帮助。

最初，我的blogstories表具有以下结构：

| Column    | Type        | Description                                    |
|-----------|-------------|------------------------------------------------|
| uid       | varchar(15) | 15 characters unique generated id              |
| title     | varchar(60) | story title                                    |
| content   | longtext    | story content                                  |
| author    | varchar(10) | id of the user that originally wrote the story |
| timestamp | int         | integer generated with microtime()             |

在我决定要为博客上的每个故事实施一些版本控制系统后，我想到的第一件事就是创建一个不同的表来保存编辑；在那之后，我想我可以修改现有的表来保存版本而不是edits。这是我想到的结构：

| Column …

我应该如何在 SQL 中实现以下实体关系图中描述的场景？

如图所示，每个A实体类型出现都必须与至少一个 B对应项（由双连接线表示）相关，反之亦然。我知道我应该创建以下三个表：

    CREATE TABLE A
    (
        a INT NOT NULL,
        CONSTRAINT A_PK PRIMARY KEY (a)
    );

    CREATE TABLE B
    (
        b INT NOT NULL,
        CONSTRAINT B_PK PRIMARY KEY (b)
    );

    CREATE TABLE R
    (
        a INT NOT NULL,
        b INT NOT NULL,
        CONSTRAINT R_PK      PRIMARY KEY (a, b),
        CONSTRAINT R_to_A_FK FOREIGN KEY (a)
            REFERENCES A (a),
        CONSTRAINT R_to_B_FK FOREIGN KEY (b)
            REFERENCES B (b)
    );

但是，如何实现总参与约束（即，强制执行其中之一的每个 …

我做了一些研究，发现我应该将路线存储为一系列停靠点。就像是：

Start -> Stop A -> Stop B -> Stop C -> End

我创建了三个表：

• 路线
• 停止
• 路线停靠点

...其中RouteStops是一个连接表。

我有类似的东西：

路线

+---------+
| routeId |
+---------+
|    1    |
+---------+
|    2    |
+---------+

车站

+-----------+------+
| stationId | Name |
+-----------+------+
|     1     |   A  |
+-----------+------+
|     2     |   B  |
+-----------+------+
|     3     |   C  |
+-----------+------+
|     4     |   D  |
+-----------+------+

路线站

+-------------+---------------+
| routeId(fk) | stationId(fk) |
+-------------+---------------+
|     1       |       A       | …

我正在用 Postgres 构建一个数据库，其中将有很多由month和分组的东西year，但永远不会由date.

• 我可以创建整数month和year列并使用它们。
• 或者我可以有一month_year列并始终将其设置day为 1。

如果有人正在查看数据，前者似乎更简单更清晰，但后者很好，因为它使用了正确的类型。

不使用 FK 约束是我公司的不为人知的规则。FK 约束仅在设计 ERD 时使用，在创建表时不使用。

据我的前辈说，在实际操作中，当我们处理紧急问题时，这些都是非常耗时的障碍。他说，当我们需要立即使用 INSERT/UPDATE/DELETE 语句时，约束会阻止这些语句的执行，并且在保持约束的同时编写语句也很耗时。我什至听说许多其他公司也在这样做。

虽然我有点理解这些挣扎，但我不确定这是否是一个好方法，因为它与我对 DB 的理解完全相反。这家公司也是我的第一份工作，所以我不知道其他公司是如何处理的。

实际上，您对此有何看法？这有道理吗？有更好的方法吗？其他公司在这方面的表现如何？

更新：对于韩国公司来说，这似乎是一种很常见的方法。我问了几个在别的公司工作的前辈，他们大多都说都是这样。甚至其中一个人在一家金融公司工作！有趣的...