Вопрос сохранения данных.

[nata267]

Хранение деревьев в реляционных базах данных нетривиальная немного не тривиальная задача.
Одно из возможных решений использовать ORM(Object-relational mapping).

это не дерево. а связь многие ко многим, но в проекте присутствуют и деревья, задача состоит в том чтобы сохранить проект целиком, со всеми изменениями вносимыми в структуру. изменения могут быть значительными и нет, поэтому целиком базу данных переписывать затратно. Надо как то следить за удалением-добавлением объектов и связями между ними.  То есть во первых получается что нужно загрузить все объекты проекта и связи между ними в оперативную память. И во вторых при каждом действии пользователя. Следить какие объекты и связи поменялись. Как их хранить и как за ними следить. Вот в чем вопрос?

[nata267]

Возможно, действительно нужно удалить все прежние данные и выгрузить данные в бд или xml из оперативной памяти.

[alexis031182]

Не очень понятно, зачем хранить в постоянной памяти (в той же БД) данные для undo. По идее, эта информация нужна лишь на время одной сессии работы приложения.

[nata267]

Не очень понятно, зачем хранить в постоянной памяти (в той же БД) данные для undo. По идее, эта информация нужна лишь на время одной сессии работы приложения.

храним полюбому в оперативной, вопрос в том как сохранять. ставить состояния (inserted, deleted, modified) объектов или стирать все данные по проекту и записывать все заново (т.е. во всех табличках по проекту project_id). я уже склоняюсь к последнему, так как со статусами замороченно. следить за ними по каждому действию пользователя

[alexis031182]

храним полюбому в оперативной, вопрос в том как сохранять. ставить состояния (inserted, deleted, modified) объектов или стирать все данные по проекту и записывать все заново (т.е. во всех табличках по проекту project_id). я уже склоняюсь к последнему, так как со статусами замороченно. следить за ними по каждому действию пользователя

А почему заморочено? У Вас элементы модели (объекты) имеют параметр, обозначающий статус. Для рисования во вьюхе этот параметр должен быть определяющим, должна ли модель отдавать ей для показа каждый конкретный элемент или не должна. И для общего сохранения в БД тоже самое, только значение этого параметра будет определять, следует ли удалить, модифицировать запись или оставить как есть.

[nata267]

храним полюбому в оперативной, вопрос в том как сохранять. ставить состояния (inserted, deleted, modified) объектов или стирать все данные по проекту и записывать все заново (т.е. во всех табличках по проекту project_id). я уже склоняюсь к последнему, так как со статусами замороченно. следить за ними по каждому действию пользователя

А почему заморочено? У Вас элементы модели (объекты) имеют параметр, обозначающий статус. Для рисования во вьюхе этот параметр должен быть определяющим, должна ли модель отдавать ей для показа каждый конкретный элемент или не должна. И для общего сохранения в БД тоже самое, только значение этого параметра будет определять, следует ли удалить, модифицировать запись или оставить как есть.

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

[alexis031182]

А что за связи между объектами, помимо отношения "Родитель - Ребёнок"?

[nata267]

А что за связи между объектами, помимо отношения "Родитель - Ребёнок"?

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

[alexis031182]

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

А как непосредственно в модели Вы реализовали эти связи? Например, храните несколько копий объектов задания, принадлежащего разным темам, или один объект задания, содержащий некие ссылки на темы, в которых это задание должно содержаться? В модели ведь дерево.

[nata267]

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

А как непосредственно в модели Вы реализовали эти связи? Например, храните несколько копий объектов задания, принадлежащего разным темам, или один объект задания, содержащий некие ссылки на темы, в которых это задание должно содержаться? В модели ведь дерево.

У меня один объект задания. Если он относится к нескольким тестовым блокам, то создаю дочерние узлы и помещаю указатель на это задание в каждый узел. При сохранении я сохраняю сначала задания, потом тестовые блоки, а в конце связи между ними. Все эти объекты я планирую зарегистрировать в одном объекте типа projectDataBase() ; В том числе связи как отдельный тип объектов

[nata267]

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

[DmitryM]

xml так же является базой данных  

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

тогда проще взять ORM, к примеру ODB

[Igors]

Тема хорошая, "по делу", но увы, специфики слишком много. Пробовал вникнуть, но нереально, особенно для человека далекого от СУБД. Даже что такое тестовый блок - четко не представляю и.т.п. Плохо что нет поста где сосредоточены термины, описания - размазано на несколько. Лучше сформулировать задачу как бы "в пробирке", чтобы можно было сосредоточиться на принципиальных вещах без многочисленных технических деталей. Понятно что это гораздо легче советовать чем сделать, но так, мне пытаться обсуждать не понимая задачи - лучше промолчать

[nata267]

xml так же является базой данных  

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

тогда проще взять ORM, к примеру ODB

а по быстродействтию что эффективнее записать в xml или в бд mysql??

[nata267]

Тема хорошая, "по делу", но увы, специфики слишком много. Пробовал вникнуть, но нереально, особенно для человека далекого от СУБД. Даже что такое тестовый блок - четко не представляю и.т.п. Плохо что нет поста где сосредоточены термины, описания - размазано на несколько. Лучше сформулировать задачу как бы "в пробирке", чтобы можно было сосредоточиться на принципиальных вещах без многочисленных технических деталей. Понятно что это гораздо легче советовать чем сделать, но так, мне пытаться обсуждать не понимая задачи - лучше промолчать

"тестовые блоки" и "задания" - это сущности бд из моей задачи.