2009-09-26 2 views
1

Если у меня есть три таблицы:SQL внешних ключей с несколькими таблицами

music_genres 
----------- 
music_type_id 
genres 
[other unique fields] 

minerals 
-------- 
mineral_id 
mineral 
[other unique fields] 

verbs 
----- 
verb_id 
verbs 
[other unique fields] 

и они заполняются:

rock 
jazz 
funk 
punk 

rock 
boulder 
stone 
shale 

rock 
wobble 
shake 
vibrate 

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

pages 
----- 
page_id 
page_url 
template_url 
foreign_key_id 

с данными, такими как:

/page/music-genres/rock/ 
/music-genres-template.html 
1 

/page/verbs/rock/ 
/verb-template.html 
1 

/page/minerals/rock/ 
/mineral-template.html 
1 

/page/minerals/rock/images/ 
/mineral-images-template.html 
1 

шаблонов будут знать, что внешний ключ относится к конкретной связанной таблице, поэтому минеральный шаблон с ноу запросить таблицу минералов для других полей этой таблицы. Однако у меня нет никакой ссылочной целостности. Если камень удаляется из таблицы минералов, я не могу использовать каскадные удаления для удаления строк со страниц, поскольку внешние ключи не уникальны. Я могу думать о многочисленных способов обойти это некрасиво:

  • Эмуляция каскадных удалит с триггеров
  • Сохранение типа элемента в каждой строке music_types, минералы и глаголы таблицы, и использовать это в ап дополнительный внешний ключ
  • Сохранение соответствующего имени таблицы на страницах стол
  • Поддержание целостности базы данных с помощью PHP и т.д.

Я думаю, что должен быть лучший способ хранить мои данные или поддерживать целостность базы данных. Есть предположения?

+0

У вас есть некоторые, которые не показывают, что генерирует первичный ключ, к которому относятся эти внешние ключи? Итак, тот же ключ для «скалы» используется во всех трех таблицах? –

+0

Точно. В этом случае колонка автоинкремента MySQL.Сценарий, очевидно, гипотетический, но иллюстрирует, что я не могу полагаться на другой столбец, который будет уникальным во всех трех таблицах, которые могут быть использованы для создания сложного ключа. – jetboy

ответ

3

Я думаю, что ваша проблема заключается здесь

шаблоны будут знать, что а внешний ключ относится к конкретной связанной таблицы,

Это знание, которое не хранится где-нибудь в база данных.

Я вижу два пути выхода из него:

  1. Учитывая, что вы на самом деле создаете отдельные таблицы для каждого типа «вещи», вы должны иметь столбец Differente для каждого типа вещей, ссылающегося на соответствующую таблицу в таблице страниц, устанавливая все столбцы в нуль, кроме одной (это может быть обеспечено с помощью ограничения)

  2. есть стол «Мастер вещей» с уникальным идентификатором, который затем страницы могут ссылаться, имеющей как столбец для идентификации тип и столбец, указывающий на остальные уникальные данные, которые будут храниться в другой таблице.

+0

Спасибо Vinko. Да, это проблема. 1. Потенциально много потерянного пространства. Звуки работают на 3 стола, но беспорядочно на 30 или даже 300! 2. Не могли бы вы дать мне представление о том, как это можно достичь? – jetboy

+0

create table things (id int, type int); create table rocks (id int ссылается на вещи (id) на delete cascade, имя varchar, ...); создавать таблицы страниц (id int ссылается на вещи (id) на delete cascade, ...); –

+0

Возможно, я ошибаюсь, потому что мне сложно это предусмотреть, но таким образом, если я удалю «вещь», она, в свою очередь, каскадом удалит связанные минералы и страницы? Это не то, что мне нужно. Я хочу удалить минерал и, в свою очередь, удалить связанные вещи и страницы. Я могу перемещать внешние ключи, чтобы это разрешить, но я не вижу, как я могу сделать эту работу с таблицами глаголов и типов музыки, добавленными в микс. – jetboy