У меня есть две таблицы:
Таблица продуктов
- ID (PK), Описание, CategoryID, SegmentID, TypeID, SubTypeID и т. Д. c.
Таблица атрибутов
- ID (PK), ProductID (FK), Ключ, Значение
И я хотел бы запросить эти две таблицы в объединении, которое возвращает 1 строку для каждого продукта со всеми записями пары ключ / значение в таблице атрибутов, возвращенными в одном столбце, возможно, разделенными символом канала (Key1: Value1 | Key2: Value2 | Key3: Value3 | etc.). У каждого продукта может быть разное количество пар ключ / значение, причем у некоторых продуктов их всего 2-3, а у некоторых - 30. Я хотел бы выяснить, как сделать так, чтобы результаты запроса выглядели примерно так (возможно, выбран в новую таблицу):
product.ID, product.Description, [столбец специальных атрибутов], product.CategoryID, product.SegmentID, et c.
пример результата:
65839, "WonderWidget", "HeightInInches: 26 | WeightInLbs: 5 | Color: Black", "Widgets", "Commerical"
И наоборот, было бы полезно выяснить, как получить результаты запроса, отформатированные, как указано выше, и вернуть их * * * * обратно в исходную таблицу атрибутов. Например, если мы выведем приведенный выше запрос в таблицу, в которой [столбец специальных атрибутов] был изменен (значения обновлены / исправлены человеком), было бы неплохо узнать, как использовать таблицу, содержащую [столбец специальных атрибутов] для обновить исходную таблицу атрибутов. Я думаю, чтобы это было возможно, поле Attribute.ID должно быть включено в вывод запроса.
В конце я пытаюсь сделать так, чтобы sh был способ экспортировать Product и Attribute. данные выходят в 1 строку для каждого продукта со всеми данными атрибутов, так что человек может просмотреть / обновить / исправить их в таком простом виде, как файл Excel, а затем отправить обратно в SQL. Я думаю, что смогу понять, как все это сделать, когда преодолею препятствия на пути выяснения того, как вывести продукты и атрибуты в виде одной строки для каждого продукта. Возможно, правильный ответ состоит в том, чтобы объединить все атрибуты в столбцы, но я боюсь, что запрос будет невероятно широким и расточительным. Также открыты для предложений. Переключение на базу данных типа документа сейчас не вариант; нужно выяснить лучший способ справиться с этим в реляционной SQL.