freepascal.ru

Привет всем.
Пара уточнений нужна, я правильно понимаю что:
1) Если в таблице хранятся файлы, то делать "Selet * From ..." в серверу БД не стоит? Поля Blob передаются в тот же момент, когда и прочие поля. И если в них много мегабайт, то беда совсем беда...
2) Есть поля для больших файлов. А есть механизм чтобы пошагово записать в одно поле данные из буфера? Я о том, что цивилизованно организовать запись файлов больше 100Мб в БД можно ли без подвисаний?

1. Блобы как раз и созданы для того, чтобы хранить бинарные данные. Если я правильно ошибаюсь, работа с блобами сильно зависит от компонентов доступа. Например, в безвременно почившем FIB+ на клиента сначала попадал ID блоба, по которому содержимое блоба выкачивалось из БД на клиента/с клиента в БД только при манипуляциях с ним. Думаю, что можно предположить аналогичный механизм у других компонентов доступа.
2. В общем случае можно, как говорится "You may if you can"

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

zoltanleo писал(а): а в БД хранить ссылки на их местоположение. Всяко быстрее будет.

В таком случае обеспечение безопасности очень проблемная штука, при архитектуре Клиент-Сервер БД. Если бы Клиент-Сервер-СерверБД, то пофиг где хранить.

Sharfik писал(а):В таком случае обеспечение безопасности очень проблемная штука

Имхо, абсолютно перпендикулярно. Главное, чтобы двери серверной были закрыты на ключ

Sharfik писал(а):1) Если в таблице хранятся файлы, то делать "Selet * From ..." в серверу БД не стоит? Поля Blob передаются в тот же момент, когда и прочие поля. И если в них много мегабайт, то беда совсем беда...

Есть проект, где хранятся фото/документы. Сама БД PostgreSQL предостовляет два вида записи файлов - через OID(LongInt), где нужно отдельно от таблиц получить, наподобие файлового значения - записываешь файл в бд, система дает этот ID которую нужно еще записать в таблицу. При SELECT * FROM значение будет получено в виде этого ID. Чтобы получить данные, нужно отдельно произвести загрузку.
И есть формат Binary(Array Byte) где при SELECT * FROM данные будут преданны клиенту полностью как есть, если файл большой - то возникают трудности. Поэтому приходится передавать без этого поля - конкретизировать поля в SELECT.

Sharfik писал(а):2) Есть поля для больших файлов. А есть механизм чтобы пошагово записать в одно поле данные из буфера? Я о том, что цивилизованно организовать запись файлов больше 100Мб в БД можно ли без подвисаний?

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

Добавлено спустя 14 минут 25 секунд:

zoltanleo писал(а):FIB+ на клиента сначала попадал ID блоба, по которому содержимое блоба выкачивалось из БД на клиента/с клиента в БД только при манипуляциях с ним. Думаю, что можно предположить аналогичный механизм у других компонентов доступа.

Зависит от реализации БД и клиента. Ну и само поле не всегда удобно хранить в виде ArrayByte, проще иметь TStream.

Если файлы больше 100 Мб, то действительно лучше хранить их отдельно, а в базе только ссылки. Если кто беспокоится за секретность, то никто не мешает хранить файлы архивированными с паролем и распаковывать только при передаче клиенту.

olegy123 писал(а):Есть проект, где хранятся фото/документы. Сама БД PostgreSQL предостовляет два вида записи файлов - через OID(LongInt), где нужно отдельно от таблиц получить, наподобие файлового значения - записываешь файл в бд, система дает этот ID которую нужно еще записать в таблицу. При SELECT * FROM значение будет получено в виде этого ID. Чтобы получить данные, нужно отдельно произвести загрузку.
И есть формат Binary(Array Byte) где при SELECT * FROM данные будут преданны клиенту полностью как есть, если файл большой - то возникают трудности. Поэтому приходится передавать без этого поля - конкретизировать поля в SELECT.

о! Спасибо

Снег Север писал(а):Если файлы больше 100 Мб, то действительно лучше хранить их отдельно, а в базе только ссылки. Если кто беспокоится за секретность, то никто не мешает хранить файлы архивированными с паролем и распаковывать только при передаче клиенту.

Не секретность, а безопасность. Хотя и секретность тут на пару процентов.
ПО клиент, которое обращается к серверу БД отдельным соединением должно работать с файловым сервером. Если подключение через интернет, то тут надо FTP или что то такое поднимать. А если внутри сети компании, то значит к файловому серверу у всех пользователей должен быть свободный доступ. Если он есть, то это и свободный доступ к этим же данным со стороны вирусов на компе пользователя. Придется прикрутить тут еще работу с файлами через "сервисную" учетную запись пользователя. Параметры которой только правильное ПО знать будет. Заморочено. Всегда сначала простые решения ищу.

Sharfik писал(а):Придется прикрутить тут еще работу с файлами через "сервисную" учетную запись пользователя. Параметры которой только правильное ПО знать будет. Заморочено. Всегда сначала простые решения ищу.

БД при входе уже организует фиксацию (транзакцию) данных и поддерживает целостность системы - тем самым не давая рассыпается. Это все из одной коробки.
Управление данными из SQL.
Репликация на разные сервера.

попробуйте это все сделать через FTP

olegy123 писал(а):ПО клиент, которое обращается к серверу БД отдельным соединением должно работать с файловым сервером. Если подключение через интернет, то тут надо FTP или что то такое поднимать.

НЕ надо никакого FTP поднимать. У нас в фирме десятилетиями работает передача файлов клиенту (и от него серверу) - по TCP, через стандартные сокеты.
Разумеется есть серверная часть и, разумеется, есть регистрация своих клиентов в конкретной БД, никак не связанная с юзерами сервера баз данных.

Снег Север писал(а):НЕ надо никакого FTP поднимать. У нас в фирме десятилетиями работает передача файлов клиенту (и от него серверу) - по TCP, через стандартные сокеты.

FTP на сокетах работает.
Ну создали аналог файлообмена параллельно БД.. Так в прогу нужно вписать работу через сокеты.
Лично я ограничиваюсь TQuery + TStream/TBytes, сотектов не вижу и картинки вывожу легко и просто.

olegy123 писал(а):

Sharfik писал(а):Придется прикрутить тут еще работу с файлами через "сервисную" учетную запись пользователя. Параметры которой только правильное ПО знать будет. Заморочено. Всегда сначала простые решения ищу.

БД при входе уже организует фиксацию (транзакцию) данных и поддерживает целостность системы - тем самым не давая рассыпается. Это все из одной коробки.
Управление данными из SQL.
Репликация на разные сервера.

попробуйте это все сделать через FTP

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

Sharfik писал(а):Я про то, что при работе с файлами напрямую не храня их в БД надо не давать всем кому попало доступ в папку их хранения.

О чём вы? Если о передаче файлов по сети, то при правильном устройстве программы никакой внешний пользователь вообще знать не может, где лежат файлы. Потому, что он получает поток байтов через сокет, а в файл он превращается снова только у клиента.

Снег Север писал(а):О чём вы? Если о передаче файлов по сети, то при правильном устройстве программы никакой внешний пользователь вообще знать не может, где лежат файлы. Потому, что он получает поток байтов через сокет, а в файл он превращается снова только у клиента.

вот об этом:

Снег Север писал(а):Если файлы больше 100 Мб, то действительно лучше хранить их отдельно, а в базе только ссылки. Если кто беспокоится за секретность, то никто не мешает хранить файлы архивированными с паролем и распаковывать только при передаче клиенту.

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

Sharfik, если использовать сетевые папки, а не серверную часть своей аппликации, то будет подобный геморрой с учеткой и вирусной паранойей. Это и называется "создать себе на пустом месте трудности и потом их героически преодолевать".

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