Display image frоm DB optimization

Чудя се за следното нещо...
Имам картинки записани в база данни (blob поле). В момента те се дисплейват чрез PHP което вади blob-a от базата данни и пуска съответния хедър. Сещате се че на страница с 60 такива картинки сървъра се замисля.... заради многото заявки....
Мисля си дали няма да е по-добре, ако пусна една заявка и вкарам резултата от нея в една сесия... после файла, който показва единичната картинка ще чете от сесията вместо от MySQL-a....
Hm, какво мислите вие... как ще е по-добре - със сесия или с много заявки? Знам че най добрия вариант е да пазя картинките като файлове, но засега не мисля да пренаписвам 3 тона код, така че това не е решение...
Интересно ми е какво ще кажат тези, които са се сблъсквали с подобен проблем....

i kak misli6 4e 6te reagira sesiata ako se opita6 da i zapi6e6 promenlivi s golemina : 60 * 15K = 1 Mb ? dali niama da se poobozi ?

E tuk ni6to niama :[линк]

ами аз в настоящия момент мога само ехидно да се надсмея над всички, които тука усилено защитаваха идеята картинки да се пазят в БЛОБ в базата данни, вместо да се съхраняват на файловата система, а в базата само пътищата до тях.
Нямам идея какво можеш да направиш, дано някой ти помогне. Но за друг път мисли повече като създаваш базите, много често бързането при "фасулската работа по ДБ-то" в началото осира иначе добри кодери

--
The#Project - лайфстайл списание в мрежата

ами точно това е въпроса... обаче картинките са по-малки....

abe voyager, kato navremeto ne si mogyl da si napravish bazata kakvo hapesh i pliuesh jupel sega?

imash image gallery i ti triabva byrz dotyp do title i description na image-a.
seshtash se veche koe e po-dobroto reshenie, nali?

slabata strana na metoda s db e kogato hosta koito runva sql servera e
razlichen ot toia na httpd-to - > traffic load.

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

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

--
The#Project - лайфстайл списание в мрежата

a kakvi li drugi problemi si otkril? moje bi triabva da pitash specialistite predi da mi kajesh? take your time..

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

Моя грешка, извинявай наистина, не знам що си реших, че ти си я правил (имах спомени че ти беше от защитниците на този вариант, когато се спореше преди време, но явно съм сгрешил )

Това обаче не променя нито мнението ми, нито факта, че не мога да ти помогна

--
The#Project - лайфстайл списание в мрежата

Набутването на картинки в база данни води до:
- фрагментиране на базата данни, предизвикано от големия обем на БЛОБ-а, което води до нужда от чести оптимизации
- допълнително натоварване на базата при заявка + допълнително натоварване на парсващия модул (в случая ПХП), който трябва да прочете файла и да го изпрати (иначе прочитането се пропуска)
- Типът БЛОБ е нефиксиран, което означава да се простиш с идеите за таблица от изцяло фиксирани типове.


Тези са без да питам специалистите, ако искаш разходи се до клуб бази данни, там ще ти обяснят по-компетентно.

--
The#Project - лайфстайл списание в мрежата

В самата сесия - не, но можеш да си правиш temp файлове, свързани със сесията. Проблемът е, че не знам кой ще се грижи да ги трие след това тези файлове.

Така че май остава вариантът с пренаписването на 3 тона код.

Напиши си скрипт, който да изплюе всички картинки и да alter-не таблицата. След това ти остава да промениш всички места, където изплюваш файл на изхода.

Аа, грешиш, никога не съм писал по тази тема. Освен не съм поддръжник на записването на картинките в базата, а на файловия метод... Поне моите си неща така съм ги правил досега..
Работата е там, че сега ми се налага да оптимизирам една боза, която по принцип работи, ама да не ти казвам как...

И аз колкото повече мисля, толкова повече се убеждавам че със сесията ще стане още по-голяма боза...
Но идеята със създаването на файлове не е лоша.... ще видим как точно да я доразвия...

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

--
The#Project - лайфстайл списание в мрежата

Male tolkva gluposti prochetoh..che se otkazah s po-natatyshnoto chetene...
Kato cqlo nikoi normalen ne pazi v "BLOB" samite kartinki..prosto zashtoto e ujasno neefektivno... ako imash nuvda ot obrabotka na dannite,naprimer imena, related info ili kakvo to i da e, OK..polzvai DB... no vmesto binary danni da pazish v BLOB zapazi v edna kolona samo pylniqt pyt do kartinkata... kato v edna direktoriq (mojesh da polzvash mnogo pod-direktorii) mojesh efektivno da postavish do 10000 kartinki..kato sled tova moje bi reshenieto s BLOB e po-dobro :-), no osnovnoto pravilo edna DB da se podyrja efektivna e tq da byde vyzmojno nai-malka :-)

Браво бе пич! Ти направо топлата вода откри! Освен това увеличи постовете които нищо ново не казват с още един...
Личи си че освен даването на мнения и четенето им не ти се удава... въпроса не е дали картинките да се пазят в блоб и как правят нормалните хора, а след като вече някой е направил това, какво може да се направи по въпроса.
Още по-малко съм се интересувал от съветите ти за основните правила при DB.
Колкото до метода с пазенето на информация за пътя към картинката в базата данни и аз го харесвам. Но не го правя така левашки, както ти го описваш. Излишно е да се пази пълния път към файла, обикновено правя имената на картинките да са обвързани с id-то на записа с който кореспондират. Това го правя за да бъде базата данни възможно най малка. Впрочем ти нали знаеш.

Vmesto da se syrdish..i da ne dovolsvash ot opita na horata da ti pomognat, po-dobre se zamisli dali da ne napravish edin prostichak cache.. naprimer syzdavash stranicata (ili samo chasta koqto e svyrzana s kartinkite...) q zapisvash vyv file i sled tova q vryshtash na posetitelq... vseki sledvasht koito gleda tazi stranica..nqma da ima nujda i 1 zaqvka da napravi kym MySQL... cache-a shte e validen naprimer dokato syotvetnata kategoriq ne se obnovi... dori tozi process moje da e interactiven (Ako ima konzolno Php to polzvai crontab...za da generirash html stranicite prez opredelen period ot vreme, taka edinstvenata promqna shte e da proverqvash dali ima nalichen cache za dadenata stranica.. ili trqba da q generirash)

Nadqvam se che sega si malko po-dovolen? A shto se otnasq do poznaniqta mi ne se pritesnqvai za tqh... moga da ti dam i drugi idei ama se symnqvam che shte mojesh da gi realizirash

Е, това е друга работа вече
При мен проблема идва основно от големия брой картинки, които се викат от отделен файл. Да им направя кеш е все едно да ги запиша като файлове, което общо взето се каня да направя... и без това се налага да направя малко промени по сриптовете за запис на картинките, така че...
Мерси за мнението, още веднъж. Любопитно ми стана относно другите идеи - нищо че може и да не стигна до тях