Имеется двухмерная sql таблица с данными, в которую затолкали многомерные данные. То есть в одну строку-запись затолкали подчиненные объекты с несколькими уровнями вложенности дерева: заказ (у него свои базовые поля), к заказу подчиняется товар: товар1 (у него в свою очередь поля товар1_наименование, товар1_модель) , потом товар2 и так далее заложено десять товаров по десять полей в каждом. Потом к товару подчиняются отзывы: товар1-отзыв_поле1, товар-отзыв_поле2. Короче говоря зарезервировали пустые группы полей в одной строке и сколько будет реально создано в каждом конкретном случае заранее неизвестно, но не более чем установленное ограничение
заказ
-товар
--отзыв
№заказаадрес заказаполе заказа ещетовар1_наименованиетовар1_модельтовар2_наименованиетовар2_модельтовар1-отзыв_поле1 итд
Так вот вопрос реально ли это разобрать и распихать по отдельным таблицам, проставив связи. Взять поля заказа и запихать в таблицу заказов.
Следующим запросом выбрать поля товар1 и засунуть в таблицу товара, проставив так же id заказа для связи.. А вот далее непонятно, можно ли получить id только что созданной записи товара и взяв потом поля отзыва сохранить их в таблицу отзывов вместе с id товара для связи? Типа если товар1-отзыв не пустое забираем в таблицу отзывов вместе с id товара, далее если товар1-отзыв2 не пустое и так далее.
И вообще здесь есть какие то нарушения в последовательности. Можно ли вообще такое осуществить?
И еще в каждом запросе нужно проверять сначала, что группа полей не пустая, чтобы не создавать пустые строки. Насколько это вообще возможно и насколько это будет перегруженное мероприятие? И если придется делать это на регулярной основе, то есть в ту таблицу будут добавляться данные, а из нее нужно будет вытаскивать и сортировать. И в случае если добавится не строка, а значение в одно из бывших пустым до этого полей – насколько реально будет сличить было ли это поле ранее заполнено установив отношения полей и можно ли будет сделать апдейт в соответствующую строку?

Из доступного разве что Visual Basic через ODBC , но получается невысокая производительность.