Каморка

[trn]Hranit' li kartinki v BD ili hranit' tol'ko ssylku na fajl s kartinkoj?

Kartinki hranyatsya v otdel'noj tablice k kotoroj obrashchajutsya ne ochen' chasto. To est', esli hranit' v BD, to vreda vrode nikakogo.
Predpolagaetsya chto budet[/trn] production DB and DB [trn]dlya izoщrennyh i izvraщennyh zaprosov, kotoraya ezhenochno kopiruetsya iz [/trn] production[trn]. Esli hranit' kartinki otdel'no, to nado organizovyvat' otdel'nuju proceduru kopirovaniya.

U kogo kakie mneniya?

I vdogonku. Mozhet kto znaet kak skormit' [/trn] BLOB to PostgreSQL? lo_import returns oid and I need bytea.

Thanks.

BLOB [trn]skormil. Pro hranenie kartinok v i vne BD poguglil. No hotelos' by uslyshat' lichnyj opyt.

"Zhal' chto nam tak i ne udalos' poslushat' nachal'nika transportnogo ceha."[/trn] (c)

StS писал(а):[trn]Hranit' li kartinki v BD ili hranit' tol'ko ssylku na fajl s kartinkoj?

Kartinki hranyatsya v otdel'noj tablice k kotoroj obrashchajutsya ne ochen' chasto. To est', esli hranit' v BD, to vreda vrode nikakogo.
Predpolagaetsya chto budet[/trn] production DB and DB [trn]dlya izoщrennyh i izvraщennyh zaprosov, kotoraya ezhenochno kopiruetsya iz [/trn] production[trn]. Esli hranit' kartinki otdel'no, to nado organizovyvat' otdel'nuju proceduru kopirovaniya.

U kogo kakie mneniya?

I vdogonku. Mozhet kto znaet kak skormit' [/trn] BLOB to PostgreSQL? lo_import returns oid and I need bytea.

Thanks.

Если нет проблем с размером базы данных, то я бы предпочел хранить данные в базе данных. Сталкивался с этой проблемой. Ничего страшного в том, что бы хранить картинки отдельно, нет. Но если логически картинки привязаны к данным, то естесвеннее будет хранить их в базе.

Gandalf писал(а):Но если логически картинки привязаны к данным, то естесвеннее будет хранить их в базе.

Меня тоже такой вопрос интересовал. Честно говоря, я так и не нашел серьезных плюсов в хранении их в базе. Фантазии наверное не хватило.
Для каких задач это может иметь смысл?

Мы делали метабазу (размещали на RDBM), а картинки (гелогические карты) (20-200 Mbt) - в виде сылок в таблицах этой ДБ. Проблема - многодельное серверное ПО. Ещё курочили проф. систему (метабазу), типа для корпоративной работы с документами (там и картинки, и текстовая инфа и прочая). Так вот там в базе хранились только ссылки. За всем следит там серверное ПО (имеется ввиду типа мидлваре).
Проблемы со сылками ясны. Если делается заведомо не очень могутная скалебл/флексыбл, то можно ограничится минимумом в серверной части и максимумом в клиентской. Быстро делается.
В противном случае надо делать могутное мидлваре. Это серьёзная задача.

ПС. сейчас всё (файлы размером 100 Kbt - 1 Mbt) храню в BLOB. Конечно, в этом случае минимум программирования на клиенте. Как бы почти обычное приложение БД. Минимум усилий... конечно. Работает ПО кстати шустро на _разных_ платформах (RDBMS). Это к вопросу о том, как засунуть BLOB.

CdR писал(а):

Gandalf писал(а):Но если логически картинки привязаны к данным, то естесвеннее будет хранить их в базе.

Меня тоже такой вопрос интересовал. Честно говоря, я так и не нашел серьезных плюсов в хранении их в базе. Фантазии наверное не хватило.
Для каких задач это может иметь смысл?

Плюсы очень простые - обычное приложение баз данных. Целостность данных, транзакции, .... гарантируется серверной часть (причём не дополнительного ПО, а RDBMS). Всё известно, прозрачно. Ребёнок может сделать. В принципе почти всю логику можно разместить на сервере. Клиент - супертонкий.

Если будешь хранить ссылки - неизбежно создание ПО, которое следит за всем этим хозяйством (не важно с каким акцентом - на клиента или своеобразное мидлваре).

CdR писал(а):

Gandalf писал(а):Но если логически картинки привязаны к данным, то естесвеннее будет хранить их в базе.

Меня тоже такой вопрос интересовал. Честно говоря, я так и не нашел серьезных плюсов в хранении их в базе. Фантазии наверное не хватило.
Для каких задач это может иметь смысл?

В последнем сообщении vg ответил Вам на этот вопрос.

Целостность данных, транзакции, .... гарантируется серверной часть

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

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

StS писал(а):[trn]Hranit' li kartinki v BD ili hranit' tol'ko ssylku na fajl s kartinkoj?

Kartinki hranyatsya v otdel'noj tablice k kotoroj obrashchajutsya ne ochen' chasto. To est', esli hranit' v BD, to vreda vrode nikakogo.
Predpolagaetsya chto budet[/trn] production DB and DB [trn]dlya izoщrennyh i izvraщennyh zaprosov, kotoraya ezhenochno kopiruetsya iz [/trn] production[trn]. Esli hranit' kartinki otdel'no, to nado organizovyvat' otdel'nuju proceduru kopirovaniya.

U kogo kakie mneniya?

I vdogonku. Mozhet kto znaet kak skormit' [/trn] BLOB to PostgreSQL? lo_import returns oid and I need bytea.

Thanks.

как я понимаю где хранить картинки вопрос из серии священных войн
Ничего плохого в хранении на сервере нет, только если необходима рапределенность или point-in-time-recovery то придется изобретать велосипед с rsync и какой-нить log-capable filesystem. К счастью база уже предоставляет это. Что до скорости то, на то и машинки что-бы данные молотить.

Касательно postgresql -
насколько я понимаю там есть два типа Blob-a
bytea - binary array хранится непосредственно со строкой и собственно
large object - в таблице хранится OID объекта который можно достать специальным API (C / java в родной доке описаны )

Если размер картинок разумен и не слишком много изменений строчек ( updates в postgresql достаточно дороги) то можно ограничится bytea тем более что поиск в LO и подобные fancy вещи для картинок вряд-ли нужны.

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

[trn]Figushki. Ya ne zrya skazal chto budet dve bazy. Esli kartinki otdel'no - otdel'nyj mehanizm kopirovaniya fajlov s prodakshn servera. Pljus otdel'naya golovnaya bol' s permishinami na fajly.

Vot chto escho nado bylo dobavit' - kartinki nebol'shie, poryadka 10K, apdejtyatsya redko (prakticheski nikogda - tol'ko vstavka i chtenie).[/trn]


bytea vs oid (large object).
[trn]Vopros byl ne o tom. Mne dlya testovyh celej nado bylo skormit' fajl, no pisat' programku dlya wtogo bylo len'. Okazyvaetsya mozhno wto sdelat' i cherez[/trn] SQL (using large object).

[trn]Da, zabyl dobavit'.
Minus hraneniya v BD v tom, chto schitaetsya chto[/trn] DB server is a bottleneck in a web application.[trn] Sootvetstvenno, chem men'she na nego nagruzka, tem luchshe.
Powtomu ne vse tak odnoznachno.
[/trn]

vg писал(а):

CdR писал(а):

Gandalf писал(а):Но если логически картинки привязаны к данным, то естесвеннее будет хранить их в базе.

Меня тоже такой вопрос интересовал. Честно говоря, я так и не нашел серьезных плюсов в хранении их в базе. Фантазии наверное не хватило.
Для каких задач это может иметь смысл?

Плюсы очень простые - обычное приложение баз данных. Целостность данных, транзакции, .... гарантируется серверной часть (причём не дополнительного ПО, а RDBMS). Всё известно, прозрачно. Ребёнок может сделать. В принципе почти всю логику можно разместить на сервере. Клиент - супертонкий.

Если будешь хранить ссылки - неизбежно создание ПО, которое следит за всем этим хозяйством (не важно с каким акцентом - на клиента или своеобразное мидлваре).

BLOB-ы с транзакциями-то не очень и работают. По-моему больше одной записи с блобом в "rollback segment" не положить (может быть специфично для типа базы данных)

не DBA

dima писал(а):

vg писал(а):

CdR писал(а):

Gandalf писал(а):Но если логически картинки привязаны к данным, то естесвеннее будет хранить их в базе.

Меня тоже такой вопрос интересовал. Честно говоря, я так и не нашел серьезных плюсов в хранении их в базе. Фантазии наверное не хватило.
Для каких задач это может иметь смысл?

Плюсы очень простые - обычное приложение баз данных. Целостность данных, транзакции, .... гарантируется серверной часть (причём не дополнительного ПО, а RDBMS). Всё известно, прозрачно. Ребёнок может сделать. В принципе почти всю логику можно разместить на сервере. Клиент - супертонкий.

Если будешь хранить ссылки - неизбежно создание ПО, которое следит за всем этим хозяйством (не важно с каким акцентом - на клиента или своеобразное мидлваре).

BLOB-ы с транзакциями-то не очень и работают. По-моему больше одной записи с блобом в "rollback segment" не положить (может быть специфично для типа базы данных)

не DBA

Ну всему есть предел, конечно ...
Ну, и потом ведь транзакция и её откат - это не аналог UNDO в редакторе Ворд.
Обычно, это откат UPDATE, INSERT, когда надо откатываться не к тому или иному значению поля BLOB (как бы UNDO в MS Word или в Paint Brush), а к групповым операциям, т.е. откак ведут по группам записей (AUTOCOMMIT OFF при этом по как эта групповуха длиться).

Кстати в этом нет никакой необходимости (откатывать редактирование любого поля, в том числе и BLOB). Например, смешно в приложении БД делать UNDO при поможи транзакций:

1) по тому, что это было бы ффффффзмом
2) по тому, что можно сделать, и обычно это делается по-другому.

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

раскажи нам а то у меня база с 200 тыс. картинок по 70 мег некоторые.
И как-то неплохо работает.

http://www.russianlook.com