Итак, в настоящее время в нашей системе мы храним файлы изображений в базе данных (SQL Express 2005). К сожалению, не предполагалось, что это достигнет максимального размера базы данных, разрешенного лицензией SQL Express. Поэтому я предложил план хранения изображений в файловой системе и индексации только тех мест, где файл находится в базе данных.
План состоит в том, чтобы сохранить корневой путь в нашей таблице параметров как что-то вроде ImagesRoot а затем только сохранение фактического идентификатора изображения в таблице, который в основном является FK из PK записи с изображением. Я решил, что было бы лучше разделить это на подкаталоги внутри ImagesRoot на основе каждых 1000 изображений, поэтому в основном (ImagedID / 1000) \ (ImageID% 1000) (например, ImageID - 1999, он будет в% ImageRoot% \ 1 \ 999).
Я ищу любые потенциальные ловушки этой системы и все, что можно улучшить, так как я уже получаю некоторое сопротивление со стороны владельца компании, который хочет, чтобы все было в базах данных. По этим причинам я бы также назвал причины Зачем все это должно быть в базах данных.
Я должен упомянуть, что у нас уже есть автоматизированные резервные копии, которые выполняются для всех баз данных наших клиентов и любых файлов, которые создаются нашей программой и которые необходимо сохранять в течение определенного периода времени. Это необязательно, но если кто-то не использует нашу систему ожидается, что они используют свои собственные, иначе потеря данных не является нашей проблемой (это если наша система выйдет из строя, а они ее используют!).
Спасибо
редактировать
Некоторые люди предлагают использовать 2008 R2 в качестве возможного решения этой проблемы. Это хорошая идея, мне просто нужно будет рассмотреть проблемы, связанные с устаревшими программами, использующими эти базы данных. Не все из них используют хранимые процедуры, а некоторые не очень удобны в обслуживании.
Если вы собираетесь таким образом разбить структуру каталогов (а вам следует это сделать), вам не следует использовать предлагаемый вами метод, который будет склонен к кластеризации. Вы должны реализовать ту же концепцию, но на основе хешированного значения имени файла.
Например, вместо того, что вы предлагаете, сделайте хеш имени файла (я буду использовать md5), а затем создайте подкаталоги на основе значения хеша:
Your proposal:
FILE=1999, H1=1, H2=999, FILEPATH=1\999\1999
FILE=1998, H1=1, H2=998, FILEPATH=1\998\1998
FILE=1997, H1=1, H2=997, FILEPATH=1\997\1997
Hashed solution:
FILE=1999, MD5=2554fe5cd0a1b3fb7f9ec112fd326744, H1=2, H2=54, FILEPATH=2\54\1999
FILE=1998, MD5=82ec15656dd2b8a3e50ff36643a713ad, H1=8, H2=2e, FILEPATH=8\2e\1998
FILE=1997, MD5=9cc2e1e538bd538014d294138a85e20b, H1=9, H2=cc, FILEPATH=9\cc\1997
Преимущество этого заключается в том, что он распределяет использование папок более равномерно, что позволяет вам делать такие вещи, как распределение папок по дискам для повышения производительности и т. Д.
Вполне вероятно, что ваша БД имеет встроенные функции хеширования, которые позволят вам рассчитывать путь на лету, вы также можете легко вычислить его один раз в коде и сохранить весь путь.
Мой пример MD5 может не быть стандартом (я думаю, что SHA1 более распространен), но это было просто для того, чтобы получить рабочий пример.
Основная причина поместить все вещи (в основном изображения и файлы) в базу данных - это проблема защиты. Для защиты я имею в виду, в данном случае, контроль доступа для защиты материалов, написанных авторским правом. Таким образом, вы можете контролировать, кто и когда видел / получил доступ к определенному ресурсу и отслеживать его, а с помощью процедуры входа в систему вы также можете решить, кто имеет право на доступ к этим ресурсам.
Почему вы достигли максимального размера db (10 ГБ) в R2?
Большие двоичные объекты, хранящиеся в файловой системе, НЕ СЧИТАЮТСЯ НА ПРЕДЕЛ РАЗМЕРА.
Дополнительная информация об этой действительно приятной функции: