一个表还是多个表，用于许多不同但相互作用的事件？

Question

我正在创建一个应用程序，该应用程序的核心功能是随着时间的推移跟踪各种数据（血糖水平，胰岛素剂量，食物摄入量等），并且试图确定如何最好地在数据库中组织这些信息。

从最基本的角度来看，在这个特定总括内的所有内容都是一个事件，因此我想到了一个带有包含所有可能出现的属性的字段的Events表。但是，这可能很麻烦，因为绝大多数字段最终对于许多字段都是空白。但我不确定这是否真的是一个问题。这种方式的好处是将更容易调用和显示所有事件。但是由于许多事件仅具有“时间戳记”共同点，因此我质疑它们是否属于同一表。

我不确定是否为每种类型的事件都拥有一个表是有意义的，因为将事件分开单独进行，大多数事件除了时间戳之外，只有一个属性，而且它们通常必须混合在一起。（许多类型的数据通常但并非总是成组出现）

某些类型的事件具有持续时间。有些是相对非常少见的。一类事件通常是保持不变的比率，除非永久改变比率或暂时更改比率（这些是我最担心的比率）。有些是简单的二进制标签（我打算在上面有一个链接表，但是要简单起见，我需要/最好使用一个整体的event_id进行链接。

我的倾向是最好有几个表具有密切相关的信息类型，而不是一个表包含所有内容和很大的空间。.但是不确定如何进行。

我希望就在这种情况下确定最佳方法的策略提供一些建议。

编辑：这是我正在处理的数据类型的摘要，以防万一，使事情更清晰

events:
-blood glucose 
     timestamp
     value 
     (tagged w/: from pump, manually entered
     [pre-meal, post-meal (breakfast, lunch, dinner) before bed, fasting, hypo, high, hyper  - which will be either manually entered or inferred based on settings or other user entries], before/after exercise etc i imagine would be better off dynamically generated with queries as necessary. though could apply same paradigm to the meals?

-sensor glucose (must be separate bc it is not as reliable so will be different number from regular bg test, also unlikely to be used by majority of users.)
     timestamp
     amount

-bolus 
     (timestamp)
     bolus total
     food total
     correction total 
     active insulin**
     bolus type - normal[vast majority] square wave or dual wave

-food
     (timestamp)
     carb amount
     carb type (by weight or exchanges) <- this could probably be in user settings table
     food-description
     carb-estimated (binary) 
     meal? - or separate table.
     (accompanying bolus id? though that seems to finicky)

-meals
     timestamp
     mealname (breakfast, lunch, supper) (or mealnames table? seems excessive?)

-basal
     timestamp
     rate per hour
     rate changes throughout day on regular pattern, so either automatically fill in from 'last activated pattern' (in the form midnight: 0.7/hr, 7am: 0.9/hr, 12pm: 0.8/hr etc)
     create new pattern whenever one is used

-temp basal
     (regular basal pattern can be overridden with temporary basal)
     temp basal start
     ?temp basal end and/or temp basal duration
     temp basal amount
     temp basal type -> either in % or specific rate.

-exercise
     start-time
     end-time
     intensity
     ?description (unless 'notes' is universal for any event)

-pump rewind (every 3 days or so)
     -time

-pump prime
     -amount
     -type (fixed or manual)

-pump suspended
     start-time
     end-time

-keytones
     time
     result

-starred
     event

-flagged
     event

-notes
     timestamp
     (user can place a note with any event to provide details or comments, but might want a note where there is no data as well.)

(i want a way for users to flag specific events to indicate they are result of error or otherwise suspect, and to star events as noteworthy either to discuss with doctor or to look at later)

**only place I get active insulin from is when a bolus is entered, but it could be useful other times as a constantly tracked variable, which could be calculated by looking at boluses delivered up to X time ago where X is the Active Insulin Time.

other infrequent events (likely 2-10 per year):
-HbA1C 
     time
     value
-weight
     time
     value
     units
-cholesterol
     time
     value
-blood pressure
     time
     value

-pump settings (will need to track settings changes, but should be able to do that with queries)
     -timestamp
     -bg-target
     -active insulin time
     -carb ratios (changes throughout day like basal)
     -sensitivity
     -active insulin time

关注。1）将“事件”表与类型叠加在一起，以便在一段时间内快速带回所有事件，而不必查询每个表？（缺点是如何处理具有持续时间的事件？在事件表上具有可选的结束时间？）

2）这是一个本地数据库，通常将是一个用户，并且如果在线同步，则永远不需要比较或交互其他用户的任何记录，因此我考虑只保留一个版本的数据库每个用户，尽管可能会在上传时添加一个“用户”
ID。

3）许多事件通常会在一起使用，以便于解释和分析（例如血糖，餐食，食物，大丸剂，便笺），我认为最好是在查询事实之后再这样做，而不是硬编码任何代码以保持完整性。

有关数据库用途的一些信息：-一天中所有数据类型的可视化表示-
平均所有测试结果和用于食物，校正，基础的胰岛素百分比。-以及一些特定的高级查询，例如：列出多达20个示例，这些示例分别是自从上次更改设置以来，在未进食且两小时内没有运动的情况下，睡前葡萄糖和早晨葡萄糖之间的葡萄糖水平差异。
-program将根据参数自动分配标签。就像在指定的“午餐”期间吃了20多种碳水化合物一样，它会说食物就是午餐。如果30分钟内有两次进食（或“进餐时间”优先），则会将它们分组为一顿饭。

Answer 1

V1.0

在对数据进行组织和规范化时，关系数据库和SQL（专为它们而设计）的性能要好得多。就性能和关系能力而言，一个大表是未规范化的，并且已经瘫痪了。

您的需求需要一个普通的表的Supertype-Subtype集群。不幸的是，像这样的普通关系结构并不“常见”。

• 标准子类型符号是半圆。

  • Supertype :: Subtype的基数始终为1 :: 0–1。

  • 子类型主键是超类型主键。它也是超类型的外键。

• 有两种类型：

  • 排他性，每个超类型行只有一个子类型，用半圆X表示。

  • 非排他性，每个超类型行中有一个以上子类型

• 您的专属。此类型需要一个鉴别器，以标识超级类型行中哪个子类型处于活动状态。如果子类型的数量少，则可以使用指标；否则，需要分类表。

• 请注意，所有这些，结构，规则，约束，支持它以及提供数据完整性所需的信息都可以在普通的IEC / ISO / ANSI SQL中获得。（非SQL不符合SQL要求）。

数据

1. 命名非常重要。建议我们按行命名表格，而不要按内容，含义或动作命名。您说的是活动，但我只能看阅读。

2. 这些阅读或事件必须有上下文。我看不到EventId如何悬空。我假设阅读材料是针对特定患者的。请指教，我将更改其型号。

3. 复合键或复合键是正常的。SQL非常有能力（非SQL没有）。PatientId已经作为FK存在于中Reading，并用于形成其PK。不需要 额外的 ReadingId列和 额外的索引 ，这将是100％冗余的。

4. SQL还具有处理许多表的能力（我正在处理的数据库目前超过500个表），关系数据库的本质是大量较小的表。

5. 这是纯第五范式（没有重复的列；没有更新异常）。

   • 可以将其进一步归一化为第六范式，从而可以获得进一步的好处；并且可以优化6NF等。但这里并不需要所有这些。

   • 有些表恰好在6NF中，但这是结果，而不是意图，因此不能这样声明。
     。
     

6. 如果您提供有关您所关注的限制和替代的信息，我可以提供解决这些问题的模型。

7. 由于对数据 进行了 建模，因此已经将其设置为非常快速的比较（生成警报等）。