Есть пожелание создать хранилище документов. Особой обработки не предполагается.
В документе будет, может, порядка 5 полей (типа ФИО, Дата и подобных) и одно поле со сканированным документом.
И вот этих доков будет порядка 2-х миллионов.
Какие советы будут по решению задачи?
Кто-нибудь сталкивался с такими объемами. В целом может скажите как провернуть такой гигантский труд, занести это все в базу.

Образы хранить отдельно, или в крайнем случае потом взять CommonStore

Domino6, я понимаю, что краткость сестра таланта )
Но по-подробнее можно.
И все-таки как такое кол-во 2млн док-в, или их лучше на несколько баз разделить.
А CommonStore это что такое?

В мегабайтах сколько

Вопросы.
1. Разграничения доступа надо
2. Средний объем файла

CommonStore IBM штука для хранения присоединенных файлов, хорошая но дорогая

2 миллиона не страшно .
- надо только избегать списков в идах т.е. делать больше категоризированных колонок

1. Надо, но только на уровне базы, думаю, ниже не потребуется
2. Три страницы сканированного текста, может ок 600КБ

0.6 Mb x 2 000 000 = 1171,8 Gb

База не вытянет атачи надо хранить отдельно.
1. В других базах
2. В другом месте

Ограничено физическим размером файла ###.nsf - 4G

реально после 1 П еле ворочается плюс проблемы с проверкой содержания сервером

Совет.
Старайтесь не раздувать свыше 1 GB

64Gb



Совет 2: Произвести оптимизацию базы согласно "Руководство по оптимизации баз"

64G ранними версиями не поддерживается
Потому в общем случае - 4G

ps
64G - врану не пожелаю админить сервер с такими базами
да и с точки зрания сохранения функциональности - нет смысла

Вот сейчас как раз любуюсь: база 11Гб, 1800 000 документов. Пока шевелится.
А рядышком - база со сканами (маленькая). Замечено, что Нотес отлично жмет *.BMP аттачи. Монохромные - так вообще чуть не в 10 раз (хаффман рулит! в этом случае).
Но 2000 000 сканов - это IMHO перебор будет...
Хранить сканы на файловой системе - а нафиг тогда вообще Домина? Тогда уж - в СУБД...

Ух какда-то читал этот пост и удивлялся как БД может весить 12 гигов, прошло каких то пол годика на тебе моя основная БД 12.5 гигов и 33.000 доков.
Пока тоже щевелится, но т.к. новый год на носу решили эту БД упрятать в архив, и дальше работать в свеженькой.

Надеюсь, для кого-то может быть интересно: Fine Reader, сканируя документы (черно-белые), без распознавания текста с сохранением изображения в pdf дает 15 - 20 килобайт на страницу. В итоге база на 5 тыс. документов (с разным количеством страниц) около 120 мегабайт.

Еще раз повторюсь: НЕ НАДО для изображений никаких pdf и jpeg! Аттачте их как тупые BMP, а в св-вах базы не разрешайте сжатие по LZV. Старинный встроенный Хаффман их замечательно сожмет: монохромные (и без полутонов) сканы - до тех-же 10-20к. Ну, разве что разрешением поиграть придется (для текстовых док-тов достаточно 150dpi)

у меня база 64гига,документы не добавляются больше
по-моему лотус сам автоматически не сжимает доки

это ограничение не лотуса, а ОСи

]]>http://forum.codeby.net/topic24094.html]]>

Лучше бы новую тему создали, чем некропостерством заниматься...
По делу: базу Вам пора разбивать на несколько частей. Если опишете ее логическую структуру (какие доки там хранятся и какие связи между ними) - смогу подсказать получше.

3 000 000, реальная база, но док-ты мелкие (всего 15гБ)

D!m@n
Да ну, лучше ее убить,чтобы не мучаласьКак насчет сжатия доков?

Лотус на уровне документов ничего не сжимает. Сжимаются аттачменты - по алгоритму Хаффмана или LZ1, но это делается автоматически (можно только выбрать предпочитаемый алгоритм в свойствах базы).
Вы также можете воспользоваться виндовым сжатием - и сжать базу просто как файл. Но я бы не советовал так поступать с большой базой, в особенности если ее юзают часто и помногу