Здравствуйте, kamui, Вы писали:
K>Преследуемая цель — хранение ВСЕХ документов в одном файле.
Я слегка не по теме...
Была у нас такая же прога которая все совала в бд (MSSQL), и в один прекрасный день все каааак навернулось. Понятное бело бэкап, но он при большом размере базы тоже не каждый день делается. В общем потеряли пару дней работы всей фирмы (порядка 250 чел за компами). После этого стали хранить только путь к файлу, а файлы раскиданы по нескольким серверам.
Есть необходимость в создании приложения под винду, осуществляющего хранение и администрирование документов в формате RTF.
Соответственно, требования: неограниченный размер самой базы, неограниченный размер поля таблицы, в котором лежит документ. Более того, очень желательно, чтобы не требовалось дополнительной установки сервера.
kamui wrote:
> Есть необходимость в создании приложения под винду, осуществляющего > хранение и администрирование документов в формате RTF.
Когда-то я пытался это сделать на Акцессе с OLE-полем.
> Соответственно, требования: неограниченный размер самой базы, > неограниченный размер поля таблицы, в котором лежит документ. Более
Такого не бывает. Любые ресурсы рано или поздно кончаются.
> того, очень желательно, чтобы не требовалось дополнительной установки > сервера.
Ну тогда точно Акцесс =)
Access да, не подойдет из-за ограничения размера базы.
А какая база позволяет реализовать ситуацию, когда размер базы ограничивается только размером жесткого диска?
Кстати, поле OLE (BLOB) тоже ограничено, как бы этого избежать.
Преследуемая цель — хранение ВСЕХ документов в одном файле.
nzeemin wrote: > РД>Ну тогда точно Акцесс =) > > У Access'а предел объема базы — 2Гб. По этой причине хранить в нем > длинные файлы — нет смысла.
На смайлик посмотри, да?
kamui wrote:
> А какая база позволяет реализовать ситуацию, когда размер базы > ограничивается только размером жесткого диска?
Ну про акцесс это я так, злую шутку запостил
А серьезно — можно посмотреть в сторону SQLite, он у нас вроде
безразмерный... http://www.sqlite.org/faq.html#q10
Только большого числа юзверей без сервера все равно не получится...
Здравствуйте, Роман Дубров, Вы писали:
РД>kamui wrote:
>> А какая база позволяет реализовать ситуацию, когда размер базы >> ограничивается только размером жесткого диска? РД>Ну про акцесс это я так, злую шутку запостил РД>А серьезно — можно посмотреть в сторону SQLite, он у нас вроде РД>безразмерный... РД>http://www.sqlite.org/faq.html#q10
РД>Только большого числа юзверей без сервера все равно не получится...
Здравствуйте, kamui, Вы писали:
K>Есть необходимость в создании приложения под винду, осуществляющего хранение и администрирование документов в формате RTF. K>Соответственно, требования: неограниченный размер самой базы, неограниченный размер поля таблицы, в котором лежит документ. Более того, очень желательно, чтобы не требовалось дополнительной установки сервера.
K>Бывает такое в природе?
sqlite посоветовали уже тут вижу. но вцелом — не вижу смысла совать документы в базу, как уже сказали — хранить uri файлов только
а сами документы — средствами файловой системы, тобишь на диске.
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
Здравствуйте, dad, Вы писали:
dad>Здравствуйте, kamui, Вы писали:
K>>Есть необходимость в создании приложения под винду, осуществляющего хранение и администрирование документов в формате RTF. K>>Соответственно, требования: неограниченный размер самой базы, неограниченный размер поля таблицы, в котором лежит документ. Более того, очень желательно, чтобы не требовалось дополнительной установки сервера.
K>>Бывает такое в природе?
dad>sqlite посоветовали уже тут вижу. но вцелом — не вижу смысла совать документы в базу, как уже сказали — хранить uri файлов только dad>а сами документы — средствами файловой системы, тобишь на диске.
Тогда получится просто еще один far. А хочется создать нечто более интегрированное.
Почтовые программы не хранят ведь файлы .eml отдельно друг от друга. Что-то вроде того.
Здравствуйте, Igor Trofimov, Вы писали:
iT>Молодцы. Готовьтесь к еще одной такой же потере. И еще к одной... И еще... пока не дойдет, что ежедневный бекап — минимум.
Ну вообще то это не мое дело делать бекапы. Для этого у нас есть всякие разные админы и целый IT отдел. По какой именно причине они перешли с ежедневного апдейта к апдейту с большим интервалом я не имею понятия, но краем уха слышал, что при тех размерах что были бекап длился несколько часов, что было невозможно обеспечить. Кароче не в том смысл, что каждый или не каждый день бекап, а в том, что как бы часто бекап не делался, теряются документы. В другом же случае теряются линки на документы и их проще восстановить.
Здравствуйте, kamui, Вы писали:
dad>>sqlite посоветовали уже тут вижу. но вцелом — не вижу смысла совать документы в базу, как уже сказали — хранить uri файлов только dad>>а сами документы — средствами файловой системы, тобишь на диске.
K>Тогда получится просто еще один far. А хочется создать нечто более интегрированное. K>Почтовые программы не хранят ведь файлы .eml отдельно друг от друга. Что-то вроде того.
Ну так посмотрел бы в сторону систем хранения open-source почтовиков: Thunderbird, KMail, Sylpheed, ...
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
HotDog wrote: > По какой именно причине они перешли с > ежедневного апдейта к апдейту с большим интервалом я не имею понятия, но > краем уха слышал, что при тех размерах что были бекап длился несколько > часов, что было невозможно обеспечить.
Инкрементальный бекап рулит. У каждой записи дата/время последней
модификации, бекапится только то что появилось/менялось с момента
последнего бекапа + раз в неделю/2/месяц полный бекап — контрольная точка.
HD>Кароче не в том смысл, что каждый или не каждый день бекап, а в том, что как бы часто бекап не делался, теряются документы.
Буквально вчера у нас выгорело одновременно три винта в серваке БД. Простой составил около 10 минут, пока (очень неторопливо) переключились на дублирующий сервер. По-уму это должно не больше минуты занимать. В Oracle это называется standby-база.
Как это называется в MS, если есть я не в курсе, и как без этого можно жить с важными данными высокой готовности — тоже не в курсе
Ну, впрочем, от программной ошибки это все тоже может не защитить ;(
Здравствуйте, HotDog, Вы писали:
HD>Была у нас такая же прога которая все совала в бд (MSSQL), и в один прекрасный день все каааак навернулось. Понятное бело бэкап, но он при большом размере базы тоже не каждый день делается. В общем потеряли пару дней работы всей фирмы (порядка 250 чел за компами). После этого стали хранить только путь к файлу, а файлы раскиданы по нескольким серверам.
На 250 человек неплохо быв завести Active Directory с DFS. Файлы будут хранится сразу на нескольких серверах и сбой любого из них не будет критическим. и теряться ничего не будет. А бекапить надо не всю БД, а разницу. Эдакий Incremental back-up.
Здравствуйте, kamui, Вы писали:
K>Есть необходимость в создании приложения под винду, осуществляющего хранение и администрирование документов в формате RTF. K>Соответственно, требования: неограниченный размер самой базы, неограниченный размер поля таблицы, в котором лежит документ. Более того, очень желательно, чтобы не требовалось дополнительной установки сервера.
K>Бывает такое в природе?
FireBird embedded
Но документы я бы хранил в файловой системе — в базе — только пути к ним
не в том смысл, что каждый или не каждый день бекап, а в том, что как бы часто бекап не делался, теряются документы. В другом же случае теряются линки на документы и их проще восстановить.
