SQL - Обновление таблицы, изменяющей значение одного столбца на основе другой таблицы
-
10-07-2019 - |
Вопрос
Извините, если название не такое описательное, каким оно должно быть, но довольно сложно объяснить в одном предложении, что я пытаюсь сделать ;).
У меня есть одна таблица, которая связывает родительские объекты со своими соответствующими дочерними.И у меня есть еще одна таблица со всеми объектами (родителями и дочерними) с соответствующими изображениями.Однако изображение задается только для родительских объектов.Я хотел бы обновить эту последнюю таблицу и установить дочернему изображению то же самое изображение, которое уже установлено для его родительского элемента.Кроме того, поскольку для каждого объекта существует более одного изображения, я хотел бы задать конкретное, которое я могу узнать на основе столбца атрибутов.
Мои таблицы выглядят примерно так:
Соотносимый
идентификатор ребенка
идентификатор родителя
Поддающийся изображению
идентификатор объекта
атрибут-идентификатор
изображение-url
И вот пример, чтобы прояснить ситуацию:
Стабильные отношения
идентификатор ребенка | родительский идентификатор
3 | 1
4 | 1
5 | 2
Поддающийся изображению
идентификатор объекта | идентификатор атрибута | URL-адрес изображения
1 | хорошее изображение | image1.jpg
1 | плохое изображение | image1b.jpg
2 | хорошее изображение | image2.jpg
2 | плохое изображение | image2b.jpg
3 | хорошее изображение | нет
3 | плохое изображение | нет
4 | хорошее изображение | нет
4 | плохое изображение | нет
5 | хорошее изображение | нет
5 | плохое изображение | нет
Итак, я хотел бы установить изображения объектов 3, 4 и 5 (дочерних) на соответствующие родительские изображения, но на "правильные", то есть изображения с 'goodimage' в качестве атрибута-id.
В конце это должно выглядеть так:
1 | хорошее изображение | image1.jpg
1 | плохое изображение | image1b.jpg
2 | хорошее изображение | image2.jpg
2 | плохое изображение | image2b.jpg
3 | хорошее изображение | image1.jpg
3 | плохое изображение | нет
4 | хорошее изображение | image1.jpg
4 | плохое изображение | нет
5 | хорошее изображение | image2.jpg
5 | плохое изображение | нет
На самом деле, меня не волнует, установлено ли также 'badimage', но важным является 'goodimage'.
Я пытался сделать что-то вроде:
UPDATE ImageTable
SET image = (SELECT image-url FROM ImageTable WHERE ImageTable.object-id = RelationTable.parent-id AND ImageTable.attribute-id = 'goodimage')
WHERE ImageTable.object-id = RelationTable.child-id AND ImageTable.attribute-id = 'goodimage'
но это не работает, так как это неправильный синтаксис SQL.Я не знаю, должен ли я использовать переменную (никогда ее не использовал) или это можно сделать всего одним предложением SQL.
Любая помощь была бы высоко оценена.
Решение
что-то вроде этого?
Примечания:
Это можно было бы объединить в один оператор без подзапроса, но я был ленив.
Я не тестировал, ожидайте опечаток
;WITH goodlist AS
(
SELECT child-id, image-url
FROM relationstable
left join imagetable on relationstable.child-id = relationstable.child-id and attribute-id = "goodimage"
)
UPATE imagetable
set imagetable.image-url =
(SELECT top 1 image-url from goodlist where child-id = imagetable.object-id)
WHERE imagetable.image-url = "no"
Другие советы
Прежде всего, если отношение между родительским и дочерним элементами равно 1: n, почему бы вам просто не добавить эту информацию в ту же таблицу?например ,имя поля "parentid" (если оно пустое / null, то это только родительский элемент).Выгода:вам не нужна дополнительная таблица, и при необходимости вы можете легко создать иерархию.
И для изображения, я предполагаю, вы хотите отобразить это где-нибудь в своем коде, но должно быть проще просто изменить SELECT, чтобы получить изображение -URL родительского изображения не указан для дочернего.Выгода:нет необходимости обновлять таблицу при получении новых записей, и также было бы возможно, чтобы некоторые дочерние записи имели свое собственное изображение (при необходимости).
Редактировать:только что заметил ваш новый комментарий о части проекта с открытым исходным кодом, конечно, это затрудняет изменение дизайна базы данных.Но, возможно, все же проще перенести некоторые проблемы на сторону программирования (если только это не решается также программным обеспечением с открытым исходным кодом).