Как решить проблему с данной архитектурой Базы данных?

Доброго дня всем! Хотелось бы проконсультироваться на счет архитектуры базы данных(Mysql),а точнее над той частью, что отвечает у меня за категории, товары и т.д. Опыта в разработке, кроме того проекта, что я делаю для портфолио нету. Сервисы и ДАО слои уже написаны почти над всеми этими объектами.
Смысл в том, что я создаю "универсальный магазин", и я пытался создать такую архитектуру, при какой, мне бы было удобно и быстро получать любые данные, т.е я предполагал поиск сверху-вниз по ID, т.к по int значением поиск происходит быстрее. Но как бы я не пытался, но не смог обойти одну проблему: устройство БД таково, что, допустим у "Автомобилей" будет множество характеристик, среди них: Мощность, Количество цилиндров, Класс, и т.д . Но и у "Мотоциклов", будут такие же параметры, понятно, что не все. Следовательно, в таблице characteristic_name будет множество одинаковых полей для каждого субъекта, т.е сотню мощностей и т.д. Я бы хотел, чтобы они ссылались на одну мощность, а я уже реализую работы БД так, чтобы при редактировании записи, если есть на нее ссылки, просто создавалась новая. Это, к делу, правда, не относится. Производителя я тоже вынес в характеристики, хотя для него можно сделать отдельную таблицу.Надеюсь, на ваш опыт, помощь и здравую критику. Повторюсь, опыта у меня в этом нету.

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

P.s View - это для фронденда,чтобы он понимал, как ему представлять информацию.

P.p.s Subject-абсурдное название, сам знаю, но пока что лучше придумать не могу)

811cf7be54474de7b0dd0fd2c45566d2.jpgf4bf1f8b4a4047c08ce028a1bf6be1b2.png
  • Вопрос задан
  • 378 просмотров
Решения вопроса 1
@nirvimel
  1. Если characteristic_value привязано к subject_model, characteristic_name (почему бы не назваьть эту таблицу просто characteristics, ведь там может храниться еще что-то кроме имени) можно не привязывать к subject. Этим достигается независимость характеристик от субъекта и отсутствие дублей среди характеристик.
  2. Что-бы при назначении значения характеристики модели можно было производить проверку на то, возможна ли вообще такая характеристика для субъекта, нужно ввести кросс-таблицу subject_characteristics (характеристики субъектов), которая бы имела внешние ключи к subject и characteristic_name, то есть many-to-many зависимость между ними, через отдельную кросс-таблицу.
  3. У вас всего два фиксированных уровня иерархии. Что, если на практике потребуется больше? Вы, кажется, стремитесь создать гибкую/универсальную систему. Тогда вам нужна динамическая иерархия категорий.
  4. Если view служит для представления, то внешний ключ к нему в characrteristic_name не нужен, так как логически характеристика, как единица учета, не подчинена представлению данных. Опять же лучше ввести many-to-many зависимость между характеристиками и представлениями, реализованную через кросс-таблицу. Подсистема представлений при этом остается полностью независимой ото основной структуры данных (ее можно убрать не нарушая структуру).


P.S.: Интересно, в каком это смысле дрель (инструмент) может быть субъектом.
Ответ написан
Пригласить эксперта
Ответы на вопрос 1
zolt85
@zolt85
Программист
Есть такая модель, называется EAV модель. Если кратко, то в ней разделяется сущность - атрибут - значение, т.е. список сущностей и список атрибутов независимы. Это позволяет делать "переиспользуемые" атрибуты, если хотите. Это что касается плюсов данной модели. Из минусов могу отметить сложность запросов к бд для выборки конкретных данных, ну и скорость выполнения этих запросов немного ниже. А так вполне жизнеспособная модель. Magento, например, использует ее в своих e-commerce продуктах.
Ответ написан
Комментировать
Ваш ответ на вопрос

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

Похожие вопросы