一个表还是多个表，用于许多不同但相互作用的事件？
我正在创建一个应用程序，其核心功能是跟踪各种数据（血糖水平、胰岛素剂量、食物摄入量等），并试图确定如何在数据库中最好地组织这些信息。从最基本的角度来看，这个特定的总结中的所有内容都是一个事件，所以我想到了一个具有所有可能属性的字段Events手表。然而，这可能很麻烦，因为绝大多数字段最终对许多字段都是空白的。但我不确定这是否真的是个问题。这样做的好处是更容易调用和显示所有事件。然而，由于许多事件只有时间戳的共同点，我质疑它们是否属于同一个手表。
我不确定是否为每种类型的事件都拥有一个表是有意义的，因为将事件分开单独进行，大多数事件除了时间戳之外，只有一个属性，而且它们通常必须混合在一起。（许多类型的数据通常但并非总是成组出现）
有些类型的事件持续时间。有些是相对罕见的。一种事件通常保持不变的比率，除非比率永久变化或暂时变化（这些是我最担心的比率）。有些是简单的二进制标签（我打算在上面有一个链接表，但为了简单起见，我需要/最好使用一个整体event_id进行链接。
我的倾向是，最好有几种与信息类型密切相关的表，而不是一种包含所有内容和大空间的表。.但是不确定怎么做。
在这种情况下，我希望提供一些建议来确定最佳策略。
编辑：这是我正在处理的数据类型的摘要，以防万一，让事情更清楚
events:-blood glucose timestamp value (tagged w/: from pump,manually entered ,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 square wave or dual wave-food (timestamp) carb amount carb type (by weight or exchanges)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 should be able to do that with queries) -timestamp -bg-target -active insulin time -carb ratios (changes throughout day like basal) -sensitivity -active insulin timebut 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分钟内吃两次（或吃时间优先），你会把它们分成一顿饭。
解决方案:
V1.0在组织和规范数据时，关系数据库和SQL(专门为他们设计)性能要好得多。就性能和关系能力而言，大表不规范，已经瘫痪。
你需要一个普通的表Supertype-Subtype集群。不幸的是，这种普通的关系结构并不常见。
标准子类型符号为半圆。
Supertype :: Subtype基数总是1 : 0–1。
子类型主键是超类型主键。也是超类型外键。
有两种类型：
排他性，每个超级行只有一个子类型，半圆形X表示。
非排他性，每个超级行都有一个以上的子类型
你的专属。这种类型需要一个识别器来识别超级类型行中哪种子类型处于活动状态。如果子类型较少，则可以使用指标；否则，需要分类表。
请注意，所有这些、结构、规则、约束、支持和提供数据完整性所需的信息都可以是普通的IEC / ISO / ANSI SQL(非SQL不符合SQL要求）。
数据
命名很重要。建议我们按行命名表格，而不是按内容、含义或动作命名。你说的是活的。动，但我只能看阅读。
这些阅读或事件必须有上下文。我看不见。EventId如何悬挂。假设阅读材料是针对特定患者的。请给我一些建议，我会改变它的型号。
复合键或复合键正常。SQL很有能力(非SQL没有）。PatientId已经作为FK存在于中Reading，并用于形成它PK。不需要 额外的 ReadingId列和 额外的索引 ，这将是100％冗余的。
SQL也有能力处理很多表(目前我正在处理的数据库有500多个表)，关系数据库的本质是大量较小的表。
这是纯第五范式(无重复列；无异常更新)。
它可以进一步归一化为第六范式，从而获得进一步的好处；并且可以优化6NF等等。但这里不需要一切。
有些表恰好在6NF但这是结果，而不是意图，所以不能这样说。
。
如果您提供您关注的限制和替代信息，我可以提供解决这些问题的模型。
因为数据 进行了 建模，因此设置为非常快速的比较(生成警报等)。
页:
[1]