Russian Qt Forum

Дайте совет если кто сталкивался. Пишется база данных для учета обработки материалов. Материалы в данным случае это файлы объемом десятки мегабайт. Данный материал в процессе обработки переходит из одного отдела в другой. Предполагалось что принимающий материал отдел, будет заносить этот материал в базу, все последующие отделы будут выгружать их к себе производит обработки и результат будут вносить в базу. Тем самым в базе будет храниться как входящий оригинал материала, так и промежуточные результаты обработки. Соответственно на последнем этапе будет данные которое непосредственно передадут заказчику. В связи с этим возникает вопрос, как лучше хранить данные: полностью кидать их в базу или сами файлы скидывать в файловое хранилище, недоступное пользователям, а в базу кидать ссылки на их расположение в хранилище, а по запросу пользователя передавать их?

Ты бы БД написал сначала.

Я бы посоветовал сначала нарисовать диаграмму взаимоотношений и проработать все возможные действия. На основании этого строим требования и смотрим что хорошо,а что плохо. Заодно и БД выбираем.

PS как показывает практика в 70% случаев говорят "Вот какая то база у нас есть, делайте всё в ней".

В БД хранить бинарные данные удобней, но время доступа к данным будет больше чем к данным из хранилища. В Вашем случае размер данных довольно велик и загрузка\выгрузка данных займет минуты. Попробуйте провести тест для точного определения этого времени. Если оно удовлетворяет требованиям к Вашей системе, то храните в БД. И еще. Прежде чем проектировать БД, проанализируйте потоки данных. Частоту загрузки\выгрузки данных, суммарный объем активных данных, жизненный цикл данных. Это поможет избежать многих проблем в будущем.   

Как показала моя практика, в SQLite лучше не хранить бинарные данные.

В SQLite же вроде всё хранится в строках? Могу конечно и ошибаться, но именно такая информация у меня отложилась :)

В БД подобных SQLite, ясно дело хранить большие объемы бинарных данных не стоит, они не для этого предназначены.
СУБД должна иметь возможность определения под эти цели отдельного табличного пространства с возможностью разбивки его по частям.

Одна из любимых холиварных тем разработчиков БД. В приличных СУБД для этого даже специальные типы данных придумали вроде FileStream и FileTables. Правильный ответ на этот вопрос всегда требует кучи наводящих вопросов, типа:
- какая СУБД?
- какой обычный размер файла?
- как часто изменяется файл?
- нужна ли репликация?
- как производится резервное копирование?
и т.д и т.п.

:) вот. именно поэтому и возник данный вопрос. я не спец по написанию баз данных и не могу составить спектр вопросов которые придется решать при эксплуатации по. :(

Я в одном из проектов поступил так - для простоты засунул изображения в БД (SQLite). Как только начали жаловаться на торможения при работе с раздувшейся базой, я вынес картинки из базы.

Ну теперь-то все правильные вопросы заданы? Или что-то ещё непонятным осталось?