Всем привет!

Организации необходимо ассоциировать файлы (изображения, doc, xls, …) с информацией о персонале/соискателях (10k – 30k человек), размещённых в реляционной базе под управлением Sql Server 2005 Express + Windows 2003 Server.

Файлы планируется держать в файловой системе (не в виде BLOB полей базы) и возникает вопрос о наиболее удачной с точки зрения производительности/удобства сопровождения иерархии каталогов на жёстком диске. Наиболее частая операция –получение списка ассоциированных файлов и доступ к содержимому. Что вы думаете о таком устройстве каталогов:

Корневой каталог -> 16 подкаталогов по первой букве ID пользователя (ID – это GUID) -> подкаталоги по ID пользователя -> файлы.
Например: Data -> A -> AB32B3EF…, A05234DE… -> Файлы отдельного пользователя.
Я ввёл дополнительные каталоги (0, 1, 2, … D, E, F) по первому символу ID для удобства навигации через браузер. Список на 30K подкаталогов одного каталога на сервере открываются в течение 8-10 секунд. Однако, скажется ли это на времени доступа к файлам пользователя против плоской структуры каталога?

С пользователем может быть связано переменное число файлов различного типа, например, персональные изображения. Как вы обычно управляете порядком извлечения файлов из каталога? Например, пользователь закачал 10 изображений, и необоходимо не только извлекать их всегда в одном порядке, но и дать возможность изменять порядок извлечения (переставлять изображения, документы). Посоветуете ли вы держать словарик файлов с приоритетом на БД или можно обыграть такие вещи через имя файла? Словарик потребует дополнительной синхронизации и мне бы не очень хотелось его вводить

Заранее спасибо!

Дмитрий16,

Синхронизовать ссылки на файлы из словарика с наличием файлов на жёстком диске. Поскольку операция удаления записи и удаления файла на Sql 2005 невозможно объединить в одну транзакцию (насколько я знаю), а также не исключён администраторский доступ к файловому хранилищу в обход системы, то возможны расхождения между данными таблички-словаря и реальными данными на жёстком диске. Вероятно, здесь мне придётся создавать дополнительную задачу, что будет проверять синхронность данных, скажем, раз в сутки.

Дмитрий16,

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

miksoft,

Спасибо, я подумаю насчёт первых двух символов, а так доступ к файлам через файловый менеджер для пользователей не предусматривается) файлы будут доступны только на чтение. Хотя, требования всегда могут поменяться.