Подскажите пожалуйста как можно и как лучше хранить произвольные объекты ( у каждого из них есть свой ID ).
Пока придумал токо:
Сереализовывать каждый объект в xml и сохранять в файл с именем obj.Id.ToString()
Создать таблицу в MSSQL ( uniqueidentifier [id], text [xml] ) и тоже сереализовывать его в xml
Как лучше?
Re: Хранение произвольных объектов
От:
Аноним
Дата:
02.03.05 07:22
Оценка:
C>Подскажите пожалуйста как можно и как лучше хранить произвольные объекты ( у каждого из них есть свой ID ). C>Пока придумал токо: C>
C>Сереализовывать каждый объект в xml и сохранять в файл с именем obj.Id.ToString() C>Создать таблицу в MSSQL ( uniqueidentifier [id], text [xml] ) и тоже сереализовывать его в xml C>C>Как лучше?
лучше зависит от ситуации. Думаю, с базой лучше при больших объемах — легче поиск и т.д.
Здравствуйте, Аноним, Вы писали:
А>лучше зависит от ситуации. Думаю, с базой лучше при больших объемах — легче поиск и т.д.
А не лучше будет динамически создавать таблицы с нужной структурой ( типов объектов не так много ) для определнного типа ( поле / столбец )?
Здравствуйте, Chardex, Вы писали:
C>Подскажите пожалуйста как можно и как лучше хранить произвольные объекты ( у каждого из них есть свой ID ). C>Пока придумал токо: C>
C>Сереализовывать каждый объект в xml и сохранять в файл с именем obj.Id.ToString() C>Создать таблицу в MSSQL ( uniqueidentifier [id], text [xml] ) и тоже сереализовывать его в xml C>C>Как лучше?
Лучше в базу, только использовать не XML, а BinaryFormatter.
Здравствуйте, Stewe, Вы писали:
S>Лучше в базу, только использовать не XML, а BinaryFormatter.
Почему? А это будет намного эффективнее? Просто хотелось иметь возможность редактировать объект вручную
Hello, Chardex!
А>> лучше зависит от ситуации. Думаю, с базой лучше при больших объемах - А>> легче поиск и т.д. C> А не лучше будет динамически создавать таблицы с нужной структурой ( C> типов объектов не так много ) для определнного типа ( поле / столбец )?
Про ORM столько всего написано... Тут одного подхода на все случаи жизни быть не может. Ты слишком мало рассказал.
Что за объекты. Какие операции хранилище должно уметь делать. Ну и тд и тп...
Здравствуйте, GarryIV, Вы писали:
GIV>Про ORM столько всего написано... Тут одного подхода на все случаи жизни быть не может. Ты слишком мало рассказал.
Что такое ORM? Где написано Мне и не на все случаи жизни, а токо на мом
GIV>Что за объекты. Какие операции хранилище должно уметь делать. Ну и тд и тп...
Объекты разные, описывают разные примитивные сущности ( например, дом: сколько этажей, дата постройки, цвет, кол-во цветов ) но могут быть дочерние ( например, этаж: сколько корридоров, двурей и т.п. ).
Мне кажется что все простые типы можно ( и которые быстро преобразовываются из строки и обратно, например Color ) нужно создавать столбец определнного типа, а для сложный, например коллекций ( этажей ), устанавливать связь ( токо как ?), и писать эти объекты уже в новую таблицу ( где лежат этажи )
Здравствуйте, Chardex, Вы писали:
C>Здравствуйте, Stewe, Вы писали:
S>>Лучше в базу, только использовать не XML, а BinaryFormatter. C>Почему? А это будет намного эффективнее? Просто хотелось иметь возможность редактировать объект вручную
Размер сохраняемых данных будет намного меньше.
Hello, Chardex!
GIV>> Про ORM столько всего написано... Тут одного подхода на все случаи GIV>> жизни быть не может. Ты слишком мало рассказал.
C> Что такое ORM? Где написано
Несомненно.
GIV>> Что за объекты. Какие операции хранилище должно уметь делать. Ну и тд GIV>> и тп... C> Объекты разные, описывают разные примитивные сущности ( например, дом: C> сколько этажей, дата постройки, цвет, кол-во цветов ) но могут быть C> дочерние ( например, этаж: сколько корридоров, двурей и т.п. ).
C> Мне кажется что все простые типы можно ( и которые быстро C> преобразовываются из строки и обратно, например Color ) нужно создавать C> столбец определнного типа , а для сложный, например коллекций ( этажей ), устанавливать связь ( C> токо как ?), и писать эти объекты уже в новую таблицу ( где лежат этажи C> )
Первичный ключ в одной таблице, внешний в другой — вот и связь.
Ты определись какие функции хранилище должно поддерживать (кроме достать\положить естественно). Например надо ли уметь находить все дома у которых коридоры с десятью желтыми дверьми или просто достаточно найти дом с определенным ID и целиком загрузить его в объектную модель. В первом случае понядобиться создавать разувесистую структуру табличек во втором можно обойтись бинарной (или xml) сериализацией, причем тут даже и не очевидно, что РСУБД в качестве хранилища будет оптимальным выбором.
Здравствуйте, GarryIV, Вы писали:
GIV>Первичный ключ в одной таблице, внешний в другой — вот и связь.
GIV>Ты определись какие функции хранилище должно поддерживать (кроме достать\положить естественно). Например надо ли уметь находить все дома у которых коридоры с десятью желтыми дверьми или просто достаточно найти дом с определенным ID и целиком загрузить его в объектную модель. В первом случае понядобиться создавать разувесистую структуру табличек во втором можно обойтись бинарной (или xml) сериализацией, причем тут даже и не очевидно, что РСУБД в качестве хранилища будет оптимальным выбором.
Понятно. Спасибо. Вообще для начала только по ID, но боюсь впоследствии — нетоко. А нету готовых подобных библиотек?
А вообще было бы здорово сделать так: Берешь объект и для его типа автоматом генерится таблица(например через отражение). Если в нем есть сложный объект(такие объекты можно будет помечать атрибутом, или если он не базовый тип ), то он записывается в отдельную таблицу и так вглубь. Вообщем сохранять любые объекты, не знаю ничего о том как они сохраняются! Наверняка есть что нить готовое
Здравствуйте, Chardex, Вы писали:
C>Подскажите пожалуйста как можно и как лучше хранить произвольные объекты ( у каждого из них есть свой ID ). C>Пока придумал токо: C>
C>Сереализовывать каждый объект в xml и сохранять в файл с именем obj.Id.ToString() C>Создать таблицу в MSSQL ( uniqueidentifier [id], text [xml] ) и тоже сереализовывать его в xml C>C>Как лучше?
Я пользовался uniqueidentifier [id], text [xml]. Вполне приемлемый подход. Но если нужно выбрать запись по содержанию поля xml, то облом. Было бы что-нибудь такое:
SELECT * FROM myTable WHERE xml XPath "/root/node/@attr = 'дом'"
Вот было бы круто. Я даже в MS wish program отправил просьбу добавить оператор XPath и тип поля xml к акцесу
В общем, когда мне потребовалось в sql отличать один xml (у меня несколько разных xml хранятся в базе) от другого я добавил поле type, и потом мне потребовалось отличать xml документы одного из типов по номеру хранящемуся в "/doc/author/user_id", я добавил еще одно поле user_id в табличку.
Конечно подход откровенно говоря плохой, но тем не менее иногда спасает.
Здравствуйте, Chardex, Вы писали:
C>А вообще было бы здорово сделать так: Берешь объект и для его типа автоматом генерится таблица(например через отражение).