Подскажите, пожалуйста как лучше сделать?
Приложение работает с БД и основано на просмотре и контроле документов. Как лучше сделать - сохранять в поле BLOB весь текст doc-файла или же в поле сhar сохранять ссылку на файл?
поле BLOB vs. char для word документа
Модератор: kdv
-
Platon_Elenin
- Сообщения: 8
- Зарегистрирован: 10 янв 2007, 11:55
Re: поле BLOB vs. char для word документа
Мы в подобных случаях храним в блоб полях контент документа. Это может быть doc файл, tiff файл, pdf - неважно. Но это лучше, чем хранить эту информацию в файловой системе. Это наше мнение, конечно, но при построении электронного архива судебных решений в первой версии образы документов мы хранили в файловой системе, указывая в БД путь к документу. Достаточно быстро от этого отказались
-
Platon_Elenin
- Сообщения: 8
- Зарегистрирован: 10 янв 2007, 11:55
Ну, CyberMax, уже ответил. В любом случае хранение непосредственно в файловой системе - это менее надежный и менее защищенный вариант. Немаловажно и количество хранимых единиц информации. У нас на сегодняшний день более 200 тысяч документов. Такое количество файлов даже для современных ОС - перегрузка для файловой сисиемы. При хранении в БД все это выглядит намного комфортнее и, если хотите, гигиеничней.Platon_Elenin писал(а):А почему отказались, что не устроило?
ИМХО - разумный предел - это размер хранимого документа, можно конечно и фильмы в базе хранить, но потом на клиента это тащить ....WildSery писал(а):Всё имеет свои разумные пределы.
Мы храним сертификаты (картинки) не в базе, а по путям, потому как их более 1.2 млн. штук, в общей сложности около 45Гб кажись.
Так что гигиена гигиеной, а таким куском можно и подавиться.
Я отмечал, что в нашей системе количество хранимых документов превышает 200 тыс единиц. Причем документы многостраничные и в сумме это более 1.2 млн. страниц формата А4. Все хранится в формате tiff. По объему это чуть больше 60 Гбт. Пока не подавились, и уверен, что это нам не грозит.WildSery писал(а):...потому как их более 1.2 млн. штук, в общей сложности около 45Гб кажись.
Так что гигиена гигиеной, а таким куском можно и подавиться.
Есть, правда, одна небольшая хитрость, образы документов мы храним в отдельных БАЗАХ ДАННЫХ. На каждый год каждого месяца создается своя база. При наших темпах закладки документов месячная БД разарастается до примерно 1..1,2 Гб. Это нас вполне устраивает. При такой организации работы по истечении текущего месяца БД переводится в режим ReadOnly (редактировать БД прошедших месяцев никто и никогда не будет). Резервное копирование выполняется только для текущей БД. В основной БД (делопроизводство), естественно хранится информация о каждом документе, включая дату его закладки в архив. По этой дате легко определяется БД хранения образа этого документа. Никогда никаких проблем это не вызывало.
Что храните в tiff - не отмечал 
Несколько баз... Насколько это удобно, и в чём отличие от хранения в отдельном каталоге?
Мне вот не видится разницы, забэкапить одну папку "2006" с вложениями или базу, которая кстати и занимает больше места, и сервер FB дополнительно напрягает обработкой того, с чем и ОС замечательно справится.
Уж про репликацию вообще молчу.
Несколько баз... Насколько это удобно, и в чём отличие от хранения в отдельном каталоге?
Мне вот не видится разницы, забэкапить одну папку "2006" с вложениями или базу, которая кстати и занимает больше места, и сервер FB дополнительно напрягает обработкой того, с чем и ОС замечательно справится.
Уж про репликацию вообще молчу.
Тут уж на вкус и цветWildSery писал(а):И какой же размер разумен?stix-s писал(а):ИМХО - разумный предел - это размер хранимого документа
В моей базе, как легко подсчитать, средний размер документа 40 килобайт.
в твоем случае я в базе бы хранил.
Придется, если чел уверен, что ему это надо, тут уж никуда не денешься - либо из базы тянуть, либо с файл-сервера.WildSery писал(а): А на клиента тащить всё равно приходится, только с другого сервера, правда.
Если как SAMZ в отдельной - тут ещё можно подумать.stix-s писал(а):Тут уж на вкус и цвет
В этой же - нет. Один бэкап-рестор чего стоит. А репликацию данных даже представить страшно.
Если файлы мы на компашках перекидываем, то в базе... Гм.
Сделать-то дополнительную оффлайновую репликацию возможно, но гемор, да и выливки-заливки таких данных из базы в базу тоже не нравятся.
Не думаю, что стоит продолжать полемику в этом направлении. Это точно про попа, попадью и попову дочку. Чего совсем не понял, при чем здесь репликация.WildSery писал(а):Что храните в tiff - не отмечал
Несколько баз... Насколько это удобно, и в чём отличие от хранения в отдельном каталоге?
Мне вот не видится разницы, забэкапить одну папку "2006" с вложениями или базу, которая кстати и занимает больше места, и сервер FB дополнительно напрягает обработкой того, с чем и ОС замечательно справится.
Уж про репликацию вообще молчу.
ну, скажем к примеру сливать бэкап для переноса на мобильный диск не проблема, все зависит от конкретных условий - тебе вот к примеру репликация на эту базу нужна, а мне она вовсе не надь к примеруWildSery писал(а):Если как SAMZ в отдельной - тут ещё можно подумать.stix-s писал(а):Тут уж на вкус и цвет
В этой же - нет. Один бэкап-рестор чего стоит. А репликацию данных даже представить страшно.
Если файлы мы на компашках перекидываем, то в базе... Гм.
Сделать-то дополнительную оффлайновую репликацию возможно, но гемор, да и выливки-заливки таких данных из базы в базу тоже не нравятся.