Добрыий день,
Имеетсжя следующая структура данных
class Object
{
public:
int id ;
TypeA a ;
TypeB b ;
...
Также имеется репозиториий ( База данных ) , которая хранит обьекты типа Object , назовем ее Object_DB
На данныий момент Репозиторий предоставлает простой метод set/get для извлечения обьекта типа Object по идентификатору ( ключ ).
Задача .
Обьект типа Object приходит по сети , но не как цельная структура , а как отдельные элементы .
Например в одном сообсщении (id, TypeA ) , в другом (id, TypeB )
Именно эти поля необходимо обновить для соответствующего обьекта в БД.
Поскольку обьект не приходит в полном обьеме , то приходиться вынимать из БД существующиий обьект , изменять необходимые поля и запихивать его обратно в БД.
Другое решение , мне кажеться менее правильное и приемлемое , предоставить в Object_DB соответствуюсщие методы для каждого типа
set ( id , const TypeA& ) ;
set ( id , const TypeB& ) ;
Вопрос :
Как посоветуете организовать структуры БД Object_DB , а такзже типы ( с указанием методов ) Object , TypeA , TypeB и т.д.
чтобы можно было эффективно обновлять отдельную часть обьекта Object в БД , используя один интерфеийс в Object_DB
set ( id , const Object& ) ;
Другими словами , чтобы обьекты Object умно копировали только то что необходимо.
Надеюсь вопрос понятен
Спасибо
Здравствуйте, Alex34, Вы писали:
A>Добрыий день,
A>Имеетсжя следующая структура данных
A>A>class Object
A>{
A>public:
A> int id ;
A> TypeA a ;
A> TypeB b ;
A> ...
A>
A>Также имеется репозиториий ( База данных ) , которая хранит обьекты типа Object , назовем ее Object_DB
A>На данныий момент Репозиторий предоставлает простой метод set/get для извлечения обьекта типа Object по идентификатору ( ключ ).
A>Задача .
A>Обьект типа Object приходит по сети , но не как цельная структура , а как отдельные элементы .
A>Например в одном сообсщении (id, TypeA ) , в другом (id, TypeB )
A>Именно эти поля необходимо обновить для соответствующего обьекта в БД.
A>Поскольку обьект не приходит в полном обьеме , то приходиться вынимать из БД существующиий обьект , изменять необходимые поля и запихивать его обратно в БД.
Извлекая объект, вы заодно проверяете, есть ли он в бд. Вдруг если его нет, нужно что-то важное сделать. Не забваем про многопользовательский доступ.
A>Другое решение , мне кажеться менее правильное и приемлемое , предоставить в Object_DB соответствуюсщие методы для каждого типа
A>
A> set ( id , const TypeA& ) ;
A> set ( id , const TypeB& ) ;
A>
A>Вопрос :
A>Как посоветуете организовать структуры БД Object_DB , а такзже типы ( с указанием методов ) Object , TypeA , TypeB и т.д.
A>чтобы можно было эффективно обновлять отдельную часть обьекта Object в БД , используя один интерфеийс в Object_DB
A>
A> set ( id , const Object& ) ;
A>
Вполне допустимо, просто небольшое нарушение принципов grasp. Есть другой вариант: "ленивая загрузка", так мы проверим что объект есть и лишние поля не будем загружать, правда в этом случае он не очень будет эффективен из-за малого количества данных в объекте.
A>Другими словами , чтобы обьекты Object умно копировали только то что необходимо.
A>Надеюсь вопрос понятен
A>Спасибо
Пожалуйста.
Здравствуйте, Alex34, Вы писали:
A>Добрыий день,
A>Имеетсжя следующая структура данных
A>A>class Object
{
public:
int id ;
TypeA a ;
TypeB b ;
...
A>...
A>Другими словами , чтобы обьекты Object умно копировали только то что необходимо.
Передо мной стояла подобная задача недавно. Дополнительно было необходимо изменять/читать записи сразу нескольких таблиц одним запросом. Реализовал следующим способом:
Есть структура верхнего уровня Trace, содержит массив (std::vector) структур Record. Каждая Record это поле table_name (enum) и массив структур Field. Каждая Field это поля field_id(int), type(enum), и бинарные данные (std::vecor<char>). Для работы с этим деревом есть набор функций: пополнение дерева как записей, так и полей (operator <<), операторы преобразования типа (актуально для удобного обращения к бинарным данным структуры Field, как к встроенным или предопределённым в программе типам), а так же обвеска для сериализации и десериализации деревьев для передачи по сети (в моём случае реализовал, как оператор "std::vector<char>& << const Trace&" и "Trace& << const char*").
Ну и, соответственно, в движок БД уходят только заданные в запросе записи и поля, а так же в качестве результата возвращаются только запрошенные или имеющиеся в наличии поля и записи. Реализовать функциональность преобразования Record в class Object и обратно, думаю, труда не составит. id полей и имена таблиц, в принципе, никто не мешает и в виде строки хранить и передавать, если схема БД непостоянна.
