Должен ли я хранить файл в базе данных или только местоположение этого файла? - PullRequest
0 голосов
/ 25 ноября 2010

Как лучше хранить файл? Непосредственно сохранить файл в базе данных или только местоположение этого файла?

Ответы [ 4 ]

4 голосов
/ 25 ноября 2010

Избегайте хранения файлов в вашей базе данных.Большинство плохо с ними справляются.

2 голосов
/ 25 ноября 2010

Когда вы принимаете ответы так быстро, вы не получаете выгоды от ответов более широкой аудитории.

Это зависит. Вам нужно учесть несколько вещей.

  1. Если у вас есть бесплатная база данных mickey mouse, это означает, что она не обрабатывает BLOB-объекты должным образом (читайте BLOB-объекты при каждом SELECT; не храните BLOB-объекты в отдельной области), храните файлы снаружи.

  2. Если у вас есть корпоративная база данных, то нет проблем хранить капли внутри базы данных. Они не читают капли на каждом SELECT. Одно дополнительное чтение, чтобы получить BLOB-объект, не является «проблемой» «производительности».

  3. Большинство баз данных имеют размер 2 КБ, а не 8 КБ или 16 КБ. Если у вас размер страницы больше, то в неиспользуемой части последней страницы будет немного растраты для каждого блоба.

  4. Недостаток хранения больших двоичных объектов в базе данных состоит в том, что резервные копии вашей базы данных будут намного больше. Некоторые корпоративные базы данных замечают, что страница не изменилась, и исключают ее из добавочных резервных копий; другие не имеют приращений.

  5. Преимуществом хранения больших двоичных объектов в базе данных является целостность данных и ссылок. У вас не будет проблемы с синхронизацией строк с BLOB-объектами.

    • Я завершил присвоение в прошлом году, когда в базе данных было 130 ГБ данных в БД и 700 ГБ документов, хранящихся вне БД. После десяти лет проблем они укусили пулю и переместили документы в БД. Угадайте, что, что должно было быть простой работой (длинной, но простой), потому что ссылки должны были быть абсолютно правильными, в конечном итоге оказалось массивным, потому что было так много дубликатов и недействительных ссылок. Полученная база данных составила 630 ГБ, было 100 ГБ дупсов. Размер страницы 2K.

Ответы на комментарии

  1. Косая черта или обратная косая черта
    Легко. В базе данных хранить только слеш. Вам нужен способ определения целевой системы и индикатор IsWindoze. Он должен быть выше в иерархии таблиц, а не на уровне, на котором вы находите Filename. Если индикатор установлен, когда вы сообщаете или отображаете столбец Filename, измените косую черту на обратную.
    У вас будет похожая проблема с DriveLetter и двоеточием, которого нет в Unix.
1 голос
/ 22 февраля 2011

Поздний ответ: это зависит от вашего двигателя.

  • Размер страницы 2 КБ не использовался с 1990-х годов для SQL Server.По умолчанию в Oracle используется 8 КБ, в SQL Server - 8 КБ.Только Sybase AFAIK по-прежнему находится в прошлом веке.

  • SQL Server теперь предлагает FILESTREAM , который сочетает в себе лучшее из обоих миров, как это дало Oracle дольше с BFILE

  • SQL Server и Oracle предлагают сжатие дисков и резервных копий

Я уверен, что PostgresSQL по крайней мере предлагает аналогичные функции.

Примечание: это в основном предложить альтернативы FUD для PerformanceDBA

0 голосов
/ 25 ноября 2010

Предпочтительным способом является сохранение файла в файловой системе и сохранение местоположения файла в базе данных. Причина этого связана с тем, как базы данных физически распределяют пространство на диске (обычно по 8 или 16 тысяч). Удаление больших файлов приводит к тому, что ваша база данных использует различные механизмы для хранения файлов (SQL Server вызывает эти данные переполнения строк ). Обычно страницы такого типа находятся вне обычной таблицы, поэтому каждое логическое чтение строки приводит к двум физическим чтениям на диске. Излишне говорить, что это не хорошо для производительности.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...