Есть большой объект сериализованый в файле. Множество потоков:
— читают поля объекта,
— находят помеченые, как еще не наполненные,
— посылают данные поля во внешний сервис, и получают данные для наполнения текущего поля,
— наполняют поле в файле.
Например, большим объектом является объект, хранящий список книг и комментариев к ним.
Нужно, чтобы каждая книга содержала актуальный список своих комментарии, для этого:
— файл блокируется,
— просматривается список книг на наличие неактуальных(старых) комментариев,
— книга помечается, как находящаяся в наполнении,
— файл разблокируется,
— ID найденой книги с неактуальными комментариями передается на сервер в интернет и получается в ответе список актуальных комментариев,
— файл блокируется,
— для книги с ID записывается актуальный список комментариев,
— файл разблокируется.
Как сделать, чтобы в момент записи данных в файл для конкретной книги не происходила полная сериализация всего хранилища книг, а только часть относящаяся к данной книге? XML мне в этом поможет?
Или есть какие простые решения (может MS SQL 2005 Express?), которые упростят разработку и не усложнят развертывание? Я не работал с БД так плотно, чтобы понять: можно ли дердать несколько БД с одними и теми же таблицами(список книг) в разных файлах и на лету осуществлять работу с ними через СУБД? Подскажите, пожалуйста.
<skipped>
O> Как сделать, чтобы в момент записи данных в файл для конкретной книги не происходила полная сериализация всего хранилища книг, а только часть относящаяся к данной книге? XML мне в этом поможет? O> Или есть какие простые решения (может MS SQL 2005 Express?), которые упростят разработку и не усложнят развертывание? Я не работал с БД так плотно, чтобы понять: можно ли дердать несколько БД с одними и теми же таблицами(список книг) в разных файлах и на лету осуществлять работу с ними через СУБД? Подскажите, пожалуйста.
Если Вам удобнее работать с файлами то можно сделать следующее:
Декомпозировать структру этого большого объекта, чтобы была возможность его серилиовать по частям. Например, главный объект, содержащий список книг реализует IXmlSerializable и внутри WriteXML бежит по всем книгам и серилизует каждую книгу в свой файл. При десерилизации обратная операция.
Вместо одного файла сделать несколько файлов, чтобы избежать полной серилизации.
Можно попробовать поработать с MS Access (проект Janus, он же оффлайн клиент для RSDN использует базу данных MS Access и разворачивается он давольно легко). Тут же можно посмотреть в сторону Business Logic Toolkit.
P>Если Вам удобнее работать с файлами то можно сделать следующее: P>
P>Декомпозировать структру этого большого объекта, чтобы была возможность его серилиовать по частям. Например, главный объект, содержащий список книг реализует IXmlSerializable и внутри WriteXML бежит по всем книгам и серилизует каждую книгу в свой файл. При десерилизации обратная операция. P>Вместо одного файла сделать несколько файлов, чтобы избежать полной серилизации. P>
Не пойдет, т.к. книг может быть очень много, около 10000. Удобнее работать именно с одним файлом — одним хранилищем книг.
P>Можно попробовать поработать с MS Access (проект Janus, он же оффлайн клиент для RSDN использует базу данных MS Access и разворачивается он давольно легко).
Я смогу окткрыть несколько БД с одинаковой структурой, но разными записями, чтобы эти БД были ассоциированы каждая со своим файлом и иметь к ним независимый одновременный доступ?
P>Тут же можно посмотреть в сторону Business Logic Toolkit.
Пока ищу описание возможностей... Может вы сразу скажете, можно ли работать с помощью него с разными файлами, как с разными БД? Как вообще называется эта проблема, чтобы я знал куда копать?
Спасибо.
Здравствуйте, Ocenochka, Вы писали:
P>>Если Вам удобнее работать с файлами то можно сделать следующее: P>>
P>>Декомпозировать структру этого большого объекта, чтобы была возможность его серилиовать по частям. Например, главный объект, содержащий список книг реализует IXmlSerializable и внутри WriteXML бежит по всем книгам и серилизует каждую книгу в свой файл. При десерилизации обратная операция. P>>Вместо одного файла сделать несколько файлов, чтобы избежать полной серилизации. P>>
O>Не пойдет, т.к. книг может быть очень много, около 10000. Удобнее работать именно с одним файлом — одним хранилищем книг.
P>>Можно попробовать поработать с MS Access (проект Janus, он же оффлайн клиент для RSDN использует базу данных MS Access и разворачивается он давольно легко). O> Я смогу окткрыть несколько БД с одинаковой структурой, но разными записями, чтобы эти БД были ассоциированы каждая со своим файлом и иметь к ним независимый одновременный доступ?
Теоритически да, только не пойму зачем. Если Вам необходимо содержать несколько версий одной записи книги, можно сделать отдельную таблицу для этого. То есть, мы создаем постоянную таблицу для записей книг и одну таблицу для промежуточных записей. Таким образом при редактировании записи она копируется в промежуточную таблицу и там редактируется, а после редактирования производится обновление постоянной таблицы.
Опять же, если у Вас есть проблемы с одновременным доступом — используйте транзакции. Можно например монопольно захватить запись, отредактировать ее и потом обновить...
P>>Тут же можно посмотреть в сторону Business Logic Toolkit.ъ
Вот Форум, вот статья
O> Пока ищу описание возможностей... Может вы сразу скажете, можно ли работать с помощью него с разными файлами, как с разными БД? Как вообще называется эта проблема, чтобы я знал куда копать? O>Спасибо.
P>>>Можно попробовать поработать с MS Access (проект Janus, он же оффлайн клиент для RSDN использует базу данных MS Access и разворачивается он давольно легко). O>> Я смогу окткрыть несколько БД с одинаковой структурой, но разными записями, чтобы эти БД были ассоциированы каждая со своим файлом и иметь к ним независимый одновременный доступ? P>Теоритически да, только не пойму зачем. Если Вам необходимо содержать несколько версий одной записи книги, можно сделать отдельную таблицу для этого. То есть, мы создаем постоянную таблицу для записей книг и одну таблицу для промежуточных записей. Таким образом при редактировании записи она копируется в промежуточную таблицу и там редактируется, а после редактирования производится обновление постоянной таблицы.
Список книг и их описаний — это структура БД. Таблицы.
Мне нужно, чтобы был список детективов в одном файле, список коммедий — в другом. Они должны легко переносится из одной копии программы в другую. Зачем это? Есть дав пользователя — у одного список детективов, у другого — коммедий. Любитель детективов хочет дать свой список любителю коммедий. Я это вижу в простом копировании файла в каталог данных программы любителя коммедий. При старте программа обнаружит новый файл-БД и отобразит его. Если БД будет одна для всех жанров, то делится жанрами будет проблематично — придется прикручивать некий экспорт/импорт. Это то же вариант, но хочется проще.
P>Опять же, если у Вас есть проблемы с одновременным доступом — используйте транзакции. Можно например монопольно захватить запись, отредактировать ее и потом обновить...
Ага это мне и нужно. Только я не знаю — есть ли возможность у MS SQL или др. хранить каждую БД в отдельном файле? Не знаю в силу слабого знакомства с СУБД.
А нельзя ли как-нибудь ассоциировать XMLDocument с файлом, в котором он хранится и при добавлении узла документа и сонхронизации с файлом получить не полную сериализацию объекта, а лишь дописывание в определенное место файла нового узла? Или это все равно будет выглядеть как: чтение файла, сопоставление его внутренностей с объектом в памяти, запись в нужное место потока файла нового узла, сохранение всего потока обратно в файл?
P>>>Тут же можно посмотреть в сторону Business Logic Toolkit.ъ P>Вот Форум, вот статья
Здравствуйте, Ocenochka, Вы писали:
P>>>>Можно попробовать поработать с MS Access (проект Janus, он же оффлайн клиент для RSDN использует базу данных MS Access и разворачивается он давольно легко). O>>> Я смогу окткрыть несколько БД с одинаковой структурой, но разными записями, чтобы эти БД были ассоциированы каждая со своим файлом и иметь к ним независимый одновременный доступ? P>>Теоритически да, только не пойму зачем. Если Вам необходимо содержать несколько версий одной записи книги, можно сделать отдельную таблицу для этого. То есть, мы создаем постоянную таблицу для записей книг и одну таблицу для промежуточных записей. Таким образом при редактировании записи она копируется в промежуточную таблицу и там редактируется, а после редактирования производится обновление постоянной таблицы.
O> Список книг и их описаний — это структура БД. Таблицы. O> Мне нужно, чтобы был список детективов в одном файле, список коммедий — в другом. Они должны легко переносится из одной копии программы в другую. Зачем это? Есть дав пользователя — у одного список детективов, у другого — коммедий. Любитель детективов хочет дать свой список любителю коммедий. Я это вижу в простом копировании файла в каталог данных программы любителя коммедий. При старте программа обнаружит новый файл-БД и отобразит его. Если БД будет одна для всех жанров, то делится жанрами будет проблематично — придется прикручивать некий экспорт/импорт. Это то же вариант, но хочется проще.
Работа с файлами выглядить проще... Но в этом случае надо будет писать быстрый алгоритм работы с файловым хранилищем.
В случае с одной базой данных можно сделать так:
Программа-источник выбирает из базы данных необходимую информацию (например коллекцию книг определенного жанра)
Серилизует эти данные в хмл и отправляет программе-приемнику.
Программа-приемник десерелизует эти данные и добавляет к себе в базу данных
То есть не все так страшно с базами данных И работаеют они достаточно быстро. И в принципе нет необходимости в нескольких базах данных — все можно спроектировать в одной.
P>>Опять же, если у Вас есть проблемы с одновременным доступом — используйте транзакции. Можно например монопольно захватить запись, отредактировать ее и потом обновить... O> Ага это мне и нужно. Только я не знаю — есть ли возможность у MS SQL или др. хранить каждую БД в отдельном файле? Не знаю в силу слабого знакомства с СУБД. O> А нельзя ли как-нибудь ассоциировать XMLDocument с файлом, в котором он хранится и при добавлении узла документа и сонхронизации с файлом получить не полную сериализацию объекта, а лишь дописывание в определенное место файла нового узла? Или это все равно будет выглядеть как: чтение файла, сопоставление его внутренностей с объектом в памяти, запись в нужное место потока файла нового узла, сохранение всего потока обратно в файл?
Готового решения к сожалению я не встречал...
P>>>>Тут же можно посмотреть в сторону Business Logic Toolkit.ъ P>>Вот Форум, вот статья
Здравствуйте, Ocenochka, Вы писали:
O> Только я не знаю — есть ли возможность у MS SQL или др. хранить каждую БД в отдельном файле?
SQL Express может хранить БД в отдельном файле. Там так и было задумано что юзеры могу файл с бд скопировать, или послать как аттачмент по почте и получатель сможет потом этот аттачмент открыть
P>Работа с файлами выглядить проще... Но в этом случае надо будет писать быстрый алгоритм работы с файловым хранилищем.
Согласен, но это вроде бы не так сложно, хотя, естественно и время и нервы. Но зато более масштабируемо получается.
P>В случае с одной базой данных можно сделать так:
P>
P>Программа-источник выбирает из базы данных необходимую информацию (например коллекцию книг определенного жанра) P>Серилизует эти данные в хмл и отправляет программе-приемнику. P>Программа-приемник десерелизует эти данные и добавляет к себе в базу данных P>
P>То есть не все так страшно с базами данных И работаеют они достаточно быстро. И в принципе нет необходимости в нескольких базах данных — все можно спроектировать в одной.
Я сейчас объемы информации оцениваю... Думаю все в файлах можно хранить. Актуальный комментарии получать в несколько потоков и по достижению какого-то объема скидывать в файл, предвариельно его блокируя и делая бэкап.
Спасибо за помощь.
И работаеют они достаточно быстро. И в принципе нет необходимости в нескольких базах данных — все можно спроектировать в одной.
