@ssrdop

Как правильно спроектировать данную БД?

Например у меня есть сущность "Писатели (фио, дата рождения, дата смерти)". Писатели делятся на отечественных и иностранных. Соответственно набор атрибутов для отечественных и иностранных будет разным. Таким образом я создаю еще 2 таблицы "Отечественные (id писателя, и т.д уникальные для данного типа атрибуты)" и также "Иностранные" (id писателя, и т.д уникальные для данного типа атрибуты, например язык). Если появится третья категория писателей, то создам еще таблицу, в которой опишу уникальные для данного типа атрибуты.

Если нужно показать список категорий писателей - тогда я создам еще таблицу "Категории писателей" (id, название категории), а в таблицах "иностранные", "отечественные" и так далее, добавлю поле "writer_category_id" - которая будет ссылаться на название категории . Теперь есть список категорий, который я уже смогу показать.

Главный вопрос - Когда пользователь начнет фильтровать писателей по категориям - то в коде я должен писать через switch , что если, например id категории равен 2, то я использую таблицу иностранные, елси другой код, то другая таблица. Верно ли это - не слишком ли много будет кода? Можно ли по другому это обрабатывать? Ведь категорий может быть, например, 15 и тогда придется 15 веток для switch писать? (Даже если фабрика, то все равно придется использовать switch)

Самый радикальный, и, на мой взгляд неправильный, добавить атрибут table_name в таблицу "Категории писателей".
  • Вопрос задан
  • 343 просмотра
Решения вопроса 2
Rsa97
@Rsa97
Для правильного вопроса надо знать половину ответа
Вообще, для такой задачи есть устоявшаяся схема:

categories (id, name) - категории (отечественный, зарубежный и т.д.)
items (id, category_id, базовый набор атрибутов) - в вашем случае авторы
attributes (id, name, type, ...) - возможные атрибуты
categories_attributes (category_id, attribute_id) - атрибуты, допустимые для категории
items_attributes (item_id, attribute_id, value) - собственно значения атрибутов

Такая схема легко расширяется, может содержать дополнительную информацию - признак обязательности атрибута в описании, список допустимых значений атрибута для типов "один из списка", "несколько из списка", единицы измерения и т.д.
Ответ написан
@Fortop
Tech/Team lead
Самый радикальный пересмотреть список атрибутов писателей.
Вы уверены что эти "уникальные" атрибуты в таком количестве и такой важности, что требуют все отдельных таблиц?

Если отличия в категориях в 2-3 атрибута, то можно расширить число полей в таблице Писатели.

Если сильно больше, то завести одну таблицу "Атрибуты писателей" куда и сохранять "ид писателя", "имя атрибута", "значение атрибута"
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 2
Lumore
@Lumore
Front-end developer
Свяжите это все внешними ключами, и вместо switch используйте:
$category_id = htmlspecialchars($_GET['category_id']);
$sql = $pdo->query('SELECT * FROM table_name WHERE `writer_category_id` = :category_id', ['category_id' => $category_id]);
$results = $sql->fetch();

Могу ошибаться, т.к. давно на нативном php с бд не работал :)
Ответ написан
ThunderCat
@ThunderCat Куратор тега MySQL
{PHP, MySql, HTML, JS, CSS} developer
Это где вы так лихо научились? Про нормальные формы никогда не слышали, я так понимаю?
Если появится третья категория писателей, то создам еще таблицу, в которой опишу уникальные для данного типа атрибуты.

Ну конечно, и еще если понадобится добавим! Больше таблиц для бога таблиц! )
Ответ написан
Ваш ответ на вопрос

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

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