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

[wwswowsogon]

Доброго времени суток!

Если кому не лень, подскажите, пожалуйста, следующее. Я тут недавно стал разбираться с БД, и возникла классическая, наверное, задача: есть структура данных, состоящая из великого множества документов, каждый из которых содержит не очень много (от нескольких до нескольких десятков) записей. Примером могут служить, например, хранящиеся товарные чеки в магазине или направления на анализы для пациентов в поликлинике. Вопрос: как хранить записи каждого документа в БД? Я вижу два варианта:
1) иметь две таблицы, в одной хранить номера документов и прочие их атрибуты, а в другой хранить сваленные в кучу записи из этих документов, с привязкой к номеру/ID документа из первой таблицы, и по запросу (открытию) документа выдергивать из второй таблицы записи, относящиеся по ID.
Насколько хорош этот способ и нет ли более красивого?
2) иметь одну таблицу и хранить там ID'ы, атрибуты документов, а также пути к текстовым файлам, содержащим записи, хранящимся в отдельных директориях. Структура вроде бы более упорядоченная, но это противоречит концепции "всё в базе", ну и плюс совместный доступ к файлам и т. д.
Как, с вашей т. з., лучше организовать хранение данных?

[Снег Север]

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

[alexs]

Всё зависит от задачи. От объёмов данных.

Хочу только отметить, что хранить документы в файлах/каталогах просто неудобно, лучше хранить в BLOB полях таблиц.

У меня строго наоборот. Отказался от хранения документов в БД, теперь там только ссылка на файл.
Но всё же - всё зависит только от задачи.

[azsx]

хранящиеся товарные чеки в магазине или направления на анализы для пациентов в поликлинике

Обратите внимание, если выключат свет, то многие БД с защищёнными транзакциями скорее сохранят изменения на диск, в отличии от файлов, которые пишутся в буфер без вашего участия. Но это мелкая придирка.
Когда мне надо было хранить десятки миллионов хтмл страниц, я хранил их файлами + имя файла -- это значимое id (md5 сумма). А вот поиск по содержимому файлов я реализовал триграммами в БД. Всё зависит от вашей задачи.

[alexs]

Обратите внимание, если выключат свет, то многие БД с защищёнными транзакциями скорее сохранят изменения на диск, в отличии от файлов

Если у вас сервер без УПС - то разговор поднимать даже не стоит.

[vitaly_l]

хранить десятки миллионов хтмл страниц, я хранил их файлами + имя файла -- это значимое id (md5 сумма).

Пардон что встреваю... но увидев очередной подвох ведущий к взрыву на АЭС, решил сообщить программистам, что (md5 сумма) - не является уникальным id, тем более когда речь о десятках миллионов страниц. Соответственно использование md5 в качестве id - приведёт к атомному взрыву на АЭС. Таким образом, была пресечена очередная попытка диверсантов, произвести взрыв на АЭС, учитывая что, программисты разрабатывающие ПО для АЭС - обучаются (в том числе) и на этом форуме. Кроме того пресечена попытка, уничтожения самолётов и ракет, путём диверсионно внедряемого md5 в качестве уникального id, которое при дублировании значений выводят из строя подкрылки и ланжероны, т.к. названия файлов имеют одинаковый результат после md5. Соответственно пилоту, после запроса, возвращается заведомо ложный документ, с ненадлежащей инструкцией. После выполнения, которой - самолёт или ракета - падают и разбиваются. Соответственно использование md5 в качестве уникального id - это диверсия.

PS: топик-стартеру: вообще хранить текстовую информацию в 1 000 000 000 файлах при наличии БД, довольно сильно нагрузит систему. С другой стороны, если это PDF файлы или картинки, а не текст, то можно и на диске. Вы бы лучше привели полный пример одной записи и тогда станет понятно как её лучше хранить.

[Mirage]

Я так понял, сложность в том, что помимо структурированных данных, есть еще не структурированные. Хотя почему чеки или направления вдруг неструктурированные непонятно.
Я бы хранил такие либо в jsonb, либо, если много и большие в файловом хранилище, а в БД ссылки и, возможно, метаданные.
Индексация для полнотекстового поиска - Elastic или Sphynx.

приведёт к атомному взрыву на АЭС

На АЭС не бывает атомных взрывов.

если выключат свет, то многие БД с защищёнными транзакциями скорее сохранят изменения на диск, в отличии от файлов, которые пишутся в буфер без вашего участия

Это как? Без электричества что-то куда-то запишут?

[serbod]

Есть два подхода:

1. Реляционная нормализованная БД (SQL). В одной таблице "шапки" документов, в другой таблице табличные части документов и идентификатор строки из таблицы "шапок". А еще таблицы-справочники для товаров, клиентов, адресов, итд.. Чтобы получить нужный документ из базы, нужно составлять запрос на языке SQL. Это старая и "зрелая" технология, с широкими возможностями по формированию отчетов, но с ощутимыми проблемами с маневренностью на больших масштабах.

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

[vitaly_l]

На АЭС не бывает атомных взрывов.

Да?... печалька... Но сбои-то бывают?! И создание уникального индекса, силами md5 - именно к сбоям на АЭС и приведёт!

[Снег Север]

У меня строго наоборот. Отказался от хранения документов в БД, теперь там только ссылка на файл.
Но всё же - всё зависит только от задачи.

Если речь о хранении файла документа с относительно редким вытаскиванием его на просмотр/отсылку, то я не представляю, как хранение в каталогах может иметь преимущество над БД. Самый медленный неудобный и ненадежный вариант.

[vitaly_l]

я не представляю

А кстати круто... надо попробовать. Спасибо, добрый: обкуренный заснеженный северный физик!

Добавлено спустя 12 минут 54 секунды:

NoSQL

Стал искать про NoSQL и наткнулся на статью работника оракл. я её тут сохраню, кому интересно почитайте, он уверяет что ускорил MySQL в 750 раз (я пока ещё не дочитал, но решил сохранить ссылку): http://tokarchuk.ru/2010/10/nosql-in-my ... ove-mysql/

[serbod]

Мы подумали и решили, что лучшим решениям являлся бы встроенный в MySQL сервер NoSQL, который был бы доступен по сети. Т.е. написать сетевой сервис, MySQL плагин, который будет принимать запросы на определенных портах, используя NoSQL протокол, а изнутри получать доступ к InnoDB используя внутренний MySQL API для движков хранилищ. Это очень похоже на NDBAPI, только работает с InnoDB.

Это просто прямой доступ к таблицам хранилища, без использования SQL.

[vitaly_l]

Это просто прямой доступ к таблицам хранилища, без использования SQL

Да, я уже тоже дочитал. Но там всё равно для меня многое было новым, наравне с NoSQL (ещё в процессе идентификации).
Чем больше занимаешься программированием, тем глубже становится бездонная бочка вариантов использования, простых: 0 и 1. (с)

[Mirage]

И создание уникального индекса, силами md5 - именно к сбоям на АЭС и приведёт!

Не то чтобы я рекомендовал использовать md5 для чего-либо, кроме разве что, контроля целостности, но, к сожалению, вероятность сбоя на АЭС несопоставимо выше, чем вероятность совпадения 128-битных хэшей. Потому как последняя с практической точки зрения нулевая. Но при наличии злого умысла может стать единичной.

то я не представляю, как хранение в каталогах может иметь преимущество над БД

Файловое хранилище это не обязательно свалка файлов на ФС. Это обычно специализированное, нередко облачное ПО, с каким-нибудь удобным интерфейсом, типа S3, с версионированием, распределенностью, избыточностью, функциями CDN и т.д. К примеру, CEPH.

[wwswowsogon]

Всем спасибо за участие и многую информацию! Я определился, думаю, пойдем по первому сценарию.
Если позволите, ещё вопрос, не совсем в тему но по БД же.
Почему не работает LIKE в нижеприведенном примере?
Есть таблица, в ней один раз встречается имя Robert.
Запрос возвращает данные только, если написано LIKE 'Robert', по принципу вхождения подстроки результат пустой почему-то, соответственно, весь смысл использования LIKE теряется.

Код: Выделить всё

Main.SQLQuery1.SQL.Text := 'SELECT * FROM PACIENTS WHERE LASTNAME LIKE ''Robert'';

- это работает.

Код: Выделить всё

Main.SQLQuery1.SQL.Text := 'SELECT * FROM PACIENTS WHERE LASTNAME LIKE ''Rob'';

- а это - нет.

Да, Firebird 2.5.