Резервирование данных для заказа

0

Таблица order_detail:

order_no | Код товара

Таблица product_detail:

prod_id | имя_продукции | prod_size | prod_type

order_detail .product_id  references to product_detail.prod_id

Я слышал, что избыточность данных - плохая идея, поэтому я присоединяюсь к таблицам, чтобы отобразить полную информацию о заказе. Но проблема в том, что данные внутри product_detail могут быть отредактированы или удалены администратором, что означает, что когда я присоединяюсь к таблицам, они могут возвращать null. Должен ли я хранить что-то вроде примера JSON: {size:23,type:MZ} в order_detail чтобы избежать потери данных?

  • 0
    Используйте LEFT JOIN на order_detail
  • 1
    Не похоже, что админ делает хорошую работу.
Показать ещё 3 комментария
Теги:
mysqli
pdo

2 ответа

0

Я предлагаю вам рассмотреть возможность использования схемы, подобной той, что на диаграмме. (Стрелки - это конец "многих" отношений PK-FK.)

Этот подход поддерживает ссылочную целостность и избегает использования пустых значений путем записи удалений в отдельной таблице.

Вы также можете добавить функцию "ProductDataChangedOnDate", которая хранит записи об изменениях, сделанных этим надоедливым администратором :-)

Изображение 174551

0

Вам нужно будет разбить структуру таблицы.

Необходимость хранить данные в формате JSON в таблице order_detail ставит под угрозу нормализацию в вашей базе данных (что нежелательно).

Сделать атрибуты продукта как отдельные объекты.

  • Информация о продукте

id | имя | some_other_descriptive_columns | deleted_at

  • Тип продукта:

id | тип

  • Размер товара:

id | размер

  • Product_type_mapping: (сводная таблица, которая обозначает отношение "многие ко многим" между продуктами и их типами)

id | product_id | product_type_id | deleted_at

  • Product_size_mapping: (сводная таблица, которая обозначает отношение "многие ко многим" между продуктами и их размерами)

id | product_id | product_size_id | deleted_at

  • Как вы, наверное, уже заметили, у нас есть дополнительный столбец с именем deleted_at чей тип данных будет timestamp и которая nullable по умолчанию во всех таблицах, приведенных выше.

  • Когда администратор редактирует (может быть также удаление определенных размеров или типов) или удаляет продукт, все, что мы делаем, - это делаем запись метки времени в столбце deleted_at. Другими словами, мы делаем мягкое удаление.

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

  • 0
    @ Эшли какое-нибудь обновление?

Ещё вопросы

Сообщество Overcoder
Наверх
Меню