Я ищу литературу или статьи.
Имеется довольно сложная админка для учета в фирме. Куча разных форм, куча разных данных. База - MySql, вся логика на js (angular) и микро-прослойка между базой и фронтом на php.
База уже разрослась до 20+ таблиц и, как мне кажется, я что-то делаю не так. Хочется узнать, как проектировать подобные системы.
Сразу скажу, что сейчас все работает. Но расширять и поддерживать становится все трудней.
Чтобы оценить уровень моего "непонимания", приведу пример вопросов, которые у меня возникают:
1. Нормально ли, что для каждого простого списка (список офисов, список складов, список поставщиков и тп) нужна своя отдельная таблица? А то есть желание объединить все одну таблицу ”Списки“ (будет спец-поле, например, "type", определяющее, к какому списку относится запись), но мешает боязнь того что простой список может вдруг обзавестись дополнительным полем и стать "сложней" других.
2. Есть список заказов на обслуживание. У заказа тонна простых параметров + сложные параметры, типа списка запчастей, где каждая запись тоже состоит из нескольких полей. Причем, всегда нужно знать кто из менеджеров и когда изменил какой либо параметр в заказе (или добавил/удалил запчасть, например). Также у заказа есть статусы (готов, в работе, принят и т.п.) и нужно уметь фильтровать список заказов по их истории - например, нужно знать какие заказы были переведены в работу 2 дня назад и завершены вчера.
Сейчас простые параметры в заказе реализованы не как поля в таблице "Заказы", а как записи в отдельной таблице "Параметры заказов" с полями "ID заказа"/"Имя параметра"/"Значение параметра"/"Состояние параметра". При обновлении параметра, старому в состояние прописывается, что он удален, и добавляется новая запись. Некоторых параметров может быть несколько активных сразу (например, несколько номеров клиентов).
Это правильное решение? Или нужно было все одиночные параметры скинуть в отдельные поля таблицы "Заказы", а для множественные параметры раскидать по отдельным таблицам? И как тогда следить за историей обновления Заказа? И как делать фильтр по старым (измененным) параметрам?
PS: Я не прошу отвечать на те 2 вопроса, которые я написал выше, я их привел для того, чтобы вы поняли тот "уровень развития" на котором я застрял. Но если вы на них ответите, то я буду весьма признателен.
Крайне советую почитать "Базы данных: Учебник для высших учебных заведении" Авторы: Хомоненко А.Д., Цыганков В.М., Мальцев М.Г.
Читаем раздел про проектирование БД.
Ответы на вопросы:
1. Это нормально. Не нужно объединять в одну табличку разные справочники =)
2. Для истории заказа заведите номер версии заказа. Работайте всегда с последней (актуальной) версией заказа.
А как хранить старые версии заказа? В той же таблице? Как отмечать старые версии? При каждом изменении придется создавать новую версию? А если изменился не сам "заказ", а данные в join-таблице (которые связаны с заказом, например список запчастей, использованных в заказе)
Простой
Средний
