Starší komentáře ke článku: PHP a MS SQL - vkládání a načítání souborů
Zpět na článek | Úvodní stránka Interval.cz
Datum vložení: 18.3.2005 10:47:04
Otázka k diskuzi - jaké výhody má vkládání souborů do databáze místo vkládání samotné cesty k souboru (a uložení souboru v původní podobě do extra adresáře)? Osobně pokládám v článku prezentované řešení jako méně výhodné - při každém zobrazení souboru se zvedá zátěž databáze (která musí načíst třeba několik desítek kilo dat s obrázkem) a následně i PHP (musí z těch dat 'složit' opět obrázek). Navíc podstatně naroste i velikost databáze, takže je problematičtější a náročnější zálohování a podobně. Nicméně mě opravdu zajímá, jaké výhody prezentované řešení podle vás má a proč ho používáte. [i]Mám na mysli samozřejmě případ serveru s návštěvností tisíce stránek denně, u serveru s několika stovkami stránek to není problém.[/i]
Datum vložení: 18.3.2005 10:57:18
Ukládání souborů do databáze má, samozřejmě, řadu výhod i nevýhod. Podstatnou a velmi důležitou výhodou je snadná údržba a maximální zabezpečení konzistence dat - jsou-li soubory v databázi přímo, nikdo je nemůže oddělit od ostatních dat, nikdo jimi nemůže nezávisle manipulovat, neztratí se atd. Jako protiargument se často uvádí zvýšená technická náročnost takové architektury. Ze své zkušenosti mohu říci, že při správně zvoleném databázovém stroji a architektuře žádné zvýšené nároky nevznikají, spíše naopak, protože databázové stroje jsou špičkou v IT...
Datum vložení: 18.3.2005 11:27:51
K prvnímu odstavci - to je přece záležitost nadstavby, která tu databázi spravuje. A jestli ona nadstavba vloží obrázek do databáze nebo na správné místo serveru mi připadá stejné. Nevidím tady většího rozdílu mezi oběma metodami. Argument, že to nespomaluje systém protože jsou databázové servery většinou špičkový HW - tak to tedy neberu. To je výmluva druhu 'nemusím program optimalizovat, mám dostatečně výkonný stroj. Pokud by začal nestíhat, koupíme ještě lepší HW.' To podle mě není správný přístup k programování. Mimochodem - nejde mi psát reakce v Mozille. Dost často se ani nezobrazí formulář, pokud se už zobrazí tak po stisknutí Zobrazit náhled se náhled nezobrazí a znovu se načte prázdný formulář.
Datum vložení: 18.3.2005 11:47:36
Myslím, že tady nejde o to "koupím nový lepší rychlejší HW" a bude to lepší... Databáze opravdu patří ke špičce v IT. Jenže proto, aby Vám fungovala opravdu dobře ji musíte "vyladit", což není žádná legrace - zvláště v případě velkých databází. Dobře nakonfigurovaná a vylaďěná databáze je opravdu schopna - podle mého soudu - daleko lepších výsledků, než v případě mnoha situací samotný program. Z tohoto důvodu se často přesouvá část logiky nebo "pomocné práce s daty" právě na databázový stroj. Ale na druhou stranu připouštím, že se najde podobný počet protiargumentů (myšleno proti "databázi")...
Datum vložení: 18.3.2005 11:52:49
Ad nadstavba: Aplikační server (nebo podobná "nadstavba" se stejnými funkcemi) sice může zajistit, že veškeré operace jím prováděné budou konzistentní, nemůže ale data ochránit v případě, že se s nimi manipuluje mimo něj. A k takové manipulaci může dojít velmi snadno - stačí třeba jediná nevinná kontrolní procedura v databázi a je po konzistenci. Jakákoli data, která nejsou v databázi, jsou automaticky nedůvěryhodná. Ad zpomalování: Prosím, nepodsouvejte mi tak stupidní argumentaci. Já jsem pouze popíral protiargument poukázáním na technickou vyspělost současných databázových systémů, které s podobnými situacemi dopředu počítají a řeší je. Kupříkladu Oracle může být sám sobě operačním systémem, takže je jedno, vkládáte-li data do filesystému nebo databáze. Konec konců, i vývoj v oblasti filesystémů už léta směřuje k databázím... Mimochodem - psáno v Mozille ;-)
Datum vložení: 20.3.2005 8:51:23
Směřuje nesměřuje - pro veřejně přístupný mapový server, kde je možné si vyhledat místo na mapě a tuto část mapy poté zobrazit, by dnes ukládal data obrázků do databáze jen šílenec. Je potřeba dobře zvážit, kdy se hodí ukládat data souborů do databáze - tady žádné "vývoj směřuje..." nepomůže, protahovat data obrázků přes databázi je prostě pomalé a zavisí to na mnoha faktorech. Prohlásit teda, že "dnes směřuje něco někam" a tedy je dobré to v tomto duchu dělat je jednoznačně zavřením si cesty k další škálovatelnosti. To by ovšem ti co sledují trendy ale sami museli také něco řešit v praxi, takhle odtrženiod praxe se můžeme opájet teoriemi a trendy do sytosti a stejně se nakonec ukáže, že jde o zbožná přání.
Datum vložení: 20.3.2005 9:30:47
Je vidět, že vy sám jste od praxe odtržen, protože právě geografické informační systémy své soubory do databází ukládají. Samozřejmě, musí se to umět a musí se na to vybrat vhodná databáze. A co se týče toho směřování - současné databáze umí pracovat se soubory efektivněji, než běžné serverové filesystémy (viz Oracle), proto se filesystémy snaží kopírovat funkčnost od databází a nikoli naopak ;-)
Datum vložení: 20.3.2005 11:41:43
není sporu o tom, jak rychle je schopen filesystém nebo databáze pracovat s uloženými soubory - zkuste si ale představit, co vše je potřeba zajistit, abyste obsah dopravil ke klientovi. Nemyslíte si doufám, že prohlížeč klienta se bude připojovat k databázovému serveru, že? Obrázek ani není součástí vlastního HTML kódu odesílaného klientovi, musí následovat další request jen kvůli obrázku - no prostě teoretizování je pěkné, ale praxi a skutečné provedení vy jste nejspíš nedomyslel, stačí si projít pár blogů na vyvojar.cz.
Datum vložení: 20.3.2005 17:30:21
Obávám se, že nedomýšlíte vy a nejen, že pojímáte problematiku velice jednostranně, ale navíc pletete hrušky s ovocem. Celou dobu se zde mluví obecně o ukládání libovolných souborů do databází, nikoli o ukládání ilustrativní grafiky pro WWW stránky. Ilustrativní grafika pro WWW je specifická záležitost, pro kterou existují specifická řešení v podobě specializovaných serverů, optimalizovaných na tento typ úkolů (je-li takových vysokých výkonů třeba - většinou nikoli). Zde mluvíme o jiné situaci - o web-based aplikacích pracujících s datovými soubory, a ty mají úplně jiné parametry. Mimochodem, když už jsme u toho, vrátil bych se ke svému (ne)oblíbenému databázovému systému Oracle, ten totiž může být nejen sám sobě o operačním systémem, jak jsem se o tom zmínil výše, ale i tím http serverem. V Oracle lze vytvořit kompletní web od začátku až do konce. A znám i jednoho nejmenovaného fanatika, který takto v praxi provozuje firemní intranet ;-)
Datum vložení: 20.3.2005 18:38:41
ok, přesvědčil jste - je to o specializovaných serverech. Co se týká toho Oracle - viděl jsem to už několikrát, že to lze. Pak stačí, aby ve firmě někdo rozeslal hromadný mail s odkazem na takový Oracle webserver a v okamžiku, kdy takto hromadně na odkaz v mailu kliknou uživatelé intranetu, celý server jde do kytek :)
Datum vložení: 21.3.2005 12:12:25
Každá věc na světě se dá udělat přinejmenším dvěma způsoby - špatným a ještě horším. Když někdo neumí správně nastavit server, nepomůže mu ani entita vyššího řádu... ;-)
Datum vložení: 22.3.2005 18:09:34
Přesně, souhlasím, například uložení XML souboru s registrovaným XSD do Oracle s XML DB znamena ze soubor se "naoko" ulozi dokonce je pristupny na vzdalenem ulozisti v podobe file, ale ve skutecnosti se cele XML rozlozi do transakcnich tabulek ktere si oracle vytvori automaticky pri zaregistrovani xml schematu, opetovne ziskane XML se lisi maximalne v whitespaces. Fyzicky zadny soubor nikde na disku samozrejme neni. Ma to obrovskou vyhodu, k datum lze pristupovat bud klasickym transakcnim zpusobem a nebo treba pomoci XML path vyuziteho primo v SQL a PL/SQL dotazech. Pravda toto je pripad XML obrazky uz sou o necem jinem. Ale vezmeme priklad treba v systemech PACS, desetimilionove systemy udrzujici vizualni data z ruznych lekarskych analytickych pristroju at uz jde treba o scany CT, RTG, RDG ci sonografie... 100% tyto systemy nepracuji s fily na disku, za chvili by se ten filesystem sesypal. Obecne je nesmysl spravovat treba desetitisice souboru, zvlaste naflakanych v jednom adresari nez mit ty data pohromade v dtb. Take mnoho velkych serveru vyuzivaji zvlast IMG servery, prikladem mohou byt urcite nektere reklamni servery, kde aplikace bezi na jednom stroji a IMG/SWF se nacitaji z jineho stroje kde bezi databaze a "plive" bannery.
Datum vložení: 26.3.2005 21:47:31
>současné databáze umí pracovat se soubory efektivněji, než běžné serverové filesystémy (viz Oracle), kdyz uz tak: SOUCASNA databaze Oracle. Pane Malek zastavate se nejakeho reseni, cpani souboru do DB a pak z vas vyleze ze efektivni je to jenom u Oracle... hmm... no clanek by mel byt radeji o DB Oracle a jeho vyhodach ohledne ulozeni souboru do DB, a ne tady bulikovat lidem ze kdyz budou cpat soubory do DB tak to bude efektivnejsi, kdyz u vsech ostatnich databazovych stroju mimo Oracle je to holy NESMYSL!!!
Datum vložení: 27.3.2005 3:13:18
Kdybyste si přečetl celou diskusi, zjistil byste, že poukazuji na Oracle jako na špičkový příklad jinak běžné vlastnosti všech moderních databází, včetně třeba takové MySQL ;-)
Datum vložení: 18.3.2005 11:03:28
Dobrý den, stejné argumenty, jaké jste vypsal nás původně v naší aplikaci vedli k tomu, že soubory (přílohy u požadavků), byly ukládány zvlášť v adresáři. Výsledkem bylo, že nastala potřeba mít 2 instance apliakce, kdy obě instance používají stejná data => což mělo důsledek ten, že se prostě v jedné instanci přílohy zakázali, protože to bylo jednodušší. Kdyby byly přílohy v databázi, vše by bylo přístupné u obou instancí. Další nevýhodou "adresářového řešení" byla zvýšená administrace aplikace (nastavení práv zápisu v adresářích, "laborace s adresáři"...) - což mělo jako důsledek to, že u u každého 2 zákazníka jsme museli laborovat "s přílohama". V případě databázového řešení je výsledek (alespoň pro nás) mnohem efektivnější. Mnou popsané řešení nám ulehčilo spoustu problémů (snížilo chybovost). Zvýšená zátěž databáze se doposud nijak neprojevila. Např. Sharepointal využívá stejný princip - námi používaná databáze má 2 GB a opravdu nemohu říct, že by to stroj nezvládal. Navíc je velmi snadné v případě databázového řešení k jednotlivým souborům přidat další atributy, např. popis. Doufám, že jsem Vám odpověděl.
Datum vložení: 18.3.2005 15:53:09
Protoze rychlost, konzistence a administrace. Resil jsem problem uloziste emailu (jak ulozit cca 1000000 souboru o delce 2KB - 2MB (prumer 40KB) - zkusil jsem si udelat testovaci databazi i filesystem a napsal jsem si benchmark script ktery rychle pristupoval k nahodnym souborum a zjistil jsem, ze v prumeru je databazove reseni rychlejsi (mysql, BLOB). Ono statisice souboru pro filesystem neni zrovna med, musite soubory delit chytre po skupinach do adresaru, chytre vymyslet jmena souboru atd....vopruz S databazi je to v pohode - indexy to udelaj za vas.
Datum vložení: 18.3.2005 16:15:48
No soubory do databáze jsou dnes skoro nutností: 1. plno hostingů vám ani nedovolí zápis na disk 2. rozdíly v rychlosti jsou zanedbatelné (možná u webu, kde máte 100 000 stáhnutí velkých souborů to trochu poznáte) 3. GIS aplikace mají v DB všechny rastry, což jsou desítky GB obrazových souborů a jedou svižně i při velké zátěži, prostě v db je to lepší, ale je s tím o trochu více práce...
Datum vložení: 20.3.2005 22:23:39
"1. plno hostingů vám ani nedovolí zápis na disk" Podobne jsou ale webhostingy omezene pameti, ktera je k dispozici PHP skriptu, a pri beznem limitu 8MB se zaloha databaze kde mate takove velke veci dela dost tezko. A jiny pristup nez pres PHP skript vam tezko dovoli tam, kde nedovoli pracovat se soubory, Leo
Datum vložení: 22.3.2005 18:12:50
Nikdo vás nenutí tam hostovat, vždy je možná volba dedikovaného serveru. Vždy je možné požádat webhostera o vytvoření zálohy, btw každý slušný webhoster, včetně mě ;) dává do ftp prostoru možnost stažení sql dumpů databáze za několik posledních dní...
Datum vložení: 21.3.2005 11:41:22
Zalezi od toho co sa v projekte vyzaduje. Ak mam subor na disku a v db mam len meta informacie potom k tomuto suboru moze priamo pristupovat web server (subor musi byt vo web roote). Nevyhodou je problem s integritou (zmazanie suboru z disku, nezmazanie meta informacii, ...) Ked je subor v db vacsinou nie je pristupmy z web serveru (*) co moze byt riesenie pre uskladnenie suborov ku ktorym chceme riadit pristup, ... Kazde riesenie ma svoje za a proti a podla poziadaviek vybrat to najlepsie. (*) su db ktore maju so sebou aj web server
Datum vložení: 18.3.2005 11:23:10
Měl bych jednu připomínku k teoretickému úvodu článku, BLOB je jak jste napsal [b]Binary[/b] LOB a proto datové typy [i]text[/i] a [i]ntext[/i] nejsou BLOBy, jsou to buďto obecne LOBy a nebo se pro ně používá označení CLOB, tj. [b]Character[/b] LOB. Právě takto je má pojmenovány např. databázový server Oracle. Tedy v teoretickém úvodu by bylo vhodné změnit výskyty BLOB za obecný LOB.
Datum vložení: 18.3.2005 11:41:44
Přiznám se, že jsem vycházel z dokumentace k MS SQL. Je tedy možné, že Oracle používá jinou terminologii. V literatuře (od Microsoftu pro Microsoft :-) ) pod označenám BLOB najdete všechny 3 datové typy. A jelikož je dané řešení právě nad Microsoftí databází, použil jsem i microsoftí terminologii. (Pojem CLOB např. v této terminologii není) Jestli to je správně či nikoli nechci příliš polemizovat. Prostě tomu tak (bohužel?) je...
Datum vložení: 18.3.2005 11:51:01
Také přiznávám, nadpis byl jako "MSSQL - trocha teorie", jen jsem chtěl upřesnit danou terminologii, každopadně označením CLOB a BLOB je zřejmé pro co je vhodné, ten který datový typ použít. Pokud by mi někdo tvrdil že bude chtít uložit text (a následně třeba fulltextově v databázi indexovat) do BLOBu, tak bych se na něho díval asi trochu divně, i když asi ne moc dlouho, protože MS terminologii používá hodně lidí a už jsem se s tím setkal.
Datum vložení: 18.3.2005 11:56:00
Nejenom Microsoft používá termín BLOB uvedeným způsobem. V praxi je to spíše naopak - většinou se používá BLOB, protože z hlediska databáze je jeho obsah irelevantní ;-)
Datum vložení: 18.3.2005 14:04:54
Já vím, proč nepoužívám MS SQL. Např. v MySQL by se na toto téma článek asi napsat nedal: Vytvoření tabulky: CREATE TABLE soubory (id int not null auto_increment, data blob, primary key (id)); <?php // uložení souboru mysql_query("INSERT INTO soubory (data) VALUES ('" . addslashes(file_get_contents( $_FILES["userfile"][ "tmp_name"])) . "')"); // vypsání souboru echo mysql_result(mysql_query("SELECT data FROM soubory WHERE id = '$_GET[id]'"), 0); ?> Žádné uložené procedury ani složité procházení 512B bloků dat. Na druhou stranu chápu, že v MS SQL je to daleko více vzrušující a dá se o tom napsat článek :-).
Datum vložení: 18.3.2005 14:15:51
Ano, bohužel je to tak - co se týká jednoduchosti práce s BLOB u MySQL. Přestože poslední verze MySQL umí už opravdu dost, je přeci jen MS SQL server u mnoha věcí daleko dál. I když práce s BLOB objektama je u něj daleko složitější. Článek jsem napsal proto, že jsem prostě potřeboval dané řešení rozchodit. I hledal jsem na internetu a jediné co jsem našel bylo právě PHP vs MySQL nebo ASP vs MS SQL... nikde ani náznak, jak to napsat pro PHP vs MS SQL... Dal jsem si tedy tu práci a řešení našel... A protože to není jendoduché, tak si myslím, že stojí za to, jej ukázat ostatním... Ostatně strávil jsem na hledání řešení cca týden...
Datum vložení: 21.3.2005 16:38:59
Já článek nezatracuji. Kdybych používal MS SQL spolu s PHP, nejspíš bych za něj byl vděčný. Jen jsem si posteskl nad tím, jak jdou jednoduché věci dělat složitě.
Datum vložení: 18.3.2005 15:04:09
Musim rici, ze ani terminologie MySQL se mi prilis nezamlouva. Schovat CLOB za podstatne mene vystizne oznaceni TEXT mi pripada dost nestastne.
Datum vložení: 18.3.2005 16:44:50
no ani v mysql se nevyhnete streamovani blobu. Prece jenom soubor vetsi nez 10 MB pres mysql neprocpete naraz ani omylem....ale i tak je to jednodusi nez prace na mssql
Datum vložení: 27.3.2005 12:12:48
mohu otravoval s dotazem? zkousim ukladat do blob obrazky (php,mysql,apache na winech), ale neulozi se mi vic nez 200-300B a ne a ne najit to omezeni
Datum vložení: 1.4.2005 14:17:47
Zkuste se podívat, zda nemáte omezení na straně php (v php.ini musíte myslím upload povolit a hlavně se zde nastavuje jeho max. velikost... standartně je toto nastaveno na 2MB) Apache neznám do všech detailů, ale nemohl by i on mít ve svém configuračním souboru nějaké omezení tohoto druhu?
Datum vložení: 18.3.2005 16:47:41
Přeci jen jsem je mi jedna věc divná, už tři roky pracuji s MSSQL 2000 a hrnu do něj soubory od kB do desítek MB pomocí PHP standardním způsobem jako do MySQL a jede mi to naprosto shodně, takže taky na dvou řádcích INSERTnu binární data i s ošetřením a čtení je stejně triviální, tak trochu netuším proč takové komplikace. Pravda hack s "0x" taky občas používám. :-)
Datum vložení: 18.3.2005 17:25:36
No nevím... na začátku jsem to zkoušel tak, jako u MySQL, ale nepochodil jsem... Při čtení dokumentace jsem zjistil, že lze pro práci s BLOB používat pouze speciální funkce => proto jsem se vydal touto cestou. Ostatně podobná cesta byla použita i u řešení ASP/MS SQL - alespoň co se týká čtení dat ze serveru. Nemáte náhodou nainstalovaný service pack 3 na MS SQL? Ten totiž docela významě mění některé vlastnosti serveru.
Datum vložení: 30.3.2005 8:35:28
Mám i nemám nainstalovaný SP, na některém serveru je (v DMZ) na některém ne. Ale musím přiznat, že problém možná bude někde jinde, protože, když tahám obrázky pomocí PHP a nativních funkcí mssql_query, tak vrací celý obrázek, ale pomocí ASP na stejném stroji vrací jen těch 512b... budu laborovat :o)
Datum vložení: 18.3.2005 17:32:12
Jenom dolpnění(napsal jsem to v předchozím příspěvku trochu nejasně): toto řešení mám odzkoušeno právě na SP3 u MSSQL
Datum vložení: 20.3.2005 21:33:47
Rád bych upozornil na související článek na Intervalu: Práce s obrázky v databázi MySQL http://interval.cz/clanek.asp?article=1590 (To je zároveň výzva pro Viléma, aby to propojil ;-)
Datum vložení: 22.6.2005 16:15:22
Dobrej a hodně užitečnej článeček. Zrovna jsem tenhle problém potřeboval vyřešil a díky tomuto článku jsem ušetřil spoustu času hledáním nějakého řešení - takže díky!!! Udělal jsem to přesně tak jak popisuje autor a nezkoušel jsem hledat nějaké jiné řešení - on tomu času určitě věnoval dost a dost a proto mu věřím. A funguje to! To je hlavní. Takže ještě jednou dík
Datum vložení: 3.10.2006 15:20:41
Dobry den, rad bych pouzil vas algoritmus, ale po spusteni zahlasi SQL2005 tuto chybu: Invalid object name 'HC_PRILOHA'. Hlasi ji pri uploadoani souboru do DB. Predem dekuji za radu.
Datum vložení: 4.10.2006 18:48:03
V textu je evidentně chyba (Jak to, že jsem na ní nepřišel?). Za to se omlouvám. HC_PRILOHA je název datové tabulky. Správně by to měla být tabulka SOUBORY. Správně by tam mělo být - v proceduře ULOZ_SOUBOR: Na místo writetext HC_PRILOHA.DATA @id @file_data Toto writetext SOUBORY.DATA @id @file_data - v PHP souboru by mělo být Na místo $sql2="set textsize 512 READTEXT HC_PRILOHA.DATA 0x".$textptr." $chunkindex ".($chunksize-$p).""; Toto: $sql2="set textsize 512 READTEXT SOUBORY.DATA 0x".$textptr." $chunkindex ".($chunksize-$p).""; Snad Vám to pomůže.
Datum vložení: 28.11.2006 13:56:47
pče dělám s MS SQL poprvé v životě, měl jsem s tímto textem dost problémy. Mé poznatky: 1) chyběl mi tu vůbec popis připojení k databázi. String uloz_soubor (odbc_connect("uloz_soubor"); ) nikde není definovaný (nebo jsem si nevšiml?) 2) "id" v dotazech je malým, v SQL příkazu pro vytvoření tabulky velkým -> chyba 3) proměnná $soubory neexistuje, má tam být $soubor 4) zmíněná HC_PRILOHA má být SOUBORY 5) v dotazu pro vložení dat do DB chybí nakonci proměnná $popis (procedura v SQL jí vyžaduje) takže: $query="ULOZ_SOUBOR '".$_FILES["userfile"][name]."',".$_FILES["userfile"][size].", '".$data."','".$_FILES["userfile"][type]."','".$popis."'"; 6) no a výsledek je takovej, že jsem se sice dost naučil, ale stejně mi to nefunguje :o/ ... data se uploadují, ale po zpětném stažení to nejsou ony, že by problém se skládáním bloků ?
Datum vložení: 28.11.2006 18:30:34
Ahoj, na něterý chybky jsem již upozornil v poředchozích diskuzích. Ještě jednou se za ně omlouvám. Co se týká velikosti textu, u MSSQL (tak jak jej mám nakonfigurovaný, to je jedno) Napiš mi na mejla (pspaleny (zavináč) gmail tečka com), pokud ten zdroják ještě najdu, pošlu ti ho tak, jak jsme jej pak používali. Snad ti to pomůže. Problém opravdu vypadá v poskládání. Pro test doporučuju uložit nějaký texťák s menším obsahem - lze pak snadno na textu vidět, kde je problém.
Datum vložení: 29.11.2006 9:48:26
už mi to šlape, svou laickostí jsem přehlédl způsob, jakým předává downloadovací script data uživateli a prásknul jsem tam HTML hlavičku, ještě před celý php kód a samozřejmě, že on jí potom hodil na začátek každého souboru. Texťák vše odhalil, já předtím zkoušel HTML soubor a ten se zobrazil korektně, bodejď by ne, s HTML hlavičkou :o) Díky za pomoc