Отдельные таблицы в зависимости от бизнес-целей
Стоит ли разбивать таблицы на основании исключительно бизнес-цели?
ПРИМЕЧАНИЕ. Все таблицы имеют одинаковые столбцы.
1. Один стол
Одна таблица orders со столбцом orderType для их различения.
2. Два стола
ДВЕ таблицы под названием sales_orders и purchase_orders.
3. Множество столов
Как насчет еще большего количества таблиц, таких как sales_quotes, sales_orders, sales_backorders, purchase_requisitions, purchase_orders...
Я считаю, что подход 3 заходит слишком далеко, а подход 1 требует слишком большой умственной нагрузки, чтобы продолжать фильтровать две совершенно разные бизнес-цели.
Подход 2 кажется достаточным разделением, но не уверен, что он будет преследовать меня позже.
PS: Я знаю, что это основано на мнении, позвольте мне поделиться этим.
Насколько различаются порядки, на сколько столбцов они различаются? Я ожидаю, что продажи и покупки будут настолько разными, что вам не следует их объединять, но котировки, заказы и отложенные заказы можно объединить.
Знаете ли вы схемы доступа?
Подумайте о жизненном цикле (потоке управления) соответствующих объектов и участвующих пользователях/ролях как о руководящем факторе: один и тот же жизненный цикл => один объект, разные жизненные циклы => разные объекты...
@NickW Предложение о просмотрах отличное. Скажите, пожалуйста, почему вы предпочитаете один стол?
@Charlieface Заказы идентичны, т. е. между ними нет разных столбцов. Единственное разделение — ментальное, то есть экономическое обоснование.
@PeterCsala Нет, что ты под этим имеешь в виду?
@JulioDiEgidio Не могли бы вы сказать мне, что вы подразумеваете под жизненным циклом?
@Ivan В общем, с сущностями может быть связана диаграмма перехода состояний, представляющая то, что неофициально можно назвать их «жизненным циклом», который является самым основным компонентом того, что, точнее, в SE называется (представлением) « поток управления». Соответственно, в сущности можно найти атрибут «Состояние», позволяющий отслеживать текущее состояние. Например (и только для примера, поскольку конкретные решения зависят от требований), заказ может быть следующим: получен, принят к оплате, отклонен, отменен, отправлен, выполнен, оплачен, возвращен, отправлен обратно.
@Иван what do you mean by it? Знаешь, как их будут запрашивать? Вместе, по отдельности? Хотите ли вы объединить таблицы, если они хранятся в нескольких таблицах? Хотите индексировать их на основе одних и тех же столбцов? Есть ли у вас одинаковые ограничения для одних и тех же столбцов в разных таблицах? и т. д...
@Ivan Я предпочитаю одну таблицу, поскольку это самое простое решение для создания, заполнения и обслуживания. Если это работает для вас, зачем усложнять жизнь, чем она должна быть? Плюс все эти обсуждения носят технический, а не деловой характер: бизнесу все равно, как хранятся их данные, а только то, как они им представлены. Если у вас нет технической причины для создания двух таблиц, используйте самое простое решение.
@NickW <<все это обсуждение носит технический характер>> Жизненный цикл объекта - это бизнес-(функциональное) требование, а не техническое. Тогда, конечно, реализация может сводиться к одной таблице, если этого достаточно, но это техническое решение.
@JulioDiEgidio, ок, мы можем согласиться не согласиться. Это одна из причин, почему на этом форуме не разрешены вопросы, требующие ответа, основанного на мнении :)
@NickW Ну, то, что этот вопрос основан на мнении, само по себе является мнением :), и я думаю, что мой ответ подразумевает, что технический ответ здесь, по крайней мере, базовый, по крайней мере возможен. Но, конечно, несогласие – это вариант.
Ответы 1
Стоит ли разбивать таблицы на основании исключительно бизнес-цели?
По моему мнению и опыту, краткий ответ – да. Действительно, не только оно того стоит, но и бизнес- (функциональные) требования фактически являются основным, если не единственным, руководящим фактором, особенно для концептуальной модели данных. Технические соображения, включая простую нормализацию, должны идти в ногу со временем, и в любом случае к ним следует относиться с осторожностью: чем больше реализация отличается от концептуальной модели (даже с точки зрения уровней абстракции!), тем менее она становится понятной и поддерживаемой (и расширяемый и др.). («Избегайте преждевременной оптимизации: уже на уровне проекта».)
Более конкретно, для конкретного критерия: рассмотрите жизненные циклы ваших объектов (представленные диаграммами перехода состояний, включая участвующих пользователей/роли): один и тот же жизненный цикл => один и тот же объект, разные жизненные циклы = > разные сущности.
(В общем, с сущностями может быть связана диаграмма перехода состояний, представляющая то, что неформально можно назвать их «жизненным циклом», который является самым основным компонентом того, что в SE называется (представлением) «потоком управления». Соответственно, в сущности можно найти атрибут «Состояние», позволяющий отслеживать текущее состояние. Например (и только для примера, поскольку конкретные решения зависят от требований), Заказ может быть: Получено, TakenChargeOf, Отклонено, Отменено, отправлено, выполнено, оплачено, возвращено, отправлено обратно.)
Одна таблица, 2 представления (если действительно нужно разделить типы)