Question

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

在这个特定保护伞中最基本的一切都是一个事件，所以我想到一个事件表，其中包含可能出现的所有属性的字段。然而，这可能是笨拙的，因为绝大多数领域最终将成为许多领域的空白;但我不确定这是否真的是一个问题。这种方式的好处是可以更容易地调用和显示所有事件。但由于许多事件只有“时间戳”的共同点，我怀疑它们是否属于同一张桌子。

我不确定为每种事件都有一个表是有意义的，因为单独使用大多数事件只有一个属性而不是时间戳，并且它们通常必须混合在一起。（许多类型的数据通常但不总是属于一个组）

某些类型的事件有持续时间。有些是比较罕见的。一类事件通常是保持不变的比率，除非费率被改变为良好或临时覆盖（这些是我最担心的）。有些是简单的二进制标记（我计划使用链接表，但为了方便起见，我需要/更喜欢整个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个例子，葡萄糖水平之间的葡萄糖水平之间的葡萄糖水平差异，没有食物吃，没有运动w / 2小时的床，因为设置最后一次更改，等等。 -program将根据参数自动分配标签。就像在指定的“午餐”期间吃了20个碳水化合物一样，它会说食物是午餐。如果在30分钟内有两个食物摄入量（或“膳食长度”偏好），它会将它们分组为一餐......不完全确定它现在如何起作用。

Answer 1

不，第二个你说“绝大多数字段最终会因许多条目而空白”，你的架构几乎肯定会被打破。

血糖应该在自己的表中，只有日期/时间和水平。如果您只是储存碳水化合物含量，同样的食物摄入量。如果您要存储膳食的各个组成部分，您应该在食物摄取表和食物成分表之间建立一对多的关系。

与胰岛素相同，具有时间戳和数量。

表示不同对象之间关系的正确方法是关系：外键等。

而且，作为一个“无关紧要的编程方面的一面”（关于事件的混合），如果你正在服用胰岛素并在餐厅吃饭同时，你可能做错了。大多数速效胰岛素需要半个小时才能开始正常工作，进入肠道的食物将在大约五到十分钟内开始产生糖分。所以在拍摄和吃饭之间应该有大约半小时的延迟。

我所知道的唯一常见的“同时或相似”事件就是餐前的血糖水平，以确保半小时前注射的胰岛素开始工作。

但我不是你的内分泌学家，我甚至不在电视上播放:-)所以先检查一下你的医疗用品。

Answer 2

“我的倾向是，最好有一些表格与密切相关的信息类型，而不是一张包含所有内容和大量空间的表格。但我不太确定如何继续。”

简单而且最好。为了了解原因，我们可以研究替代方案。

每个指标一个表。完全正常化但令人难以置信的疲劳。我通常是一个标准化的鹰派，而且我通常也会说'桌子是免费的'，当他们开始为数十或数百种类似的东西开始编号时，这并不完全正确。所以我们更喜欢更简单的东西。

另一方面，我们有一个E-A-V表，其值为test_id，metric_id，value。众所周知，这几乎不可能查询和使用。就像金星捕蝇草一样，带着甜美的花蜜吸引你，然后闭上你并吃掉你。

在抓握的手上，有一个包含所有可能列的大表。由于显而易见的原因，这被称为“稀疏”解决方案。我在直接营销中做到了这一点并且效果很好，但这是一个非常专业的情况，通常不推荐这种方法。

所以中间的某个地方是少数几个表，每个测试集都有一个表，具有相似的存储值。

嗯，这正是你的建议。听起来不错！

Answer 3

请看一下这些SO示例：one，two，three，four。

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

4 个答案: