Как проектировать БД для сложной админки (mysql)?

Я ищу литературу или статьи.
Имеется довольно сложная админка для учета в фирме. Куча разных форм, куча разных данных. База - MySql, вся логика на js (angular) и микро-прослойка между базой и фронтом на php.

База уже разрослась до 20+ таблиц и, как мне кажется, я что-то делаю не так. Хочется узнать, как проектировать подобные системы.

Сразу скажу, что сейчас все работает. Но расширять и поддерживать становится все трудней.

Чтобы оценить уровень моего "непонимания", приведу пример вопросов, которые у меня возникают:

1. Нормально ли, что для каждого простого списка (список офисов, список складов, список поставщиков и тп) нужна своя отдельная таблица? А то есть желание объединить все одну таблицу ”Списки“ (будет спец-поле, например, "type", определяющее, к какому списку относится запись), но мешает боязнь того что простой список может вдруг обзавестись дополнительным полем и стать "сложней" других.

2. Есть список заказов на обслуживание. У заказа тонна простых параметров + сложные параметры, типа списка запчастей, где каждая запись тоже состоит из нескольких полей. Причем, всегда нужно знать кто из менеджеров и когда изменил какой либо параметр в заказе (или добавил/удалил запчасть, например). Также у заказа есть статусы (готов, в работе, принят и т.п.) и нужно уметь фильтровать список заказов по их истории - например, нужно знать какие заказы были переведены в работу 2 дня назад и завершены вчера.

Сейчас простые параметры в заказе реализованы не как поля в таблице "Заказы", а как записи в отдельной таблице "Параметры заказов" с полями "ID заказа"/"Имя параметра"/"Значение параметра"/"Состояние параметра". При обновлении параметра, старому в состояние прописывается, что он удален, и добавляется новая запись. Некоторых параметров может быть несколько активных сразу (например, несколько номеров клиентов).
Это правильное решение? Или нужно было все одиночные параметры скинуть в отдельные поля таблицы "Заказы", а для множественные параметры раскидать по отдельным таблицам? И как тогда следить за историей обновления Заказа? И как делать фильтр по старым (измененным) параметрам?

PS: Я не прошу отвечать на те 2 вопроса, которые я написал выше, я их привел для того, чтобы вы поняли тот "уровень развития" на котором я застрял. Но если вы на них ответите, то я буду весьма признателен.
  • Вопрос задан
  • 3281 просмотр
Пригласить эксперта
Ответы на вопрос 2
Крайне советую почитать "Базы данных: Учебник для высших учебных заведении" Авторы: Хомоненко А.Д., Цыганков В.М., Мальцев М.Г.
Читаем раздел про проектирование БД.
Ответ написан
@iryndin
Ответы на вопросы:
1. Это нормально. Не нужно объединять в одну табличку разные справочники =)
2. Для истории заказа заведите номер версии заказа. Работайте всегда с последней (актуальной) версией заказа.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы