Препоръчително място за съхранение на документи - в база данни или другаде?

Единственото ограничение за съхраняване на документи в базата данни е технологично.

Една база данни за релации е предназначена да бъде постоянното хранилище на критичните данни на едно предприятие. Колко добре може да изпълнява тази функция, разбира се, варира от база данни до база данни и система до система. Но в идеалния случай ACID свойствата на релационна база данни са предназначени да я превърнат в хранилище на всички корпоративни данни. Файловата система, системите за контролери на ревизии и други локални системи за съхранение може да имат специфични предимства, но те не са предназначени за корпоративно съхранение на данни като такива.

Ако документите, които съхранявате, се квалифицират като корпоративни данни - ако се използват постоянно в цялото предприятие - тогава е логично да ги съхранявате в базата данни. Ако имате проблеми със съхранението в базата данни, може би DBA може да намери по-добро решение. Може дори да се наложи да ги преместите от базата данни от съображения за производителност, но не мисля, че трябва да ги преместите от базата данни от съображения за най-добри практики.

Разбира се, ако документите не са корпоративни данни, ако се използват само за едно приложение, да речем, тогава преместването им извън базата данни също би имало смисъл.

Въз основа на моя опит бих казал да ги запазите в базата данни. Преместихме две от нашите системи да правят това.

Поставянето му в базата данни означава:

• Лесен е за достъп дори от множество сървъри
• Архивира се автоматично (вместо да има отделна работа за това)
• Не е нужно да се притеснявате за пространството (тъй като хората пазят DB от препълване на диска, но може да забравят да следят къде се съхраняват документите)
• Не е нужно да имате сложна схема на директория

Имахме документи извън базата данни. Става проблем с много документи. Нормалната директория в Linux е един блок, който обикновено е 4K. Имахме директория, която беше 58MB, защото имаше толкова много файлове в нея (беше просто плоска директория, без йерархия). Имаше толкова много индиректни блокове. Изтриването отне повече от час. Отне минути, за да се получи броят на файловете в директорията. Беше ужасно. Това е на ext3.

С файловата система ви трябва:

• Отделен механизъм за архивиране (от архивирането на DB)
• За да поддържате нещата в синхрон (така че записът да не съществува в DB без файлът да е там)
• Йерархия за съхранение (за предотвратяване на проблема, изброен по-горе, така че нито една директория да не се окаже с 10 000 файлове)
• Някакъв начин да ги видите от други сървъри, ако имате нужда от клъстер (така че вероятно NFS или нещо подобно)

Наистина е болка. За всякакъв нетривиален брой документи бих препоръчал да не използвате файловата система въз основа на това, което съм виждал.

Предпочитам да съхраня документа във файловата система и след това да съхраня връзка към файла и свързаните метаданни на файла в базата данни.

Той се оказа по-удобен, по-лесен за поддръжка и по-евтин от алтернативата.

Повечето системи за управление на документи от корпоративен клас НЕ съхраняват обектния файл в базата данни. Това, че можете, не означава, че трябва. Ако мащабируемостта и производителността са важни за вас и имате голям набор от документи, трябва да сте много внимателни при съхраняването на обектите в базата данни. Помислете за следното:

В случай на изображения на документи, 200 милиона TIFF файла могат да се считат за относително голяма, но не масивна система. Системите с по-голям мащаб могат да имат над 1 милиард обектни файлове. При, да речем, 20KB на битонален TIFF може да имате 4TB място за съхранение на обектни файлове. Колко време ще отнеме архивирането на вашата база данни? Колко време ще отнемат вашите запитвания? Каква е честотата на достъп до тези обекти? Ако тези обекти имат висока честота на достъп, искате ли вашият DB сървър от висок клас да прекарва цялото си време в обслужване на файлове? Ако имате милиони обекти, тогава трябва да бъдете адски внимателни относно това как проектирате решение, където обектите се съхраняват в db.

Да предположим, че сега имате задачата да конвертирате тези 200 милиона TIFF файлове в PDF файлове. Бъдете готови да поставите вашето решение на колене, тъй като вашият сървър на база данни губи времето си, обслужвайки всеки обектен файл в процеса на преобразуване и след това повторно запазване на резултатите.

Само като пример, Sharepoint е известен със съхраняването на обекти в db. Sharepoint също е известен с проблеми с мащабируемостта.

Моят отговор:
За малки системи (‹ 1M файлове) може да се обмисли съхраняването на файлове в DB. За големи системи (> 1M файлове) съхраняването на файлове в DB е грешка.

Най-голямата ми грижа при съхраняването на файловете в самата база данни е управлението на размера и сложността на архивирането и други операции по поддръжка на db.

Една стратегия за смекчаване на тази трудност (поне в MS SQL) е да се създадат отделни дялове на база данни, потенциално съхранявани на различни устройства.

След това отделете вашата схема на данни, така че вашите метаданни за файловете да са разположени на един дял, а действителните BLOB файлове да са разположени в отделен дял.

Тези дялове могат да бъдат архивирани по различни графици или дори да бъдат възстановени отделно.

Веднъж съм съхранявал изображения като BLOB в базата данни и съжалявах за първия път, когато трябваше да извърша групова операция върху тези изображения. Би било много по-лесно да го направите във файловата система. Освен това, както споменахте, извличането на документите е много по-бързо, ако те живеят във файлова система.

Моят прост възглед: файловата система трябва да съхранява файлове, а релационната база данни трябва да съхранява релационни данни.

Съхранявайте двоичните файлове във файловата система. Създайте ASP.NET приложение за операциите за съхранение и извличане. Можете да бъдете фантастични с уеб приложението (версии на документи, многостепенна защита и т.н.). Мисля, че това е консенсусът в индустрията за управление на документи.

Тъй като вашият „брой документи нараства драстично“, изглежда, че това придобива голям мащаб. Може да искате да започнете да търсите готови решения на трети страни (като http://kofax.com/capture/ – Имам богат опит с това!), за да свърша „мръсната работа“ вместо вас. Или още по-добре, обмислете да разгледате предлагането на SaaS като тези момчета http://www.edocumentsolutionsllc.com/

:-)

Съхранявайте вашите документи като файлове като .doc, ако искате да имате достъп до файловете и да ги редактирате и запазвате отново.

Съхранявайте документите си като файлове като .pdf или .tiff, ако искате действителни исторически копия, които могат да бъдат изтеглени и възпроизведени.

Съхранявайте цялата информация относно вашите файлове (като дати, автори, местоположение) във вашата база данни.

Винаги съхранявам основна информация и файлов път за документи в базата данни, но никога самия документ. Рядко се налага целият документ да бъде в базата данни.

Това позволява много по-голяма гъвкавост при използването на тези документи. Например искате да използвате многослойно съхранение на резервни копия и механизми за дедупиране? Опитайте това в Oracle BLOBs.

Единственото предимство, което виждам в съхраняването на документи в базата данни, е лесното преместване на тези документи в друга среда. Отделно от това, не бих го направил поради всички вече споменати причини.

Лична експертиза: Вие сте db администратор или програмист?

Сигурност: една настройка за базата данни срещу 2 за базата данни и файловата система. Притеснение ли е, че някой случайно е преместил/изтрил файловете? В сложна настройка администраторът може да избере да премести файлове на друг сървър и просто да промени споделянето или картографирането. Знам, че това никога няма да се случи.

Нови бази данни се подобряват в тази област.

Помислете за съхраняване на вашите документи в subversion или друга система за контрол на версиите. Ще имате добро архивиране, възможност да разглеждате стари версии на документи и прекрасен мрежов достъп. Вижте „Моят живот в subversion".

Напротив, бих отишъл за съхранение в базата данни поради няколко причини:

1. По-проста стратегия за архивиране
2. Документите, съхранявани в базата данни, могат да бъдат индексирани и търсени
3. Не е нужно да се притеснявате за преместване на файлове/подправяне на сигурността
4. Лесен за пренасяне към друг сървър в случай на срив
5. Ако правителството нареди да съхранявате данни отпреди x години, управлението на това с помощта на база данни е много по-лесно

Базите данни са създадени, за да съхраняват данни. Файловете са само данни.

Въпреки че казахме, че има ползи от съхраняването на файлове във файловата система, основната е, че производителността на базата данни е по-добра и размерът е намален. SQL Server 2008 ви позволява да имате най-доброто от двата свята с помощта на FileStream. Прочетете тази бяла книга за повече информация