#mysql #spring #postgresql #jpa
#mysql #spring #postgresql #jpa
Вопрос:
Одним из приложений, с которыми я работаю, является приложение Spring JPA clinical records. В нем есть две таблицы для отслеживания допусков; «Посещения» и «Поступления». Visits — это огромная таблица, содержащая записи о посещениях для 100 000 пациентов. Admissions — это «активная» таблица, содержащая только записи для поступивших в настоящее время пациентов. По мере выписки пациентов они удаляются из таблицы приема. Здесь мы думали, что пользователи в основном заинтересованы в текущих поступлениях, поэтому нам нужно, чтобы поиск текущих поступлений был быстрым — отсюда и таблица меньшего размера. Однако это добавляет сложности и накладных расходов, тогда как можно было бы просто иметь флаг «допущен» в таблице посещений, и вместо этого разрешенные в настоящее время запросы могут выполнять поиск по посещениям, что упрощает структуру приложения и, возможно, повышает производительность. Я понимаю, что здесь обычная форма и что она несколько нарушается дублированием данных в двух таблицах. Мне просто интересно узнать, будет ли предпочтительным подходом одна таблица или текущий дизайн будет считаться подходящим? Моя главная задача — производительность, и в тестировании нет существенной разницы (с точки зрения пользователя). Я не верю, что для этой проблемы существует какой-либо признанный «шаблон», но он может быть?
Комментарии:
1. Разделение
2. Меня только что поразила молния — @RangePartitioning — спасибо!
3. Разделение
4. Вы уверены, что количество посещений велико? Сто посещений для миллиона пациентов будут составлять 100 миллионов строк. Это большое, но не неуправляемо. (Я не совсем уверен, что разделение здесь сильно поможет, но я могу ошибаться)
5. Из того, что я читаю, разделение — это, по крайней мере, более «систематический» подход — лучше, чем иметь две таблицы со всеми накладными расходами на ведение записей в обеих.
Ответ №1:
Что представляет собой строка? Предположительно, не «человек», а какое-то действие (посещение, прием, выписка и т. Д.)?
Количество посещений будет в несколько раз превышать количество допусков?
Ограничены ли допуски «теми, кто в настоящее время занимает кровать»? Или в нее входят ранее выписанные пациенты?
Чтобы помочь с вышеуказанными вопросами, подумайте о том, какие запросы необходимо выполнить. И какие биты данных необходимы в этих запросах.
Учебники будут настаивать на одной «правильной» форме размещения базы данных. Я склоняюсь к прагматизму. Вот некоторые факторы, которые подтолкнули бы меня к отдельным таблицам:
- Количество строк, скажем,
visitsнамного больше, чем количество строкadmissionsв. - Существует нетривиальное количество столбцов, которые не отображаются в обеих таблицах.
- Многим запросам нужно просматривать только одну таблицу, а не другую. (
UNION ALLможет использоваться, когда вам нужны данные из обоих.) - «Общие» данные могут быть нормализованы из обоих. (Пример: информация о не-больнице о
person‘. Внимание:address, и т. Д. Может меняться со временем.) - Для оптимизации разных запросов необходимы разные индексы.
- Возможно, «допуск» является надмножеством «посещения»? То есть в каждой таблице может быть одна строка для одного события. (cf
JOINили, возможноLEFT JOIN.)
«Правильного» ответа нет. В конкурсе может даже не быть явного победителя. Реализуйте это одним способом, но с искренним намерением вернуться к вопросу через несколько месяцев.
Вы упомянули, что меньшая таблица быстрее — это зависит. Правильно проиндексированный размер таблицы оказывает лишь небольшое влияние на скорость. Когда нет жизнеспособного индекса, размер имеет значение. Итак… Продумайте SELECTs сейчас, еще до того, как вы создадите таблицы. Конечно, это вдвое больше работы, но это полезно — для обучения, для практики и для помощи в принятии решения.