Дизайн базы данных: та же структура таблицы, но другая таблица

Question

Мой последний проект имеет дело с большим количеством "промежуточных" данных. Как и при регистрации клиента, данные сохраняются в таблице customer_temp, а когда он проверяется, данные перемещаются в таблицу customer.

Прежде чем я начну снимать электронные письма, неистовствуйте, думая, что это неправильно, и вам просто нужно поставить флажок в ряд, всегда есть вероятность, что я идиот. Кто-нибудь может объяснить мне, почему это желательно? Создание 2 таблиц с одинаковой структурой, заполнение таблицы (таблица 1), а затем перемещение всей строки в другую таблицу (таблица 2) при возникновении определенных событий.

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

Но я не могу понять, хранит ли таблица 2 оперативные данные, которые могут постоянно меняться.

Подведем итог: Кто-нибудь может объяснить, насколько неправильным (или правильным) этот, казалось бы, контрпродуктивный подход?

Answer 1

Если существует существенная разница между «клиентом» и «потенциальным клиентом» в бизнес-логике, то их разделение в базе данных может иметь смысл (вам не нужно всегда помнить, чтобы запрашивать по флагу, для пример). В частности, если данные, хранящиеся для этих двух, могут в будущем расходиться.

Это несколько упрощает отчетность и снижает вероятность того, что оба типа объектов будут рассматриваться как один и тот же.

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

Answer 2

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

Например, это может уменьшить конфликт между процессами, которые хранят новых потенциальных клиентов, и процессами, обращающимися к существующей базе клиентов.Или это может позволить ограничить определенные столбцы, чтобы они не были нулевыми в таблице клиентов, которым разрешено быть нулевыми в таблице потенциальных клиентов.Или это может позволить жестко контролировать доступ на запись к таблице клиентов и быть недоступным для операций, исходящих из Интернета.

Или оригинальный дизайнер просто не увидел преимущества, которые мы с вами видим в одной таблицедизайн.

Answer 3

Каждый раз, когда я вижу постоянные имена таблиц "customer_temp", я вижу красный флаг.Как правило, это означает, что кто-то работал над проблемой, когда они шли вперед, и не думал об этом заранее.

Что касается структуры, которую вы описываете, есть некоторые преимущества.Например, таблицы могут индексироваться по-разному или размещаться в разных местах файлов для повышения производительности.

Но обычно эти преимущества не стоят затрат на поддержание синхронизации структур при изменении (добавление столбца к поиску в разных таблицах).для двух наборов зависимостей и т. д.)

Если вам действительно нужно, чтобы они обрабатывались по-разному, лучше справиться с этим, добавив слой абстракции с представлением, а не создав две отдельные модели.

Answer 4

Кажется, есть несколько объяснений того, почему вы хотите "customer_temp".

1. Как вы заметили, это будет для архивных целей. Чтобы можно было анализировать данные, но в этом случае исторические данные должны быть агрегированы по интересному запросу. Однако использование реальных данных не выглядит правдоподобным

2. Как уже отмечалось, существует определенная бизнес-логика, которая различает клиента и потенциального клиента.

3. Или это может быть функция безопасности, которая требует регистрации всех попыток регистрации клиента в дополнение к хранению утвержденных клиентов.