Предложение по целостности базы данных с внешними ключами

Я пытаюсь создать дизайн базы данных, соответствующий моим потребностям.

Я был бы очень признателен за любую вашу рекомендацию по поводу моего следующего дизайна таблицы:

введите описание изображения здесь

У меня есть два компонента: Категории и Контент.

Каждый раз, когда я создаю новый элемент для любого из этих двух компонентов, должен быть также создан новый элемент маршрута с отношениями, как показано на визуальной диаграмме.

Красные и синие блики идентичны по цвету.

Является ли хорошей практикой иметь в этих таблицах следующие столбцы, такие как ci_routes.refid, ci_categories.slug и ci_content.slug?

==== ОБНОВЛЕНО ====

Бизнес-логика моего приложения работает так:

  • Я создаю элемент категории с формой html
  • При отправке формы приложение создаст новый маршрут для возврата вновь созданного ci_routes.id
  • Категория будет создана и заполнена всей информацией, включая ci_categories.rid.
  • Затем он снова обновляет ci_routes со всей информацией, где ci_routes.slug идентичен ci_categories.slug, а ci_routes.route будет основываться на настроенных параметрах, например, $path/$category_id, где $path = 'category'

Каждый раз, когда я решаю изменить $path на что-то вроде $path = 'node', все мои маршруты должны быть очищены и воссозданы на основе новых настроек.

Пожалуйста, поправьте меня, если я где-то в своей логике допустил логическую ошибку


person aspirinemaga    schedule 29.05.2014    source источник


Ответы (1)


Рекомендуется ли иметь в этих таблицах следующие столбцы ci_routes.refid

Нет. В текущем дизайне ci_routes.refid будет столбцом, ссылающимся на две таблицы, у вас не может быть внешнего ключа более чем для таблицы в столбце в РСУБД, поэтому вам придется обрабатывать его в логике вашего приложения, это будет глючная, тяжелая работа. Также вы потеряете целостность данных на уровне базы данных, что не приветствуется.

Решение 1:
Имейте два отдельных столбца в ci_routes для ссылки ci_categories и ci_content, как ci_routes.content_id и ci_routes.categories_id

Решение 2:
Используйте наследование, имея базовую таблицу для компонентов и категорий, содержащую общие свойства этих двух сущностей, имея базовую таблицу, вы можете ссылаться на нее внутри ci_routes как на внешний ключ .

введите описание изображения здесь

Является ли хорошей практикой иметь в этих таблицах следующие столбцы, такие как ci_categories.slug и ci_content.slug?

Чтобы ответить на вопрос, нужна дополнительная информация о вашей бизнес-логике.
Кстати, похоже, вы собираетесь денормализовать свою модель с помощью избыточного столбца slug. Если вы собираетесь сделать это только по соображениям производительности, подумайте о том, когда обновляется столбец заголовка компонентов, вам нужно будет обновить зависимые строки маршрута. Я не буду этого делать, пока не получу конкретных доказательств.

person Mohsen Heydari    schedule 29.05.2014
comment
Спасибо за ответ, Мохсен. Причина, по которой у меня есть ярлык в обеих таблицах компонентов, заключается в том, что, если я когда-нибудь решу усечь таблицу маршрутов для генерации новых значений на основе новых настроек, я думаю, это будет намного проще. Но может я что-то упускаю. Я обновлю свой вопрос через мгновение, чтобы вы могли лучше понять мою бизнес-логику. - person aspirinemaga; 29.05.2014
comment
Что произойдет, если вы сохраните slug только внутри Категории и Компонента и удалите его из маршрутов? - person Mohsen Heydari; 29.05.2014
comment
Мне было интересно примерно то же самое, либо оставить его внутри routes и удалить из таблицы компонентов, либо, как вы сказали, удалить его только из маршрутов. - person aspirinemaga; 29.05.2014