Нужно выбрать правильный путь для сохранения N-Дерева в СУБД. Дерево состоит из разных объектов и представляет собой иерархию структур и членов этих структур. В последствии это всё отоброжается таблицами и их полями в ДБ. А само дерево это методанные, которые помогают создавать запросы и описывают всю глобальную структуру таблиц.

Кроме того должна существовать возможность менять дерево (а именно структур таблиц) и дерево всего 100% должно соответсвовать тому, что есть БД.


Вопрос в том как лучше представить дерево и выбрать петерн для его сохранения.

Тут вопрос не в базах данных, а именно в предсталении этой структуры например на С++ или C# не важно, главное это какой выбрать патерн для этого.

Пытаюсь оптимизировать существующие глюки)

mayton,

У структуры есть вершина (root) и у неё есть дочернии структуры их может быть N и дочерние члены разных примитивных типов (строки числа и тд). Понятное дело что у этих структур тоже может быть свои подструктуры.

Уточните пожалуйста как это реализованно в приложении.

mayton,

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

Компоновщик это очень близко, проблема в том что хочется все операции по работе с бд , передать другому объекту, для того чтобы не внедрять sql код в классы которые по сути отвечают за описание мета данных, и при этом иметь возможность менять структуру этого дерева с возможностью отката, при возниконовении ошибок при изменении структуры таблиц.

Что то похожее описывает Ларман с 329

Saving objects in a relational database is a very general task for which
many classes need support. Placing these responsibilities in the Sale class
suggests there is going to be poor reuse or lots of duplication in other classes
that do the same thing.
Thus, even though Sale is a logical candidate by virtue of Information Expert to
save itself in a database, it leads to a design with low cohesion, high coupling,
and low reuse potential—exactly the kind of desperate situation that calls for
making something up.
A reasonable solution is to create a new class that is solely responsible for saving
objects in some kind of persistent storage medium, such as a relational database;
call it the PersistentStorage.2' This class is a Pure Fabrication—a figment of the
imagination.


По сути ближе это именно к PersistentStorage. Но на мой взгляд это подходит для объектов одинаковой структуры (для самих данных), но не для структуры которая может менятся если пользователь хочет поменять её во время работы приложения.

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

Как в этом случаее можно определить обновлённые элементы?

Как в таком случае компоновщик может сохранять объект, если он не знает что именно он должен сохранить в дереве?