Я создаю приложение, которое в качестве своей основной функции отслеживает различные данные с течением времени (уровни глюкозы в крови, дозы инсулина, потребление пищи и т. Д.), И я пытаюсь решить, как лучше всего организовать эту информацию в базе данных.
Самое основное в этом конкретном зонтике - это событие, поэтому я подумал о том, чтобы иметь одну таблицу Событий с полями для всех свойств, которые могут появиться. Это может быть громоздким, потому что подавляющее большинство полей окажется пустым для многих стран; но я не уверен, что это действительно проблема. Преимущество этого способа заключается в том, что будет проще вызывать и отображать все события. Но так как многие из событий будут иметь общую метку времени, я задаюсь вопросом, относятся ли они к одной таблице.
Я не уверен, что имеет смысл иметь таблицу для каждого вида событий, поскольку, взятые отдельно, большинство событий имеют только одно свойство, отличное от метки времени, и им часто приходится смешиваться. (многие типы данных часто, но не всегда, приходят в группу)
некоторые типы событий имеют длительность. некоторые сравнительно очень редки. Один класс событий, как правило, представляет собой скорость, которая остается неизменной, если скорость не изменяется навсегда или с временным переопределением (это те, о которых я больше всего беспокоюсь). Некоторые из них представляют собой простые двоичные теги (для которых я планировал создать таблицу ссылок, но для простоты мне понадобится / я бы предпочел общий 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) это локальная база данных, которая, как правило, будет одним пользователем, и никогда не будет необходимости сравнивать или взаимодействовать с записями других пользователей, если они синхронизируются в Интернете, поэтому я думал о сохранении одной версии базы данных для каждого пользователя, хотя, возможно, добавляя идентификатор пользователя при его загрузке.
3) многие события часто идут вместе для простоты интерпретации и анализа (например, уровень сахара в крови, еда, еда, болюсы, примечания), я считаю, что лучше делать это после фактов с запросами, а не жестко кодировать что-либо для поддержания целостности.
Некоторая информация о том, для чего будет использоваться база данных:
-Визуальное представление всех типов данных в течение дня
-Среднее все результаты теста и процент инсулина, который используется для питания, коррекции, базальных.
-А также конкретные расширенные запросы, такие как: перечислите до 20 примеров разницы в уровне глюкозы между уровнем глюкозы перед сном и утренней глюкозой, когда пища не употреблялась, и не выполнялась физическая нагрузка в течение 2 часов после сна, с момента последнего изменения настроек и т.д.
-program автоматически назначит теги на основе параметров. например, если во время назначенного «обеденного» периода употребляется> 20 углеводов, это означает, что еда - это обед. если в течение 30 минут есть два приема пищи (или предпочтение «длительность приема пищи»), они сгруппируют их как одно блюдо… не совсем уверен, как это будет действовать прямо сейчас.