Выберите таблицу базы данных для объединения, используя значение поля

Question

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

Конечно, я хочу, чтобы изображение наследовало права ресурса, частью которого оно является. Например: если пользователю A не разрешено просматривать гостевую книгу, я не хочу, чтобы он мог просматривать изображение, размещенное в гостевой книге, перейдя в image / view / id / 12 (что было бы запросом изображения, использовавшим его в гостевой книге).

Теперь у меня есть то, что система запоминает используемые ресурсы (в данном случае гостевая книга), идентификатор изображения связан с идентификатором ресурса. Однако я не знаю, к какой записи в гостевой книге связано изображение (я, конечно, знаю это наоборот).

Есть ли в SQL способ соединить одно поле таблицы с полем в другой таблице, где таблица, к которой я подключаюсь, может варьироваться в зависимости от одного из значений поля первой таблицы?

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

Или это все глупый способ решения проблемы, и я должен не использовать одну таблицу для загруженных изображений, а оставить изображение прикрепленным к ресурсу (например, в виде столбца в таблице)? Похоже, что использование одной таблицы, по крайней мере, намного медленнее в использовании (но у меня был бы отличный обзор всех изображений в одном месте).

Надеюсь, вы, ребята, сможете мне помочь.

РЕДАКТИРОВАТЬ: дополнительное объяснение: дБ модель Я постараюсь объяснить, как все это работает как можно лучше.

Прежде всего: я использую Zend Framework, и поэтому я также использую Zend_Acl для работы с привилегиями.

Структура моей БД: - Пользователи подключены к ролям (напрямую или через группу, связанную с ролью) - Существует таблица ресурсов, содержащая все ресурсы, которые связаны с привилегиями. Например: гостевая книга - это ресурс, просмотр или редактирование - это привилегии. Рядом с контроллерами / действиями также могут быть другие ресурсы в этой таблице, такие как категория в повестке дня или местоположение файла. - роли связаны с привилегом

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

Короче что-то вроде: пользователи -> роли -> привилегии <- ресурсы </p>

Когда пользователь добавляет запись в гостевую книгу с изображением, используемые ресурсы (в этом случае гостевая книга сохраняется): guestbook_posts -> изображения -> ресурсы

Надеюсь, это немного объяснит мою модель БД, в противном случае я попытаюсь создать образ таблиц.

Answer 1

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

Однако я не знаю, к какому гостевая книга опубликовать изображение связано (Конечно, я знаю это иначе вокруг) .

Если вы знаете ассоциацию одним способом, сможете ли вы использовать ассоциацию в обоих направлениях? Я предполагаю, что у вас есть таблица, которая включает в себя "post_id, image_id" или что-то?

Может быть, таблица сначала индексируется только post_id, и в этом случае запрос этой таблицы по image_id может быть медленным, но тогда вы можете просто включить новый индекс сначала с image_id?

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

Answer 2

Создайте два предложения SELECT, каждое из которых имеет правильные объединения с правильными таблицами, а затем объедините выходные данные двух предложений SELECT, используя оператор UNION.

SELECT field1, field2 
FROM table1 
JOIN table2 on table1.PK = table2.FK
WHERE table1.selector = 1

UNION SELECT field1, field2 
FROM table1 
JOIN table3 on table1.PK = table3.FK
WHERE table1.selector = 2    

Answer 3

Звучит так, как будто вы хотите ограничение внешнего ключа .

Обновление: Совершенно неправильно понял вопрос, очевидно.

Здесь есть два подхода:

1. В нынешнем виде в схеме нет ничего, что запрещало бы связывать одно и то же изображение из нескольких ресурсов.Если это желательно, тогда ограничение внешнего ключа и индекс для обратной ссылки, вероятно, является лучшим решением, хотя оно не будет хорошо масштабироваться и требует дополнительных вычислений (поскольку права на изображение должны быть объединением правреферирование ресурсов).

2. Альтернативой является создание некоторой схемы наследования, в которой есть таблица со списком «ресурсов» (которая фактически содержит только идентификаторы), на которую ссылаются как на внешний ключиз таблиц фактических ресурсов и таблицы изображений;единственное ограничение, которое не может быть выражено простым SQL, состоит в том, что разные ресурсы могут не использовать один и тот же идентификатор.