При вставке сложного объекта в базу данных SQL, когда объект должен быть разбит на его уважительные таблицы?

Question

Редактировать: Вкратце, какую стратегию следует использовать для сценариев insert и select со сложными объектами (например, два вызова select, по одному для каждой таблицы; один вызов select с объединениями)?

У нас есть вставка базы данных (postgresql), которая включает в себя список объектов, который сериализуется (в текстовом формате xml), и помещает его в ячейку подряд среди обычных строк и тому подобное. Мы хотели бы создать новую таблицу с этими списками со ссылками на ключ исходного элемента. Где должен быть отколот объект? Я не думаю, что это возможно в запросе SQL, но если это так, это было бы идеально. Наше любимое место в настоящее время - как раз перед тем, как мы настроили наши JDBCProcedures.

string name
int id
List<sub-objects>

и в настоящее время это хранится в схеме БД, например:

name varchar(20)
id int
subObjs text [or other character type big enough to hold the serialized XML]

Answer 1

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

Answer 2

Пожалуйста, предоставьте немного больше информации о структуре ваших объектов и уточните свой вопрос. Не совсем понятно, о чем вы здесь спрашиваете.

Тем не менее, позвольте мне попробовать нанести удар: Если у вас есть объекты в коде Java со структурой, примерно такой:

string name
int id
object[] list_of_sub-objects

и в настоящее время он хранится в схеме БД, например:

name varchar(20)
id int
subObjs text [or other character type big enough to hold the serialized XML]

Это правильно?

И тогда ваш вопрос:

Мы хотели бы создать новую таблицу с этими списками со ссылками на ключ исходного элемента. Где должен быть отделен объект? Я не думаю, что это возможно в запросе SQL, но если это так, то это было бы идеально.

Когда вы говорите, что элемент списка «сериализуется» в вашей существующей системе, вы имеете в виду XML? Похоже, что синтаксический анализ XML в самом SQL все еще находится в разработке для postgreSQL, и в любом случае, если вы еще не знаете, как это сделать, может возникнуть много проблем при кодировании чего-то подобного.

Но у вас уже есть код приложения, который представляет ваши объекты несериализованным способом. Вы можете написать функцию в кодовой базе вашего приложения, которая выполняет миграцию. Загрузите записи из старой таблицы базы данных в объекты приложения в соответствии с существующей схемой, а затем запишите их обратно в новую пару таблиц БД в соответствии с новой схемой.

Это концептуально упрощает проблему до того, что вы можете представить в псевдокоде, т. Е. «Как мне сопоставить структуру моего объекта из старой схемы базы данных с новой?»

Надеюсь, это поможет! Если вы сможете немного прояснить свою структуру, я мог бы предоставить более конкретный псевдокод для решения, которое я предлагаю здесь.