🚀 go-pugleaf

In article <3b7e345f$1@news.bsi.net.pl>, "cauchy" 
<\\x//cuchy2k@o2.pl\\x//> wrote:

> $mysqlPicture = addslashes(fread(fopen
> ($Picture, "r"), $PSize));
> to moge zapisac rysunki w bazie ale tylko z kompa na ktorym chula serwer
> a gdy laduje z klienta wyskakuje error

Nie za bardzo rozumiem - jak to chcesz z klienta ladowac? Musisz 
najpierw przez formularz na serwer uploadnac chyba zdjecie, a potem za 
pomoca kilku funkcji przerzucic je z katalogu tymczasowego do bazy. Nie 
ma mozliwosci bezposredniego dostepu do plikow klienta z serwera, chyba 
ze ten sam tak zarzadzi przez formularz :). No chyba ze przez jakas 
dziure w przegladarce ;>

-- 
tomasz 'tonid' nidecki, zoliborz, warszawa, poland
mailto:tonid@tonid.net http://endemic.tonid.net
Volkswagen 1302 "Garbus" Automatic (1971) 
Cadillac Eldorado (1983) - CZEKA NA NOWEGO WLASCICIELA!

A jesteś pewny ,że serwer bazy zezwala na dostęp z zewnatrz, być nmoże masz
dostęp tylko przez localhost?

witam

dzieki za pomoc
jakie funkcjie sa odpowiedzialne
za pobieranie plikow z katalogu
tymczasowego

bo error jaki wyskakuje to odnosi sie do
pilkow tymczasowych

choc jeszcze popatrze co z tymi prawami
dostepu

serdeczne dzieki
pozdro

Witaj!

Trzymanie binariów w bazie to nie najlepszy pomysl. Wlasciwie to nie ma
zadnego racjonalnego powodu aby chciec pakowac binaria do bazy.

Czy nie lepiej trzymac w bazie nazwę pliku i jego typ?

Przykladowo, robisz systemik newsów z możliwocią dodania zdjęcia.
Zakladasz ze zdjęcia moga byc w formatach GIF, JPG, PNG  

1. tworzysz formularz w ktorym osoba uprawniona moze dodac newsa
- podaje tresc newsa, tytul itp.
- pole (FILE) umożliwiające dodanie zdjęcia.

2. tworzysz skrypt obrabiajacy dodawanie nowego newsa...
jesli zostal wyslany plik to:
- sprawdzasz jego typ mime, jesli nie pasuje do akceptowanego formatu to
to go kasujesz. [unlink()]
- pobierasz wielkosc obrazka
- dodajesz do bazy nowy rekord o przykladowej strukturze

id | tytul | tresc | typ_obrazka | szerokosc | wysokosc

jako typ_obrazka mozesz przyjac:
0 nie ma obrazka
1 GIF
2 JPG
3 PNG

- jesli format pliku ok to kopiujesz go do wybranego katalogu np. img
  nazwa pliku to numer_ostatniego_id a roszerzenie zależne od typu mime.


3. wyswietlanie newsa

Pobierasz rekord jesli typ_obrazka > 0 to tworzysz nastepujacy fragment
HTMLa np. 

<img src='img/$id.$roz_typ[$roz]' align=left width=$szerokosc 
	height=$wysokosc>

gdzie
$roz_typ = array ('', 'gif','jpg','png');



To tyle...

Stosowanie plików (zamiast bazy) jest szybsze, wygodniejsze w obsludze,
mozesz latwo podejrzec lub skasowac wybrane pliki.


Mała podpowiedz co do typów plików.

IE i NN różnią się w zwracaniu wartosci typu mime dla JPGów...
Róznica wynika dlatego ze NN nie rozróznia JPGów progresywnych od
normalnych.

Fragment kodu okreslającego rozszerzenie pliku na podstawie typu mime.


switch ($pict1_type) 
{
case "image/jpeg" :
	$roz = "jpg";
	break;

case "image/jpg" :
	$roz = "jpg";
	break;

case "image/pjpg" :
	$roz = "jpg";
	break;

case "image/pjpeg" :
	$roz = "jpg";
	break;

case "image/png":
	$roz = "png";
	break;

case "image/gif":
	$roz = "gif";
	break;
} 



Pozdrawiam Adam
I witam wszystkich na nowej grupie.

Popieram rozwiazanie Adama.

Rzeczywiscie tak napisana aplikacja jest znacznie szybsza, pewniejsza i
jednoczesnie nie obciaza za bardzo bazy danych.

MySQL przy duzych plikach wrzuconych do bazy binarnie (powyzej 100kB)
lekko juz 'zipie' jesli ktos mu da zapytanie by zwrocil np. 100 takich
obrazkow. Dodatkowo czas zapytania sie strasznie wydluza, nawet do 30
sek.

pozdrawiam

MACHINA

Witam 

Napisane przez Marcin Slominski <machina@otwarte.pl>  w pl.comp.lang.php
> Popieram rozwiazanie Adama.
.> Rzeczywiscie tak napisana aplikacja jest znacznie szybsza, pewniejsza i
> jednoczesnie nie obciaza za bardzo bazy danych. 
> MySQL przy duzych plikach wrzuconych do bazy binarnie (powyzej 100kB)
> lekko juz 'zipie' jesli ktos mu da zapytanie by zwrocil np. 100 takich
> obrazkow. Dodatkowo czas zapytania sie strasznie wydluza, nawet do 30
> sek.

Bo MySQL to nedzna baza. Moze i prosta w obsludze ale daleko jej do 
normalnego RDBMSa. Lepiej od razu przesiasc sie na Postgresa albo jesli 
bedzie sie chcialo dorabiac jakis interfejs klient-side to na IB.

Ale wracajac do tematu trzymania plikow w bazie. Pomimo wielu wad takiego 
rozwiazania (wzrost wielkosci bazy, spowolnienie zapytan (szczegolnie tych 
"select * from cos_tam" 8-) , jakis tam spadek wydajnosci) nalezy pamietac 
ze takie rozwiazanie ma jedna podstawowa zalete. Pliki nie maja tendencji 
do gubienia sie. Stawiam diamenty przeciwko orzechom ze takie rozwiazanie 
(pliki osobno, w bazie jakis namiar na nie) spowoduje to ze po jakims 
czasie bedzie mnostwo plikow nie majacych swojego rekordu w bazie. I ten 
wlasnie bajzel jest najwiekszym problemem.

Rozwiazania sa takie:
1. __Bardzo__ staranne napisanie skryptow, tak zeby przerwanie ich 
wykonania nie powodowalo powstawania smieci (ale i tak ryzyko powstawiania 
pogubionych plikow jest dosc spore).
2. Napisanie jakiegos privata, miejsca gdzie sie czasami wchodzi i 
przeprowadza globalne sprawdzenie czy to co w bazie rowna sie temu co na 
dysku.
3. Przejscie na inny RDBMS. Fajny wydaje sie PG (pomimo mojej milosci do IB 
8-) ). ZTCP trzyma on BLOBy na zewnatrz bazy i mozna od niego wyciagnac te 
pliki bez uzycia samego silnika. Hmmm. A i w IB mozna by cos takiego zrobic 
stosujac jakiegos sprytnego UDFa + SP.

-- 
Pozdrawiam 
	Michal "Misza" Sznajder
[  http://www.fxmedia.com.pl/ ]

Witaj!

> Pliki nie maja tendencji do gubienia sie. Stawiam diamenty przeciwko
> orzechom ze takie rozwiazanie (pliki osobno, w bazie jakis namiar na
> nie) spowoduje to ze po jakims czasie bedzie mnostwo plikow nie 
> majacych swojego rekordu w bazie. I ten wlasnie bajzel jest
> najwiekszym problemem.

Nie wiem o jakim bajzlu mowisz. Dobrze napisana aplikacja nie ma prawa
pozwolic na powstawanie jakichkolwiek "nie zwiazanych" plikow.

Najprosciej mozna to uzyskac nastepujaco:
1. nazwa pliku = id w bazie
	czyli mamy np.
	...
	id smallint unsigned not null auto_increment,
	pict_st tinyint unsigned,
	tekst text,
	...

i teraz jesli pict_st > 0 to znaczy ze jest plik a jego rozszezenie
zalezne jest od numeru pict_st 1 = GIF, 2 = JPG, 3 = PNG

2. wszystkie plik umieszczasz w wybranym katalogu np. img/
Jesli plikow ma byc sporo np. 2000 i wiecej to tworzysz podkatalogi np.
img/
	1/
	2/
	3/
i ladujesz np. po 500 (lub jak to woli 100 ;-) do podkatalogu


3. Przy kasowaniu rekordow
a) pobierasz do tablicy wartosc pict_st z rekordów ktore chcesz
skasowac.
b) kasujesz rekordy z bazy
c) w petli robisz kasowanie wszystkich plików z tablicy, ustalajac dla
	 kazdego indywidualnie rozszezenie pliku.


4. Przy edycji danego newsa (nawiazujac do poprzedniego przykladu)
a) dajesz pole do wybrania innego pliku oraz checkboxa do odznaczenia
(skasowania) obrazka z newsa.
b) jesli odznaczysz obrazek to wpisjesz pict_st = 0 oraz dajesz
  clearstatcache ();

c) jesli w edytowanym newsie zmieniasz obrazek to:
	- pobierasz stara wartosc pict_st
	- kasujesz stary obrazek jesli byl
	- clearstatcache ();
	- dalej postepujesz jak przy dodawaniu (oczywiscie zamiast
		 INSERT robisz UPDATE)


Reasumujac nic Ci sie nie moze zepsuc.


Pozdrawiam Adam.

Witam 

Napisane przez Adam Major <amajor@tenbit.pl>  w pl.comp.lang.php
> 
>> Pliki nie maja tendencji do gubienia sie. Stawiam diamenty przeciwko
>> orzechom ze takie rozwiazanie (pliki osobno, w bazie jakis namiar na
>> nie) spowoduje to ze po jakims czasie bedzie mnostwo plikow nie 
>> majacych swojego rekordu w bazie. I ten wlasnie bajzel jest
>> najwiekszym problemem.  
> Nie wiem o jakim bajzlu mowisz. Dobrze napisana aplikacja nie ma prawa
> pozwolic na powstawanie jakichkolwiek "nie zwiazanych" plikow.

Nie ma aplikacji doskonalych. Poza tym jestesmy w obrebie PHP gdzie nie 
mamy mozliwosci pelnej kontroli nad poczynaniami klienta.

> Najprosciej mozna to uzyskac nastepujaco:
.> 2. wszystkie plik umieszczasz w wybranym katalogu np. img/
> Jesli plikow ma byc sporo np. 2000 i wiecej to tworzysz podkatalogi np.
> img/

Nie wiem czy to ma jakis sens. Nalezy sprawdzic jak sobie radzi file-system 
z taka iloscia plikow w jednym katalogu. Chyba pare tysiakow powinien 
wyciagnac.

> 3. Przy kasowaniu rekordow
> a) pobierasz do tablicy wartosc pict_st z rekordów ktore chcesz
> skasowac.
> b) kasujesz rekordy z bazy
> c) w petli robisz kasowanie wszystkich plików z tablicy, ustalajac dla
>       kazdego indywidualnie rozszezenie pliku.

O i tu jest zagrozenie. A co sie stanie jesli skrypt przestanie dzialac po 
punkcie b ? W bazie nic juz nie bedzie a pliki pozostana ... 

> Reasumujac nic Ci sie nie moze zepsuc.

Tak samo Tytanik mil byc niezatapialny 8-). A prawa Murphy'iego pamietasz?

-- 
Pozdrawiam 
	Michal "Misza" Sznajder
[  http://www.fxmedia.com.pl/ ]

Witaj!

> Nie ma aplikacji doskonalych. Poza tym jestesmy w obrebie PHP gdzie 
> nie mamy mozliwosci pelnej kontroli nad poczynaniami klienta.
Wiekszosc poczynan mozna przewidziec. Zawsze mozna wspomoc sie
jakims automatem czyszczacym, odpalanym z crona.

> Nie wiem czy to ma jakis sens. Nalezy sprawdzic jak sobie radzi
> file-system  z taka iloscia plikow w jednym katalogu.
Jesli bedzie to *nix to bez problemu sobie poradzi... gorzej z
czlowiekiem, dzielenie na pokatalogi ma pomoc w ewentualnym
przegladaniu podkatalogow (via Shell, FTP lub SSH) przez osoby
uprawnione.

> O i tu jest zagrozenie.
Sorry moj blad... mialo byc odwrotnie, najpierw kasowanie plikow, a
pozniej danych z bazy.

> > Reasumujac nic Ci sie nie moze zepsuc.
> Tak samo Tytanik mil byc niezatapialny 8-).
;-))

> A prawa Murphy'iego pamietasz?
Tak.


Jednak nadal twierdze ze trzymanie plikow w bazie nie ma uzasadnienia
;-)

Pozdrawiam Adam.

>
> > A prawa Murphy'iego pamietasz?
> Tak.
 ja nie czy moglbym prosic o ich zacytowanie

>
> Jednak nadal twierdze ze trzymanie plikow w bazie nie ma uzasadnienia
>
 a jak to Ci nie przeszkadza to uwazam ze powinienes
otrzymac miano cyberSyzyf'a
poniewaz jak juz sie przekonalem
tzrymanie plikow w bazie jest calkiem
rozsadnym rozwiazaniem

pozdo