#database #database-design #relational-database
#База данных #база данных-дизайн #реляционная база данных
Вопрос:
Если какой-либо объект может быть video, audio, или story , лучше ли иметь отдельную таблицу для каждой категории или нормально иметь "type" поле, содержащее множество "audio" , "video" и "story" записей?
1) ПРЕДПОЛОЖИМ, что каждый объект может быть только одного типа
2) ПРЕДПОЛОЖИМ, что каждый объект может быть нескольких типов (в этом случае лучше всего определить таблицу ObjectType, в которой хранятся отношения между объектами и типами, верно?)
(Я использую реляционную базу данных)
Спасибо!
Комментарии:
1. попробуйте создать образец для каждой и протестировать, по пути вы столкнетесь с трудностями, и вы получите помощь здесь
2. Может ли элемент находиться более чем в одной категории? Видео также может быть историей, не так ли?
3. @Будет хорошим аргументом… я отредактирую вопрос, чтобы отразить эту проблему.
Ответ №1:
Предлагаемые схемы ниже. Используя идентификаторы, а не строки, вы уменьшаете объем хранилища и усилия, требуемые ядром базы данных при объединении. Вы также значительно упрощаете переименование категории — вместо того, чтобы обновлять множество строк, где используется категория, вы обновляете одну строку КАТЕГОРИИ.
Только с одной категорией на элемент:
ITEM:
ID
CATEGORYID
...
CATEGORY:
ID
NAME
...
С несколькими категориями для каждого элемента:
ITEM:
ID
...
CATEGORY:
ID
NAME
...
ITEMCATEGORY:
ITEMID
CATEGORYID
Комментарии:
1. Спасибо, это подтверждает то, что я думал о второй категории. Спасибо, что указали на сложность изменения названия категории без использования идентификаторов
2. С удовольствием, AC — в долгосрочной перспективе это принесет дивиденды, если вы также установите внешние ключи на место.
3. Важно не «усилие» (если только это не может быть доказано , что это проблема), а скорее обеспечение согласованности и удобства использования базовой реляционной модели — а это невозможно без FK (использование суррогатных PK в стороне).
4. @pst — согласовано, хранение усилия отходят на второй план по сравнению с основной проблемой простоты обслуживания.