标签: database-normalization

我正在存储有关棒球统计数据的数据,并希望使用三个表格来执行此操作:player,battingStats和pitchingStats.出于问题的目的,每个玩家将有击球统计数据或投球统计数据,但不是两者都有.

我如何在3NF中规范这种关系？

假设我有一个与另一个表具有 1:0..1 关系的客户表，我通常会在客户表中有一个指向另一个表的 Nullable FK。

然而，假设与客户相关的附加可选数据片段的数量增加，并且仅出于论证目的，表的数量现在为 10 个。是否最好使用相同的架构，以便客户中有 10 个附加列表，如果没有存储额外的数据，则全部可能为空，或者让 FK 指向子级的客户表更好吗？这个模型看起来更简洁，因为我没有大量可为空的列，并且如果需要，我可以通过简单地添加新表和指向新表中的客户的新 FK 列来逐渐扩展系统。唯一的缺点是（查看数据库）您可以添加更多行来打破 1:0-1 关系规则。但是，我的应用程序无论如何都不会插入额外的行。

第一种方法要求我为添加到系统中的每个新表在客户表的末尾添加一个新列。

在这种情况下哪种方法最好？

我正在设计一个具有不同类型地址的系统.例如,人员地址,酒店地址,机场地址,办公室地址.

我参与讨论,我认为由于地址不同(不同实体酒店,机场等),地址应存储在单独的表格中.我认为这会提高性能.

还有另一种意见是将所有地址放在同一个表中.

我正在使用PostgreSQL,我正在查看超过1000万条记录.

您认为更好的设计是什么？

我期待着你的意见.

此致,Shardul.

我需要设计一个数据库表，其中大多数属性都有单位。例如：

Readings
--------

id   load (kW)   fuel_consumption (tonnes) - etc
1    1154        89.4
2    1199        54.2

在设计中捕获单元的推荐方法是什么？例如，我可以：

• 在属性名称中存储单位，例如 load_kW 和fuel_conspiration_tonnes
• 将单位存储在单独的表中，例如每个值都成为另一个表的外键，其中包含值和单位的列。
• 存储在数据库外部：例如在业务逻辑中或在文档中
• 还有其他人吗？

我碰巧使用 MySQL，但我认为这是一个通用的数据库规范化问题。

简单的数据库设计问题,我老实说不能完全指责.

在很多情况下,我有一个类型表,它由一个ID和类型的名称组成.Ala.语言代码表有2列

表: language

language_id (1,2,3)                 
language_code (et, en-us, de)

现在我总是把language_id作为其他表的外键,

但

哪个更好？

分发language_id为外键,然后联接得到language_code.

要么

language_id完全忽略我们所拥有的

表: language

language_code (et, en-us, de)

然后,当我们想知道用户的母语是什么时,我们将只将代码作为外键分发,并且不需要任何连接.

意见？

简短介绍 - 数据背后的逻辑

我正在研究一个存储实验数据(拉曼光谱)及其元数据的PostgreSQL数据库.除了我们的样品的"正常"光谱之外,还必须获取并保存用于仪器校准目的的特殊光谱.

每次我进行实验时,我都会在表中创建一条新记录measurements,在此我指定measurement type相应的元数据(其他表的外键).

问题是,元数据类型的不同取决于measurement type:

1. 样品测量 - 我们必须sample_id从表中存储samples
2. 标准物质 - 在这种情况下,我们指定表中的物质 substances
3. source_id必须提供特殊标准化光源
4. 暗帧 - 简单,不需要来自其他表的数据

样品,物质和光源具有完全不同的属性,因此我们必须将它们保存在单独的表中,measurements通过外键链接到表中.我认为我的数据在这里有多态关系(如果我错了,请纠正我).

问题

在当前设计中,存储在列measurementtype_id(突出显示为红色)中的值定义必须NULL编辑哪些外键(突出显示为黄色)以及哪些必须包含值.

表关系

我很确定这个设计违反了第三种常规形式.我们可以有一个场景,当错误类型的元数据与测量相关联时.如何确保数据完整性？不幸的是,到目前为止我找不到合理的解决方案......

我对这种形式的正常化很陌生。我以前曾使用过 4NF，但目前 5NF 似乎很混乱，我想知道是否有任何规则说明何时适合应用这种结构，或者我是否必须开始思考和使用它今后。

PS：我读过它并且我有点理解；我只是想知道是否存在某些情况下最好使用它或不使用它，如果是的话，什么时候使用它。

我在Azure SQL Server数据库中有一个表,它只是一个nvarchar(max)包含JSON字符串的列,如下所示,每行一个扁平化为一行(约200,000行)

{
    "username": "George84",
    "items": [{
            "type": 8625,
            "score": "90"
        }, {
            "type": 8418,
            "score": "84"
        }, {
            "type": 7818,
            "score": "90"
        }, {
            "type": 23,
            "score": "q"
        }
    ]
}

每条记录都有一个用户名和一个包含一个或多个条目的项目数组.items数组中的每个条目都包含一个类型字段(整数)和一个得分字段(字符串).用户名是唯一的.多个用户可能具有相同类型的项目,并且这些重复项可能具有相同的分数,也可能不具有相同的分数.

我想将其转换为一组新的正确规范化的表,其架构如下所示:

我知道我可以使用外部应用程序来完成它,但我希望利用SQL Server 2016的新JSON处理功能完全在数据库/ TSQL中完成.

完成此转换的最佳方法是什么？

许多 DBMS 开始允许在数据库中使用 JSON。这违反了 1NF 吗？

1NF 的规则之一是不在一列中存储多个值。但我们存储的是 JSON，它可以包含键值对。这是否违反规则？

我已经接管了一个存储健身信息的数据库,我们正在讨论某个表格,以及它是应该保留为一个表还是分成三个表.

今天,有一个名为:锻炼的表,其中包含以下字段

id,exercise_id,reps,weight,date,person_id

因此,如果我在一天内完成了2组3个不同的练习,那天我将在该表中有6个记录.例如:

ID,exercise_id,代表,重量,日期,PERSON_ID
1,1,10,100,1/1/2010,10
2,1,10,100,1/1/2010,10
3,1,10,100,1/1/2010年,10
4,2,10,100,1/1/2010,10
5,2,10,100,1/1/2010,10
6,2,10,100,1/1/2010, 10

所以问题是,鉴于多个记录中存在一些冗余数据(date,personid,exercise_id),是否应将其标准化为三个表

WorkoutSummary:
- id
- date
- person_id

WorkoutExercise:
- id
- workout_id(外键进入WorkoutSummary)
- exercise_id

WorkoutSets:
- id
- workout_exercise_id(外键进入WorkoutExercise)
- 代表
- 重量

我猜测的缺点是在重构之后查询会更慢,因为现在我们需要连接3个表来执行之前没有连接的相同查询.重构的好处允许将来在锻炼总结级别或锻炼级别添加新字段而不添加更多重复.

关于这场辩论的任何反馈？