Когда лучше не использовать один столбец для нескольких возможных значений

«Получить правильно с первого раза» — это мантра для каждого проектировщика систем. Лучше проводить исследования, чтобы получить лучший опыт, чем начинать все сначала, когда мы слишком поздно осознаем, что делали что-то не так. Возможно, наш дизайн еще не оптимален, но мы можем улучшить его позже с помощью быстрых итераций. Обратный случай, если наш дизайн неверен с самого начала, мы должны все «переписать» в будущем.

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

Большинство из нас, как правило, используют эту архитектуру проектирования:

Выглядит просто, ха? Нам просто нужно установить связь между этими двумя таблицами с помощью CustomerID и OrderID в качестве ключей. Если клиент заходит на наш сайт или в наши приложения и создает корзину, он/она фактически делает неоплаченный заказ в нашей серверной системе. После того, как она/он оплатил свою корзину, нам нужно изменить статус с UnpaidOrder на PaidOrder.

Хорошо, мы говорим о цене этого дизайна:

  1. Прежде всего, мы должны хранить дополнительный статус для каждой строки.
  2. Всякий раз, когда клиент повторно посещает наш веб-сайт/приложения, нам нужно просмотреть таблицу заказов и проверить атрибут «Статус» каждой строки для этого конкретного клиента.
  3. После того, как она/он оплатил свой заказ, мы должны обновить статус заказа с «неоплаченный» на «оплаченный». Вы знаете стоимость процесса обновления, если сравните его с процессом вставки (в большой таблице).
  4. Бухгалтерия заботится только о транзакциях (читай: оплаченных заказах). Если они просят создать отчет или обновить определенный атрибут (скажем, неверную сумму перевода), нам потребуются дополнительные усилия, потому что (опять же) мы должны отделить оплаченные заказы от неоплаченных заказов.
  5. Если у нас есть огромные записи и быстрые действия, все вышеперечисленные процессы требуют дополнительного времени.

Мы можем сделать лучший дизайн;

Да, прежде чем вы жалуетесь на существование двух таблиц (таблица UnpaidOrder и таблица PaidOrder), поэтому нам нужно хранить разные данные в разных таблицах… Я говорю да, нам нужны эти две таблицы по уважительным причинам:

  1. Конечно, нам не нужен лишний статус для каждой таблицы.
  2. Всякий раз, когда клиент повторно посещает наш веб-сайт / приложения, нам просто нужно найти таблицу UnpaidOrder, где UnpaidOrderID НЕ СУЩЕСТВУЕТ в таблице PaidOder как PaidOrderID, тогда наша корзина готова.
  3. Наша таблица UnpaidOrder — это наша история заказов.
  4. После того, как она/он оплатил свой заказ, мы просто вставляем запись в PaidOrder со значением первичного ключа (не AUTO_INCREMENT), совпадающим с первичным ключом таблицы UnPaidOrder (AUTO_INCREMENT), поэтому нам не нужно дополнительное определение. таблица нормализации.
  5. Для некоторых целей, если нам нужно соединить таблицу Customer (с отношением «один ко многим») с таблицами UnpaidOrder и PaidOrder, мы можем использовать составной индекс.
  6. Если у нас есть огромные записи и быстрые действия, все вышеперечисленные процессы не требуют дополнительного времени.

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