标签: database-design

我们有 3 个完全相同数据库的副本。所有 3 个数据库都有一个Users表，并且一个用户将始终存在于所有 3 个数据库中，并且具有完全相同的设置。任何时候我们想要添加或编辑用户，我们都必须更新 3 个数据库。

Users从数据库 2 和 3 中删除表并将其替换为Synonym指向数据库 1的表是否更好？

这是我能想到的优点/缺点：

优点

• 更容易维护。可以在一个位置而不是 3 个位置更新用户
• 用户 ID 将在数据库之间匹配（很重要，因为许多附加应用程序都基于用户 ID）

缺点

• 不要认为这是标准程序，所以可能会造成混淆
• 用户必须在数据库之间具有相同的设置
• （来自下面gbn 的回答）如果数据库 1 出现故障，数据库 2 和 3 也将不可用。还存在恢复时数据不一致的潜在问题

这是我正在考虑的一个选项，用于包含数据库之间相同设置的几个不同表，而不仅仅是Users表。我在示例中使用用户，因为它很容易理解。

鉴于位域只是数据的二进制表示，需要以稍微“奇怪”的方式进行查询。

使用位字段作为布尔值实际上是否有任何好处？从我所见，似乎表明空间是唯一真正的好处。

假设我有一个名为 Software 的实体和两个子类型 FreeSoftware 和 NonFreeSoftware。NonFreeSoftware 实体具有购买日期、供应商等属性。 FreeSoftware 实体具有许可证、源代码 url 等属性。

因此，如果我想为另一个实体（OperatingSystem）建模，我应该怎么做？与软件存在“是一种”关系，但与自由软件和非自由软件存在“非此即彼”的关系。

我想我在分析这个层次结构的方式中遗漏了一些东西。

我经常在数据库中遇到一种情况，其中给定的表可以 FK 到许多不同的父表中的一个。我已经看到了这个问题的两种解决方案，但都不是个人满意的。我很好奇你在那里看到了什么其他模式？有没有更好的方法来做到这一点？

一个人为的例子
假设我的系统有Alerts. 可以接收各种对象的警报——客户、新闻和产品。一个给定的警报可以只针对一个项目。无论出于何种原因，客户、文章和产品都在快速移动（或本地化），因此在创建警报时无法将必要的文本/数据拉入警报。鉴于此设置，我看到了两种解决方案。

注意：下面的 DDL 是针对 SQL Server 的，但我的问题应该适用于任何 DBMS。

解决方案 1 -- 多个可空 FKey

在此解决方案中，链接到多个表之一的表具有多个 FK 列（为简洁起见，下面的 DDL 不显示 FK 创建）。 好处- 在这个解决方案中，我有外键很好。FK 的空优化使得添加准确数据变得方便且相对容易。THE BAD Querying 不是很好，因为它需要N LEFT JOINS 或N UNION 语句来获取关联数据。在 SQL Server 中，特别是 LEFT JOINS 阻止创建索引视图。

CREATE TABLE Product (
    ProductID    int identity(1,1) not null,
    CreateUTC    datetime2(7) not null,
     Name        varchar(100) not null
    CONSTRAINT   PK_Product Primary Key CLUSTERED (ProductID)
)
CREATE TABLE Customer (
    CustomerID  int identity(1,1) …

我有一个日志表，用于捕获某些文件何时导出到另一个系统的日期时间戳。

导出的日志表目前有三个字段：

id                (primary key)
messageId         (int)
exportedDateTime  (datetime)

回顾这一点，我发现该id字段没有任何用处，因为没有连接到该表。在这个表上唯一的工作是插入处理消息的批处理作业并插入到这个日志表中。

我应该删除该id字段吗？

我是否应该在任何一个主键messageId或exportedDateTime或两者兼而有之？

有两个表：

1. 用户
2. 地址

用户包含对地址的引用。

地址包含列 CreatedBy 和 ModifiedBy，这是对用户的引用。

如何设计此数据库以避免循环依赖？

在数据库中存储单个记录的元数据的最佳实践是什么？

我需要在我的数据库中存储许多表的常见元数据，例如创建时间和上次更新时间。我找到了几种不同的解决方案：

1. 将元数据直接存储在表中。

   优点：

   • 元数据直接链接到记录
   • 无需连接即可检索元数据

   缺点：

   • 需要大量重复列（除非使用继承）
   • 元数据和业务数据不分离

2. 创建一个通用元数据表，并使用软外键将数据链接到正确的表和记录。

   优点：

   • 没有重复的列
   • 元数据与业务数据分离

   缺点：

   • 元数据和数据之间没有直接链接（不能使用 FK）
   • 联接需要附加条件

3. 为每个需要元数据的表创建单独的元数据表。

   优点：

   • 元数据直接链接到记录
   • 元数据与业务数据分离

   缺点：

   • 需要很多额外的表
   • 需要大量重复列（除非使用继承）

是否有比我在这里提到的更多的选择、优点或缺点？存储这些元数据的最佳实践是什么？

我需要将 600GB MySQL 表中的数据类型从 INT 更改为 BIGINT。该列具有唯一索引。我可能对 unsigned INT 很好，但我认为更改为 unsigned 或 BIGINT 将几乎相同的痛苦。该表的引擎是 InnoDB。什么会更容易：

1. 更改表
2. 复制结构和 INSERT INTO (SELECT *)
3. 转储表和更改转储文件表定义
4. 还要别的吗？

更新：根据要求，MySQL 5.5.15 版，没有外键并创建表：

 CREATE TABLE `tbl` (
    `id` int(11) NOT NULL AUTO_INCREMENT,
    `user_id` int(11) NOT NULL,
    `created_at` datetime NOT NULL,
    `tid` bigint(20) NOT NULL,
    `t` varchar(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
    `f` tinyint(1) NOT NULL,
    `i_id` bigint(20) NOT NULL,
    `ir_id` int(11) NOT NULL,
    `r_c` int(11) NOT NULL,
    `r` tinyint(1) NOT NULL,
    `e` text CHARACTER SET …

我正在设计我的第一个电子商务模式。我已经阅读了一段时间的主题，并且对 anorder_line_item和 a之间的关系感到有些困惑product

一个product可以被购买。它有各种细节，但最重要的是unit_price。

Anorder_line_item有一个外键，指向product_id购买的、quantity购买的和unit_price客户购买产品的时间点。

我读过的大部分内容都说应该明确添加unit_priceon order_line_item（即不通过 引用product_id）。有道理，因为商店将来可能会改变价格，这会弄乱订单报告、跟踪、完整性等。

我不明白的是，为什么直接将unit_price值保存到order_line_item?

创建一个记录unit_pricea 更改的审计/历史表不是更好product吗？

当order_line_item被创建，所述的外键product_audit表，并将该价格可以从那里检索（通过引用）。

在我看来，使用这种方法有很多好处（减少重复的数据、价格变化历史等），那么为什么不更频繁地使用它呢？我还没有遇到使用这种方法的电子商务模式的例子，我错过了什么吗？

UDPATE：我的问题似乎与Slowly Changed Dimension 相关。我仍然感到困惑，因为缓慢变化的维度与数据仓库和 OLAP 相关。那么，缓慢变化的维度类型可以应用于我的主要业务事务流程数据库 (OLTP) 吗？我想知道我是否混合了很多概念，非常感谢一些指导。

我在 SQL 中对电气原理图建模时遇到了一些麻烦。我想捕获的结构是

  part ??????????? pin
   ?                ?
part_inst ?????? pin_inst

其中“inst”是“instance”的缩写。

例如，我可能part将 LM358 运算放大器pin用作 1OUT、1IN-、1IN+、GND、2IN+、2IN-、2OUT 和 V _CC。然后我可能会将这部分放在原理图上，创建 apart_inst和 8 pin_insts。

忽略数据字段，我对模式的最初尝试是

create table parts (
    part_id bigserial primary key
);
create table pins (
    pin_id bigserial primary key,
    part_id bigint not null references parts
);
create table part_insts (
    part_inst_id bigserial primary key,
    part_id bigint not null references parts
);
create table pin_insts (
    pin_inst_id bigserial primary key,
    part_inst_id bigint …