标签: database-design

我为足球比赛创建了数据库。

我有 2 个具有多对多关系的表，因此我还创建了一个连接表：

裁判

CREATE TABLE referee (
  id_referee INT IDENTITY PRIMARY KEY,
  id_type_referee INT NOT NULL,
  first_name varchar(20) NOT NULL,
  last_name varchar(30) NOT NULL,
  date_of_birth DATE NOT NULL,
  FOREIGN KEY(id_type_referee) REFERENCES type_referee(id_type_referee)
);

比赛

CREATE TABLE match (
  id_match INT IDENTITY PRIMARY KEY,
  id_stadium INT NOT NULL REFERENCES stadium(id_stadium),
  id_season INT NOT NULL REFERENCES season(id_season),
  date_of_match DATE NOT NULL,
  audience INT CHECK (audience>=0)
);

接线台

CREATE TABLE match_referee(
  id_referee INT NOT NULL,
  id_match INT NOT NULL,
  PRIMARY KEY(id_referee,id_match), …

我想通过添加一列来更改表格。到目前为止，这里没什么可看的，但我想让这个列成为复合键的一部分，即，我现在有一个布局

table_name( Field_1  datatype PK, Field_2 datatype,....) 

并且我希望插入的列，比如 Field_k 与现有的单字段 PK 一起成为 PK 的一部分。

我还没有找到有关如何执行此操作或是否可行的任何来源。请问有什么建议吗？

我已经开始为我工作的公司设计一个数据库。我很好奇专业人士会如何设计这样的数据库以及您可能会提出什么建议。

数据库的相关资料：

数据库反映了完全不同的活动。基本上有大约七个活动，每个活动都携带自己的信息集。这意味着很难标准化数据库并简单地制作一个称为“活动”的表，该表足以满足整个数据库的需求。

我正在考虑为每个活动使用一个单独的表格，并将它们链接到几个包含基本信息的表格，例如地理信息和/或参与的员工。

如果是这样，那么我至少知道我在正确的道路上，如果我不正确，那么我学到了一些重要的东西！

如果提供的信息不完整，请随时询问更多信息！

我有两个表，一个是 product，它是一个带有一个主键的父表，我有另一个产品的子表，它是一个 product_details 表。但是子表使用逻辑数据而不是外键与父表（产品）链接，因为我们在编码端的java代码的帮助下建立这种关系，而不是依赖于数据库，这使得它变得紧密夫妇。为了避免表之间的紧密耦合，我们将主键值存储在子表中。

请参考这张图片，其中包含在产品和产品详细信息表之间创建逻辑关系的数据。

脚本是：

CREATE TABLE `tbl_product` (
  `product_id` varchar(200) NOT NULL,
  `product_details_id` varchar(200) DEFAULT NULL,
  `currency` varchar(20) DEFAULT NULL,
  `lead_time` varchar(20) DEFAULT NULL,
  `brand_id` varchar(20) DEFAULT NULL,
  `manufacturer_id` varchar(150) DEFAULT NULL,
  `category_id` varchar(200) DEFAULT NULL,
  `units` varchar(20) DEFAULT NULL,
  `transit_time` varchar(20) DEFAULT NULL,
  `delivery_terms` varchar(20) DEFAULT NULL,
  `payment_terms` varchar(20) DEFAULT NULL,
  PRIMARY KEY (`product_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;



 CREATE TABLE `tbl_product_details` (
  `product_details_id` varchar(200) NOT NULL,
  `product_id` varchar(200) DEFAULT NULL,
  `product_name` varchar(50) DEFAULT NULL,
  `landingPageImage` varchar(100) DEFAULT …

我将从一个示例数据库设计开始，让您了解我目前正在处理的内容。

我有一张桌子，里面放着所有品牌的车辆，还有一张桌子，里面放着每个品牌的模型。这将导致以下数据库设计：

使

• ID
• 姓名

楷模

• ID
• 姓名
• 制作 ID

到目前为止，它非常简单，但现在有点困难，它在我的场景中引入了“不可避免的”循环引用。我要介绍另一个名为 Vehicles 的表，用于配置特定的车辆。

车辆

• ID
• 制作 ID
• 型号标识
• 变体（例如 3.0 TDI，只是一个纯文本字段）。

我来这个设计的原因是因为我有一个前端 Web 应用程序，它允许用户填写表单来配置车辆。在表单内，用户会看到两个选择框，一个用于品牌，另一个用于模型。在这种情况下，一旦用户选择了一个品牌，属于一个品牌的模型就会动态加载，因此模型和品牌之间的 FK 关系。

可能的解决方案：

1) 从 Vehicles 表中删除 FK 关系，只存储品牌名称和型号名称，但如果由于某种原因这些值发生变化，已插入的车辆记录将不会显示更新的名称。

2) 仅将 ModelId 存储在 Vehicles 中

3) 在 Vehicles 和 Makes 和 Models 之间创建一个多对多表，并将多对多表的 Id 作为 FK 存储在 Vehicles 表中。然而，这需要前端根据 MakeId 和 ModelId 执行查找，以获取多对多表的 id。

推荐哪种方法？有更好的选择吗？

我“即将”在我的一个应用程序上实现一项功能，该功能需要存储大量数据（播放列表）。

假设以下场景：

• 一个用户可以有多个播放列表
• 这些播放列表最多有 50 万个条目（可能更多）
• 我必须能够获取、删除、重新排序或查询整个播放列表或使用索引
• 目前每个用户都有一个播放列表；但
• 我即将实现一项功能，允许用户拥有 1 个以上的播放列表。
• 每个播放列表大约有 3500 个条目。有些可以高达 590k。

播放列表条目由以下类表示：

public class Item {
  private Long owner; // User
  private String data;
  private String name;
  private String author;
  private int index; // Index of this item on the list
}

TL;DR：List< Item >对于每个用户（每个用户超过 1 个），此列表可以扩展到 500k+ 个条目。

目前，我为此使用了基于 SQL 的存储，但是，它很慢，特别是当我需要移动索引时 - 慢到我的数据库驱动程序认为连接失败并泄漏的程度。

解释“移位索引”：假设我正在删除第 3 个索引 ( i = 3)处的一个项目，这意味着它之后的所有其他项目都需要向下移动一个索引，因此我稍后可以请求索引 3 并获取该项目以前是索引 4。

目前，我会在Order删除后减少所有元素的播放列表的列值。

当前播放列表项目表设计

Id (Ordering/Index) | PlayList …

我们正在 SQL 服务器表中进行并行、多线程插入，并希望减少闩锁。

利用散列分区来减少闩锁的缺点是什么？从本质上查询所有这些拆分的分区表是否降低了查询速度？

我们有大约 120 表插入每秒，金融系统。

其他注意事项：SQL 2016 系统每年将使用大约 50 GB 的 SSD 硬盘空间。目前，拥有 50 个核心处理器和 150 GB 的 RAM。

平台未搭建，所以没有基线测试；但我需要制定测试计划和策略。

哈希分区示例： http : //www.madeiradata.com/how-to-solve-the-tail-insert-problem-2/

CREATE PARTITION FUNCTION pf_hash (TINYINT) 
AS RANGE LEFT FOR VALUES (0,1,2,3,4,5,6,7,8);

CREATE PARTITION SCHEME ps_hash 
AS PARTITION pf_hash ALL TO ([PRIMARY]);

CREATE TABLE dbo.UserEntries_RegularWithHash 
(   
Id BIGINT IDENTITY NOT NULL,
UserId INT NOT NULL ,
CreatedDate DATETIME2 NOT NULL,
HashId AS CAST(Id % 9 AS TINYINT) PERSISTED NOT NULL,
CONSTRAINT PK_UserEntries_RegularWithHash 
PRIMARY KEY CLUSTERED …

我们有一个 Postgres 设置，其中包含多个表，代表项目的不同部分和阶段，目前有 4 个，但将来可能会更多。我们想要制作一个Task带有这些表中任何一个的外键的表。最好是这样的：

CREATE TABLE stage1(
id SERIAL PRIMARY KEY,
description TEXT);

CREATE TABLE stage2 (
id SERIAL PRIMARY KEY,
description TEXT);

CREATE TABLE stage4 (
id SERIAL PRIMARY KEY,
description TEXT);

CREATE TABLE task (
id SERIAL PRIMARY KEY,
description TEXT,
foreignkey_table VARCHAR(20),
foreignkey_id INTEGER);

其中命名的列foreignkey_table可以指示“父”表，并且foreignkey_id将指示“父 ID”。

这些阶段 1 到 3 是为了使示例简单，但它们绝不能合并为一个。将它们视为“准备阶段”、“执行阶段”和“评估阶段”。或者作为完全不同的表格，如“用户”、“公司”和“活动”，每个表格都有自己特定的不重叠内容。

我怎样才能做到这一点？

我读过一些帖子，说这是不可能的，但它们已经很旧了，所以我希望在这些帖子之后实施解决方案。我还在Constraint for multiple foreign key上找到了一个潜在的解决方案，但它是互斥的 (PostgreSQL)，这是我目前最好的后备选项。

我有一个包含以下列的表格清单

ChkId, Q1_ID, Comment1, Checked1, Q2_ID, Comment2, Checked2, ... Q200_ID...

我有一个包含以下列的表格问题

Q_ID，提示

如何用匹配的 Questions.Prompt 替换 Checklist.Q#_ID 而不将它们加入最多 200 次？有没有优雅的解决方案？

根据我们组织的一些数据库管理员的说法，通常不建议在我们的 MySQL 数据库中实际强制执行外键关系。相反，最好用伪外键 ID 列简单地表示它，并为外键强制执行额外的应用程序处理。原因是随着数据库的扩展，插入和删除（尤其是级联的）变得非常昂贵。

但这不是违背了 RBDMS 的初衷吗？据我了解，似乎使用 RBDMS 开始的最大原因之一（除了强制 ACID 属性）是确保最小化涉及相关（即通过 FK 由连接表绑定）对象的应用程序查询处理。

那么使用伪外键和附加应用程序处理通常更实用吗？而且，如果是这样，您为什么还要使用 RBDMS？我认为原因是应用程序处理仍然比 NoSQL 解决方案略少（而且更直接）？