主页 / dba / 问题

问题[database-design](dba)

Martin Hope
Carl Schmidt
Asked: 2025-01-23 08:48:39 +0800 CST
  • 5

这是我正在使用的架构：数据库设计

以下是在https://dbdiagram.io/d中重新创建的 DBML ：

Table University {
  ID integer [primary key]
}

Table Professor {
  ID integer [primary key]
  UniversityID integer [primary key, ref: > University.ID]
}

Table Class {
  ID integer [primary key]
  UniversityID integer [primary key, ref: > University.ID]
  ProfessorID integer [null]
}

Ref: Class.(ProfessorID, UniversityID) - Professor.(ID, UniversityID)

我的目标：

  • 一所大学可以有多个班级和教授。
  • 一个班级可以有一位教授，或者没有教授。
  • 删除一所大学会删除其所有教授和课程
  • 删除教授会将 Class.ProfessorID 设置为 NULL

最后一个目标给我们带来了问题。由于存在多个级联路径，SQL Server 会阻止添加另一个级联外键约束，并且触发器无法工作，因为：

  1. 由于 Professor 上的外键约束，删除查询被拒绝，因此 FOR DELETE 触发器永远不会运行
  2. 由于与大学的级联关系，SQL 无法创建 INSTEAD OF DELETE

我怎样才能实现这个目标？

database-design
Martin Hope
Marlon Brando
Asked: 2025-01-22 21:48:54 +0800 CST
  • 6

在我目前正在阅读的书中，提到了该表作为示例，说明如果表满足 BCNF 但仍然有冗余，我们可以做什么。然后它提到解决方案是数组。但是该表是否符合 BCNF？语言 -> PersNr 和编程 -> PersNr 之间是否存在函数依赖关系。这两个属性都不是超键，因为它们不能唯一地标识行。所以在我看来，它们破坏了 BCNF。还是我误解了什么？

在此处输入图片描述

database-design
Martin Hope
Amessihel
Asked: 2024-12-24 00:22:44 +0800 CST
  • 5

我正在设计一个应用程序（带有 sqlite的Python），它可以处理一些贡献者随时间跨多个群体移动的情况。

我的设计目前看起来像（PK 为粗体，FK 为斜体，如果 FK 是 PK 的一部分则为斜体）：

  • 组（ID，名称）
  • 贡献者（ID，姓名，名字）
  • 动作（动作ID，名称）
  • 贡献者动作（贡献者ID，动作ID，日期）
  • 会员资格（群组 ID、贡献者 ID、开始日期、结束日期）

我的目标是保留会员资格的历史记录，以便在特定贡献时检索贡献者的正确会员组。

这样做涉及在主键（会员表）中使用日期列。但是，EndDate这可能是NULL针对贡献者的当前会员资格，而且我读到这可能不是一个好的（甚至是允许的）做法。

我是否遗漏了某些内容以至少获得 3NF 设计？

database-design
Martin Hope
ncmprbl
Asked: 2024-12-06 01:57:16 +0800 CST
  • 6

展览

假设我们的系统有用户和一些游戏。我们把这些游戏称为A、B和C。

为了简单起见，我们的初始表格如下所示：

CREATE TABLE IF NOT EXISTS users (
    id SERIAL PRIMARY KEY
);

CREATE TABLE IF NOT EXISTS games (
    id SERIAL PRIMARY KEY
);

问题

每当我们玩这些游戏并完成它们时，我们都必须记录与特定用户的游戏相关的统计数据。例如，对于游戏A，我们必须记录total_jumps和total_crouches，因为游戏的机制允许这种累积，但是游戏B和C可能要求我们记录其他total_*字段（尽管前缀total_不是必需的）。我该如何存储这些信息？

我对这个问题的解决方案感到困扰。我想出了两种方法：

解决方案 1

有一张表用于此：

CREATE TABLE IF NOT EXISTS statistics (
    user_id SERIAL REFERENCES users (id) ON DELETE CASCADE,
    game_id SERIAL REFERENCES games (id) ON DELETE CASCADE,
    fields JSONB,
    PRIMARY KEY (user_id, game_id)
);

这样，我们就可以将来自字段列的任意数据解析到应用程序级别。

解决方案 2

有多个桌子，每个游戏一个：

CREATE TABLE IF NOT EXISTS A_statistics (
    user_id SERIAL PRIMARY KEY REFERENCES users (id) ON DELETE CASCADE,
    total_jumps INTEGER,
    total_crouches INTEGER
);

就我个人而言，解决方案 #2 看起来更好，但是...这个问题仍然困扰着我。好像我错过了什么，因为这两个选项都不能使扩展（添加新游戏）变得更容易？假设我们添加游戏D、E和F。这两种解决方案都要求我们以某种方式处理这些游戏所需的特定字段（在应用程序级别）。这是我必须接受的事情吗？或者是否有第三个更好的解决方案，我只是没有看到？

database-design
Martin Hope
J. Mini
Asked: 2024-12-01 09:30:15 +0800 CST
  • 5

我最近一直在研究 Microsoft SQL Server 的列存储索引，我开始担心我的经验与行业经验不符。列存储索引旨在使聚合变得容易。人们经常说，出于这个原因，它们非常适合事实表。

这让我感到不安。根据我的经验，事实表不是聚合的。我制作的每个事实表的列表都是“主键后跟几个维度列，后跟我们存储的有关主键的每一点信息”的形式。然后它们被转储到 PowerBI 或 ThoughtSpot 等 BI 工具中，因此非技术人员可以根据维度进行筛选并找到他们想知道的任何信息。它们可能会不时聚合，但这肯定不是表格的主要用途。我预计这样的表格会有超过 100 列。

我所描述的表设计和访问模式是否符合事实表的预期？或者我所描述的是一种完全不同类型的表，而我不知道它的名称？

database-design
Martin Hope
mowalid0
Asked: 2024-11-22 16:30:22 +0800 CST
  • 5

我现在正在制作一个银行系统数据库，在帐户实体的情况下，将其作为外键（分支机构 ID、客户 ID、服务 ID、四个生成的整数）的主键组合，用于贷款等上下文服务，或者使它们仅为普通外键。如果您可以提供一个更一般的案例，其中复合键是最佳用例

database-design
Martin Hope
it's not me
Asked: 2024-09-27 19:38:35 +0800 CST
  • 7

我和我的朋友正在为职业足球联赛创建 ER 图，我们对数据库都很陌生，所以我们不确定我们所做的一切是否正确。

在建立教练与俱乐部的关系时，他做出了这样的决定：图表

我很困惑为什么 managedBy 和 signsWith 这两个关系是多对多。我的朋友说多个经理可以一次一对一地管理多个俱乐部。但那不应该是一对一吗？因为在任何时刻，一个俱乐部只能由一名经理管理，而一名经理只能管理一个俱乐部（在这种情况下我们不关心助理经理）；signsWith 关系也是如此。

那么我们当中哪一个人是对的？

database-design