Разработка 3 тесно связанных таблиц SQL
У меня есть 3 таблицы SQL: App, Marketplace и Category.
Эти сущности имеют следующие отношения:
- На торговой площадке есть много приложений. (один ко многим)
- У торговой площадки есть много категорий. (один ко многим)
- В приложении много категорий.
- Категория принадлежит многим приложениям. (многие ко многим)
Я придумал это:
Это почти работает, но проблема в том, что я могу создать приложение на торговой площадке, у которой есть категории, не принадлежащие этой торговой площадке. Я хотел бы добиться этого, если это возможно, и я не смог придумать решение.
@Barmar Спасибо за информацию.
Я думаю, у вас здесь есть проблемы. Вы должны уточнить, что «торговая площадка имеет много категорий» и «приложение имеет много категорий». Категория слов не одинакова в обоих предложениях (по крайней мере, в реальном мире). Например, приложение может быть «веб-приложением» и продается на рынке в рамках «бизнес-инструментов». Более точный способ сказать, что на торговой площадке есть группы приложений, и каждое приложение классифицируется по нескольким категориям / типам. Существуют дополнительные подробности, я мог бы уточнить, если вы хотите узнать больше.
Вам не нужна таблица marketplace_category?
@NoChance Для моего сценария эти категории совпадают, и именно они продаются на рынке. Категория приложения - это категория, в которой оно указано на торговой площадке.
Возможный дубликат Какие есть варианты хранения иерархических данных в реляционной базе данных?
Извините, разместил не ту ссылку. PS Это faq. Пожалуйста, всегда гуглите много ясных, кратких и конкретных версий / формулировок вашего вопроса / проблемы / цели с вашими конкретными строками / именами и без них и читайте много ответов. Добавьте в поисковые запросы релевантные ключевые слова, которые вы обнаружите. Если вы не нашли ответа, отправьте сообщение, используя поиск по одному варианту в качестве заголовка и ключевых слов для тегов. См. Текст при наведении курсора мыши на стрелку "против". Если у вас есть вопрос о не дублирующемся коде, который нужно опубликовать, прочтите и действуйте по минимальный воспроизводимый пример.
Без разделения категорий в соответствии с моим комментарием выше у вас может не получиться хороший дизайн. Вы можете решить указанную проблему, используя составной внешний ключ, такой как MarketPlaceID + AppCategoryID, в качестве одного внешнего ключа таблицы «многие ко многим» и MarketPlaceID + AppID для другого внешнего ключа. Однако это выглядит не очень хорошо из-за того, что я упоминал ранее.
К сожалению, MySQL очень ограничен в типах ограничений, которые он может применять автоматически. Единственные встроенные ограничения, которые он имеет, - это уникальные ключи и внешние ключи. Вы можете выполнить такую проверку в триггере, но часто проще сделать это в логике приложения, чем в базе данных.