Чем меньше столов, тем лучше, чем больше?

Question

Я внедряю небольшое приложение для отслеживания времени и не могу выбрать между двумя проектами базы данных.

Первый имеет все записи журнала в одной таблице, т. Е.

TimeLog
-------------
job_id   :  long
timestamp
start    :  boolean [or perhaps 'type : enum']
_id      :  long

Другой вариант - две таблицы: одна для записей «старт», другая для записей «стоп».

StartLog                     StopLog
-------------                -------------
job_id   :  long             job_id   :  long
timestamp                    timestamp
id      :  long              id      :  long

Каковы плюсы и минусы каждого подхода? Есть ли другая альтернатива?

Мое конкретное приложение будет работать на SQLite, и я хотел бы оптимизировать его для скорости, но меня интересуют общие аргументы.

Answer 1

Я бы пошел на первый (однотабличный, дифференцированный по типу) проект, не особенно потому, что там слишком много таблиц, а просто потому, что объекты базы данных очень похожи и имели бы аналогичные ограничения и операции.

Answer 2

Я бы использовал первый дизайн: одну таблицу базы данных. Как сказал Cade Roux, сущности очень похожи и будут иметь схожие ограничения и общий набор операций. Кроме того, я предлагаю переименовать поле start в поле с именем type с типом данных enum.

Предположим, в какой-то момент вы хотели бы записывать другое время, а не только время начала и окончания. Наиболее очевидный пример - работодатели, записывающие перерывы между работниками. Некоторые работодатели платят своим работникам за короткие перерывы, возможно, продолжительностью 15 минут или меньше. Вы не хотите, чтобы они полностью выбили (т. Е. Ушли "вне времени"), но вы do хотите указать тот факт, что они начали свой период перерыва, для расчет заработной платы и законные цели (например, обязательные перерывы каждые n часов, как того требует закон).

Table "TimeLog"
---------------
job_id     :  LONG
timestamp  :  TIMESTAMP
type       :  ENUM [ "punch-in", "punch-out", "break-start", "break-stop" ]
_id        :  LONG

Это можно легко сделать с помощью поля type с типом данных enum. Вы можете иметь punch-in, punch-out, break-start и break-stop, в случае вышеприведенного примера.

Answer 3

Первый вариант самый лучший на сегодняшний день. Обе операции (Пуск / Стоп) имеют общие атрибуты. С этим дизайном вы будете в лучшем положении, если требования изменятся (например, если будет создана операция «Отмена»).

Answer 4

Я думаю, это зависит от того, какие запросы вы будете использовать больше.

Если вы в большинстве случаев запрашиваете только начальные или конечные записи, но не оба, вы получите выгоду от меньших размеров таблицы.

С другой стороны, если вы в основном используете обе части в одном запросе, объединение результатов может замедлить работу.

Кроме того, вы уверены, что хотите оптимизировать скорость? В большинстве случаев скорость не является проблемой, и вам следует беспокоиться о том, какой подход имеет больше смысла.

Answer 5

На уровне логического дизайна, нет сомнений в том, что опция «две таблицы» является правильной.

На уровне ФИЗИЧЕСКОГО дизайна вы можете выиграть от дизайна с одним столом, если время начала / остановки очень часто требуется вместе.

Вы можете спросить, зачем проводить это различие? Четкое представление о логическом дизайне поможет вам лучше понять, какие данные на самом деле записываются в базу данных. Наличие логического атрибута в одной таблице «очевидно» не говорит о том, что речь идет о времени начала и окончания. Наличие двух различных «таблиц» (на логическом уровне) может лучше выполнять эту работу, особенно если у них есть слово «начало», соответственно. «стоп» в их именах.

На физическом уровне проектирования вы должны сосредоточиться на производительности, лучший способ достичь которой, как правило, состоит в том, чтобы получать данные, которые часто используются вместе, как можно ближе друг к другу физически (и редко бывает что-либо ближе, чем вместе в одном и том же). строка).