Имеется БД mysql для админки в компании. Есть пара вопросов по её усовершенствованию.
1. Нормально ли, что для каждого простого списка (список офисов, список складов, список поставщиков и тп) нужна своя отдельная таблица? А то есть желание объединить все одну таблицу ”Списки“ (будет спец-поле, например, "type", определяющее, к какому списку относится запись), но мешает боязнь того что простой список может вдруг обзавестись дополнительным полем и стать "сложней" других.
2. Есть список заказов на обслуживание. У заказа тонна простых параметров, плюс сложные параметры, типа списка запчастей, где каждая запись тоже состоит из нескольких полей. Причем, всегда нужно знать кто из менеджеров и когда изменил какой либо параметр в заказе (например: добавил/удалил запчасть, изменил имя клиента, добавил дополнительный номер телефона клиента). Также у заказа есть статусы (готов, в работе, принят и т.п.) и нужно уметь фильтровать список заказов по их истории - например, нужно знать какие заказы были переведены в работу 2 дня назад и завершены вчера.
Сейчас простые параметры в заказе реализованы не как поля в таблице "Заказы", а как записи в отдельной таблице "Параметры заказов" с полями "ID заказа"/"Имя параметра"/"Значение параметра"/"Состояние параметра". При обновлении параметра, старому в состояние прописывается, что он удален, и добавляется новая запись. Некоторых параметров может быть несколько активных сразу (например, несколько номеров клиентов).
Это правильное решение? Или нужно было все одиночные параметры скинуть в отдельные поля таблицы "Заказы", а для множественные параметры раскидать по отдельным таблицам? И как тогда лучше всего следить за историей обновления Заказа? И как лучше делать фильтр по старым (измененным) параметрам?
1. Да, это называется "нормализация". Для приведенного вами случая - да, это должны быть разные таблицы. Правда есть еще single table inheritance, что удобно использовать если у вас есть несколько типов записей, которые должны выводиться одним списком (например). То есть, если говорить в ОО стиле, у вас есть базовый абстрактный класс, и несколько наследников. У каждого наследника свои поля, но в базе это все хранится как одна большая таблица и одно поле, разделяющее типы.
2. Тут сложно ответить наверняка, но все опять же упирается в нормализацию. Для хранения параметров существуют паттерны типа EAV (Entity-Attribute-Value)
Почитайте по нормализации. EAV не сильно сложный паттерн, но сразу хочется сказать что его реализация будет относительно медленной на выборку. Паттерны с наследованием таблиц обычно применяют в купе с ORM, если у вас есть мэппинг таблиц на объекты.
1. Да, нормально. Хотя в последних версиях MySQL, текущий вариант с выбором типа записи, будет работать точно также.
2. Думая, что надо разделить логику на текущее положение заказа и историю изменений.
Да, я думал об этом но сложности с переносом и неизвестность того, как хорошо и удобно это работает, отсутствие поддержки монго у большинства обычных хостеров на вирт-хостинге меня останавливает от этого.
