akrushСимонов Денисakrush,

если для хранения сканов хочется разместить их в отдельную БД, то возникает логический вопрос, а на хрена тогда вообще БД, проще в расшаренной папке хранить.

Есть несколько причин:
1. При каждом обращении человек подает новое заявление и справки. Если хранить в папке - пользователя практически не реально заставить хранить информацию или в структуре или правильно называя файл.
2. Нет прямого доступа к персональным данным на сканах. Понятно что опытный пользователь откроет БД и посмотрит, но таких на 220 коиентов 1-3%
3. При 50тыс. заявителях - это либо дополнительно 50тыс. папок по номерам заявлений и внутри папки по номерам подачи разных заявлений, либо вообще все в одной папке. А это, даже при 5 обращениях+3 документа, 50000*5*3=750 000 файлов/папок. Не думаю что операционка себя будет комфортно чувствовать. Да и поиск в таком количестве усложняется, даже программный поиск.

Готов выслушать (прочитать) возражения. :)
а чего это юзеры столько всего решают, а не вы?
и название файлам таки можно же дать самому, а юзерам алиас отдавать

Basil A. SidorovИ, по опыту всё той же позапрошлой работы, могу сказать, что первый вариантом был как раз "блобы в базе".
Сдохло, ибо:
1. Требуется больше места, чем на диске;
2. Сильно дороже по ресурсам.

Вторым вариантом был "свалим все файлы в одном каталоге".
Сдохло ибо сканирование ~65000 файлов в одном каталоге - (сравнительно) очень медленно.

Третьим вариантом было хранение в иерархии каталогов.
Вполне нормально, хотя реализация была далеко не идеальной.
о5 25 (
если вы сложите всё в одну папку, ОНО УМРЁТ. Потому что МУХ всё содержимое каталога СКАНИРУЕТ каждый раз, когда туда идёт запрос.
Поэтому не кладите 50000 файлов в один каталог , это я вам как админ говорю. Каталоги != таблицы, в них нельзя хранить триллионы строк!

А вот если вы сложите свои файлы так: /in/di/vi/individual.php
то у вас всё будет летать даже при миллионах файлов, ибо каждый слот даёт 26 букв + 10 цифр, итого 36 ** 6 = 2176782336 (кол-во дир, НЕ файлов! В каждой штук по 500 файлов себя вполне нормально чувствовать будут)
главное цифрами названия не делать, а то из-за ограничения int там на 1-2 будет сильно больше, чем на остальных

alekcvpВсе эти данные требуется хранить в одной таблице, и тут возник вопрос: как оптимальнее их туда складывать - напрямую данные в BLOB поля таблицы или в таблице хранить только все остальные параметры и имя файла, а сами файлы - в отдельной папке/папках на диске? Как будет правильнее с точки зрения производительности базы данных? Повлияет ли большая таблица с BLOBами на скорость работы всей базы в целом или только на эту таблицу?

P.S: Доступ к этим записям (и файлам) в 99% времени будет только на чтение.
ну вот пару мыслей на этот счёт:
авторfacebook оптимизировали свой сервис после возросшей нагрузки:

Кеширование более часто используемых миниатюр изображений в памяти на оригинальных серверах для масштабируемости, надежности и производительности
Распределение их по CDN для уменьшения сетевых задержек
Возможно сделать еще лучше:
Хранение изображений в больших бинарных файлах (blob)
Сервис, отвечающий за фотографии имеет информацию о том, в каком файле и с каким отступом от начала расположена каждая фотография (по ее идентификатору)
Этот сервис в Facebook называется Haystack и он оказался в 10 раз эффективнее «простого» подхода и в 3 раза эффективнее «оптимизированного»
и:

alekcvpakrushПросто я пока ума не приложу как лучше. Создавать по отдельной папке на клиента - 75тыс. папок. не будут ли операции с файлами подвисать при входе в эту папку. Если нет - то тогда решение есть:
1. На каждого клиента по папке по его уникальному номеру
2. Внутри папки по обращениям
3. в папке обращения сканы.
Тут выше уже приводили, на мой взгляд, удобное решение с хранением файлов по ID и разделение на папки по классам.

нельзя их по ID хранить, потому что из-за ограничения на int, файлов с 1-2 в начале будет сильно больше (~5 раз), чем всех остальных

Ariochtip78МУХ всё содержимое каталога СКАНИРУЕТ каждый раз

Это в FAT/FAT32 где директории - простой несортированный массив

В других системах это деревья

http://spider.seds.org/spider/OS2/HPFS/dirs.html
http://ext2.sourceforge.net/2005-ols/paper-html/node3.html
да хоть кусты, суть не в названии, а в ресурсах. На линухе это всё так же прекрасно виснет и падает.

Basil A. SidorovОбъясните, каким образом в предложенной мною схеме может возникнуть значимая неравномерность?
Если, конечно, исключить патологический случай, когда мы случайным образом теряем девяносто процентов идентификаторов монотонной последовательности.
ну в hex int = 7FFFFFFF
т.е половина (8-F) будет в меньшинстве

AriochBasil A. Sidorov,

оттуда же, откуда у tip78 в 21354526

ВК - верхнего уровня корзина
tip78 B.A.S. ВК по tip78 ВК по B.A.S.1.txt 00000001.txt 1 002.txt 00000002.txt 2 003.txt 00000003.txt 3 004.txt 00000004.txt 4 005.txt 00000005.txt 5 00.....11.txt 00000011.txt 1 0012.txt 00000012.txt 1 0013.txt 00000013.txt 1 0014.txt 00000014.txt 1 0015.txt 00000015.txt 1 00.....

Будет ли неравномерность проблемой или нет - вопрос отдельный.
эта тема с каталогами не для файлов 1.txt, а 127627334.txt

а вы минималку в генераторе поставьте на 1000000 и будет счастье

Ariochtip78файлов с 1-2 в начале будет сильно больше (~5 раз), чем всех остальных

content-addressed storage обычно на хэшах делается

а хэши распределяются равномерно
чё за хеши то?
эти: 7fffffff ?