Оптимальное хранение Image в БД MSSQL

[zubr]

Собственно, вопрос не конкретно по MSSQL, думаю тип БД здесь не принципиален. Ситуация такова: Достаточно-большая клиент-серверная БД, работающая в локальной сети, должна хранить различную информацию, в том числе и фото. Как оптимальнее с точки зрения скорости работы БД, резервного копирования, безопасности (на случай слета диска, с возможностью последующего восстановления) хранить фото:
1-й вариант: хранить фото в файлах, а в БД линки на файлы
2-й вариант: хранить фото в отдельной от других данных таблице БД

[Алексей++]

1 вариант лучше , только бэкапы для папок с фотами тоже не забывать делать

[Джон]

Хммм...

Я бы сделал второй вариант. Обоснование - центральное хранение информации. Так перекрываются пункты "резервного копирования и безопасности". Иначе надо для КАЖДОГО бэкапа БД делать соответствующий бэкап ВСЕХ файлов. Запаришься управлять такой системой.
Но надо смотреть как часто изменяются файлы - в смысле содержимое файлов, сколько их, сколько одновременных пользователей у БД. Если очень часто, много, много, то стоит ли так нагружать БД, да и потянет ли она? Справится ли? Что будет, если например несколько пользователей захотят одновременно изменить один и тотже файл?  В таком случае может быть лучше применить какую-нить систему управления версиями? А ля SVN. И уже бекапить её в свою очередь.

[zubr]

Пользователей у БД будет не много (не более 5 одновременно), фотки в основном будут добавляться, а не изменяться (хотя возможность редактирования присутствует). Но за счет фоток БД будет разрастаться на 2 гига в год. Меня смущает следующее - если слетит диск, вероятность что можно будет восстановить БД в каком случае выше, когда 1 но большой файл БД надо восстановить (2-й вариант) или не очень большой файл БД + тысячи файлов фоток (1-й вариант).

[Джон]

Вероятность в обоих случаях равна 50% - либо восстановишь, либо нет.

В этом приколе есть доля правды. Если ты восстановишь БД из бэкапа, то восстановишь ВСЁ. С отдельными файлами такого нельзя гарантировать. Я имею ввиду, что восстановив БД, ты так же восстановишь ВСЕ отдельные файлы, именно к ней относящиеся. Кроме того это будте такой геморр. Но это конечно зависит от того, как ты их будешь сохранять, как часто, и какую версию потребуется восстановить. ЭТо кстати не обязательно должно произойти в результате сбойя харда. У юзеров, как известно, ручки ой какие шаловливые.

При уточнённых условиях я всё больше склоняюсь к хранению файлов в БД. 2Г в год это пустяк для БД. 5 юзеров - ваще ничто. Те я так понял - фото это сопутствующая инфорамация, а не основная? Как например БД для фотографов.

[Malaja]

У нас в БД реализован именно первый вариант. При этом файлы лежат на той же машине, что и БД, поэтому при ежедневном бекапе все копируется.

[zubr]

Те я так понял - фото это сопутствующая инфорамация, а не основная? Как например БД для фотографов.

Да, это сопутствующая информация.

Я тоже склоняюсь к 2-му варианту. Тем более заказчик удаленный и с шаловливыми ручками. В период моего с ними сотрудничества у них уже система слетала (какой то юзер вируса занес), так пришлось им пошаговый хелп писать по установке MS SQL.

Всем спасибо.

[RXL]

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

На работе имеется опыт подобного. Система была запущена еще до меня. Я предлагал начальнику поменять ее на хранение картинок в файлах, но он настоял на текущем решении. Итог: дапм базы все растет и растет и скоро перестанет влезать на DVD болванку. Приходится делать его инкрементальным, что снижает надежность хранения бекапов, т.к. при порче "нулевого" бекапа не удастся востановить базу из инкрементального. Выход: раз в год все равно делаю полный бекап.

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

Минус БД: нельзя просмотреть картинку без спец.написанной проги. В случае файлового хранения можно сделать любым просмотрщиком картинок.