Cześć !
Lazarus + ZEOS-y _ Firebird.
W jaki sposób mogę (jeżeli oczywiście jest to możliwe) pobrać BEZPOŚREDNIO z TImage załadowaną grafikę
i zapisać ją następnie do BLOB-a w bazie danych ?
W/w grafika wcześniej była załadowana również z BLOB-a bazy danych i posiada różne formaty (*.jpg, *.png ...).
0
1
Tomek Pycia napisał(a):
Do jakiejś konkretnej bazy?
A to ma jakieś znacznie?
Nie ma.
jurkowojc napisał(a):
Cześć !
Lazarus + ZEOS-y _ Firebird.
W jaki sposób mogę (jeżeli oczywiście jest to możliwe) pobrać BEZPOŚREDNIO z TImage załadowaną grafikę
TImage.Image.SaveToStream itd.
i zapisać ją następnie do BLOB-a w bazie danych ?
Zapisujesz strumień do pola BLOB.
W/w grafika wcześniej była załadowana również z BLOB-a bazy danych i posiada różne formaty (*.jpg, *.png ...).
No to wszystko masz w kodzie, musisz zrobić tylko odwrotnie ;-)
0
Akurat wczoraj miałem otwarte kilka zakładek na ten temat bo też rozważam zapis grafik do bazy i to też do firebirda, jedyna różnica (lub nie) że ja to mam zamiar zrobić za pomocą firedac-ka. Jednak cały czas się gryzę czy to robić czy jednak zapisywać grafiki na dysku a w bazie tylko link.
Tak więc chętnie zaznaczam obserwowanie wątku i czekam na dalsze posty.
0
Ja bym uważał na bloby w Firebirdzie. Najlepiej zrób sobie tabelkę, która będzie trzymała adres repo oraz tabelkę plików gdzie będzie klucz na repo + ścieżka względna i zapisuj na dysku. Może to powodować problemy ze spójnością, ale baza będzie zdrowsza. Można tez wynieść część z blobami obrazków do osobnej bazy.
0
robertz68 napisał(a):
Akurat wczoraj miałem otwarte kilka zakładek na ten temat bo też rozważam zapis grafik do bazy i to też do firebirda, jedyna różnica (lub nie) że ja to mam zamiar zrobić za pomocą firedac-ka.
Nie ma znaczenia :)
Jednak cały czas się gryzę czy to robić czy jednak zapisywać grafiki na dysku a w bazie tylko link.
Tak więc chętnie zaznaczam obserwowanie wątku i czekam na dalsze posty.
Aplikacja desktop, czy tylko serwer aplikacyjny?
Jeśli desktop będzie sięgał do bazy po grafiki, to zapisuj je w bazie danych i tyle.
Podejście z zapisem linków jest/było popularne wśród "chłopców od PHP" czyli w webie :D, ponieważ u nich proces zapisujący/czytający dane z bazy danych zazwyczaj był na tej samej maszynie.
Po drugie, w www czas dostępu do takich plików może być krytyczny. A dostęp do pliku będzie zawsze sziszy od pobrania tego z bazy danych.
Tylko, że w aplikacji desktop te ograniczenia nie mają znaczenia.
No i odwrotnie - w aplikacji desktop dostęp do plików na serwerze jest utrudniony i może być upierdliwy.
Jeszce inaczej będzie to wyglądało, jeśli dostęp do danych będzie zapewniał serwer aplikacyjny.
Wtedy założenia również się zmieniają i można powalczyć z plikami na dysku.
Ale osobiście robiłbym to tylko i wyłącznie wtedy, kiedy ma to sens - a sens ma tylko wtedy, kiedy żądań do takich zasobów będzie niemało.
A niemało, to powiedzmy dziesiątki na sekundę.
1
somedev napisał(a):
Ja bym uważał na bloby w Firebirdzie.
Niby dlaczego?
http://www.firebirdfaq.org/faq277/
Najlepiej zrób sobie tabelkę, która będzie trzymała adres repo oraz tabelkę plików gdzie będzie klucz na repo + ścieżka względna i zapisuj na dysku. Może to powodować problemy ze spójnością, ale baza będzie zdrowsza.
To jest jakiś mit, powtarzany od lat przez ludzi, którzy opierają swoją wiedzę na jakiś plotkach.
Można tez wynieść część z blobami obrazków do osobnej bazy.
Sorry, ale to kolejny genialny pomysł, który tak naprawdę niczego dobrego nie wnosi, poza komplikacją.
Dlaczego tak twierdzę?
Bo znam dwa projekty, które tak właśnie realizowały dostęp do plików (ścieżka do dysku oraz dedykowana baza danych).
I nie przyniosło to żadnej korzyści, poza komplikacją oraz z definicji brakiem spójności.
Zdecydowanie nie polecam, jeśli to nie jest absolutnie konieczne.
2
Ja od lat wkładam skany do baz i nie ma z tym problemów (MSSQL). Zalety to przede wszystkim to, że nie trzeba pilnować powiązań rekordów z plikami na dyskach i bawić się uprawnieniami do tych plików. Poza tym dodatkowa zaleta to prostota wykonywania kopii zapasowych i przenoszenia aplikacji na inne serwery (wystarczy backup i restore bazy).
I jeszcze jedna sprawa, której nie widać przy małych bazach. Administruję bazą w której są setki tysięcy skanów i po prostu trzymanie takiej ilości osobnych plików na dyskach jest kłopotliwe.
0
cw napisał(a):
Ja od lat wkładam skany do baz i nie ma z tym problemów (MSSQL). Zalety to przede wszystkim to, że nie trzeba pilnować powiązań rekordów z plikami na dyskach i bawić się uprawnieniami do tych plików. Poza tym dodatkowa zaleta to prostota wykonywania kopii zapasowych i przenoszenia aplikacji na inne serwery (wystarczy backup i restore bazy).
Tak, tylko MSSQL to jednak nie Firebird.
Ale ponad wszystko w MSSQL do takich celów powinien być używany FileStream, bo do tego właśnie jest i działa od wersji Express w górę.
O samym FileStream było niedawno na forum...
0
wloochacz napisał(a):
Jeśli desktop będzie sięgał do bazy po grafiki, to zapisuj je w bazie danych i tyle.
Właśnie na odpowiedź od Ciebie czekałem i oczywiście że mnie przekonałeś.
1
wloochacz napisał(a):
somedev napisał(a):
Ja bym uważał na bloby w Firebirdzie.
Niby dlaczego?
http://www.firebirdfaq.org/faq277/
Ta, wiem - oni generalnie zawsze chwalą ten silnik.
Niemniej to moje doświadczenie. Baza z duża ilością blobow puchnie. Powoduje to utrudnienie podczas backupy i replikacji. Można omijać cześć tabel ale to tez dodatkowa komplikacja. Dodatkowo zauważyłem ze tabele z blobami często ulegają uszkodzeniu indeksów. Teoretycznie nie ma to nic do rzeczy ale napatrzyłem się na leżące bazy które padały po wprowadzeniu blobow. Przynajmniej do FB 2.5.3 nie ufam blobom na tyle by składować ich duże ilości w obawie o pad bazy. Nie są to plotki i mity a po prostu wieloletnie obserwacje.
Najlepiej zrób sobie tabelkę, która będzie trzymała adres repo oraz tabelkę plików gdzie będzie klucz na repo + ścieżka względna i zapisuj na dysku. Może to powodować problemy ze spójnością, ale baza będzie zdrowsza.
To jest jakiś mit, powtarzany od lat przez ludzi, którzy opierają swoją wiedzę na jakiś plotkach.
Można tez wynieść część z blobami obrazków do osobnej bazy.
Sorry, ale to kolejny genialny pomysł, który tak naprawdę niczego dobrego nie wnosi, poza komplikacją.
No widzisz nie trzymanie blobow w biznesowej bazie wynika z tego ze spotykałem się z padami takich baz. Trzymanie ich na dysku to tez inna odmiana separacji blobow od bazy biznesowej. Masz racje powoduje to komplikacje aczkolwiek przy założeniu, że bloby lub sposób jak się ich używa powoduje uszkodzenie bazy jest to sensowny środek ostrożności. Nie bez przyczyny rekomenduje taka komplikacje - a może masz jakiś sprawdzony magiczny konfig na którym bazy które maja terabajty danych biznesowych także obsługują dodatkowe gigabajty blobow? Chętnie dowiem się czegoś więcej o FB. Wiem - baza powinna być odchudzona i zagregowana osobna hurtownia ale życie i projekty są jakie są.
Co do komplikacji - rozwiązanie z osobna baza nie jest złe jak masz jakaś warstwę w której możesz przekazać akronimem gdzie się odwoływać, do jakiej bazy, a sam FB obsługuje zapytania on external i to fajnie działa.
Dlaczego tak twierdzę?
Bo znam dwa projekty, które tak właśnie realizowały dostęp do plików (ścieżka do dysku oraz dedykowana baza danych).
I nie przyniosło to żadnej korzyści, poza komplikacją oraz z definicji brakiem spójności.
No widzisz masz dobre doświadczenia a ja złe. Projekty które widziałem i brałem udział po rezygnacji z blobow na głównej bazie na rzecz osobnej lub repo plikowego zyskały mniejsza awaryjność bazy i mniej przestojów na odtwarzanie bazy i danych.
Zdecydowanie nie polecam, jeśli to nie jest absolutnie konieczne.
Przyznam, ze jeśli nie jest konieczne to faktycznie jest to zbędny środek ale to jak ze wszystkim. Gdyby te bazy stabilnie pracowały z błonami ja sam tez miał bym inna opinie.
0
I znowu kolega wloochacz jest WIELKI !
To jest proste jak metr sznurka w kieszeni. Nie mam pojęcia dlaczego do tej pory uskuteczniałem jakieś dziwne kombinacje.
ST := TMemoryStream.Create;
Image.Picture.Graphic.SaveToStream(ST);
StoredProc.ParamByName('?').LoadFromStream(ST, ftGraphic);
ST.Free;
Wielkie dzieki!
0
jurkowojc napisał(a):
I znowu kolega wloochacz jest WIELKI !
Wypraszam sobie, jestem zdecydowanie węższy niż kiedyś 
To jest proste jak metr sznurka w kieszeni. Nie mam pojęcia dlaczego do tej pory uskuteczniałem jakieś dziwne kombinacje.
No jest.
A gdzie bezpieczny kod bloku?
ST := TMemoryStream.Create;
try
Image.Picture.Graphic.SaveToStream(ST);
StoredProc.ParamByName('?').LoadFromStream(ST, ftGraphic);
finally
ST.Free;
end;
Wielkie dzieki!
Luzik.
Tylko zbyt często zapominam o tym, co dla mnie jest oczywiste, a dla innych niekoniecznie - niestety :/
0
Oczywiście, że jest !
Pozwoliłem sobie skrócic zapis dla lepszej czytelności ale widzę, że to był błąd !
Pozdrawiam
0
somedev napisał(a):
wloochacz napisał(a):
somedev napisał(a):
Ja bym uważał na bloby w Firebirdzie.
Niby dlaczego?
http://www.firebirdfaq.org/faq277/Ta, wiem - oni generalnie zawsze chwalą ten silnik.
Niemniej to moje doświadczenie. Baza z duża ilością blobow puchnie. Powoduje to utrudnienie podczas backupy i replikacji. Można omijać cześć tabel ale to tez dodatkowa komplikacja. Dodatkowo zauważyłem ze tabele z blobami często ulegają uszkodzeniu indeksów. Teoretycznie nie ma to nic do rzeczy ale napatrzyłem się na leżące bazy które padały po wprowadzeniu blobow. Przynajmniej do FB 2.5.3 nie ufam blobom na tyle by składować ich duże ilości w obawie o pad bazy. Nie są to plotki i mity a po prostu wieloletnie obserwacje.
Przewrotnie zapytam - a jaki SUB_TYPE BLOBowe pole miało ustawione?
Czy nie było jakiś dziwnych akcji z kopiowaniem pliku w trakcie działania silnika?
Pewnie nie, ale widziałem już i takich asów.
I co ciekawe, najczęściej im się udawało "i działało".
Ale do czasu.
/ciach/
No cóż więcej dodać do reszty?
Wszystko już chyba napisane :)
0
wloochacz napisał(a):
somedev napisał(a):
wloochacz napisał(a):
somedev napisał(a):
Ja bym uważał na bloby w Firebirdzie.
Niby dlaczego?
http://www.firebirdfaq.org/faq277/Ta, wiem - oni generalnie zawsze chwalą ten silnik.
Niemniej to moje doświadczenie. Baza z duża ilością blobow puchnie. Powoduje to utrudnienie podczas backupy i replikacji. Można omijać cześć tabel ale to tez dodatkowa komplikacja. Dodatkowo zauważyłem ze tabele z blobami często ulegają uszkodzeniu indeksów. Teoretycznie nie ma to nic do rzeczy ale napatrzyłem się na leżące bazy które padały po wprowadzeniu blobow. Przynajmniej do FB 2.5.3 nie ufam blobom na tyle by składować ich duże ilości w obawie o pad bazy. Nie są to plotki i mity a po prostu wieloletnie obserwacje.Przewrotnie zapytam - a jaki
SUB_TYPEBLOBowe pole miało ustawione?Czy nie było jakiś dziwnych akcji z kopiowaniem pliku w trakcie działania silnika?
Pewnie nie, ale widziałem już i takich asów.I co ciekawe, najczęściej im się udawało "i działało".
Ale do czasu./ciach/
No cóż więcej dodać do reszty?
Wszystko już chyba napisane :)
Różnie. Czasem były to bloby tekstowe, a czasem takie surowe. Ofc. bloby tekstowe były stosowane celowo - najczęściej to trzymania tekstów, opisów czy htmli. W surowych najczęściej lądowały obrazki i inne formaty binarne. Generalnie silnik zły nie jest, ale ma swoje zachcianki i po prostu trzeba uważać, dlatego omijam tutaj bloby, lub stosuje osobne bazy/pliki. W innych silnikach nie boję się blobów.
Nieee, nie działał silnik ;) Tzn. nie wtedy, kiedy padały te bazy - wtedy nie były tak gwałcone. Owszem zdarzało się asom na dev tak kopiować bazki i potem sie dziwić, ale na produkcji to stosuje się backupy gbakiem, lub kopiuje się plik bazy bo wcześniejszym jej zablokowaniu i złączeniem z deltą po operacji. Niemniej tutaj też raz był fuckup z złączeniem, więc z FB to jak z kryształowym kieliszkiem ;)
0
somedev napisał(a):
wloochacz napisał(a):
somedev napisał(a):
wloochacz napisał(a):
somedev napisał(a):
Ja bym uważał na bloby w Firebirdzie.
Niby dlaczego?
http://www.firebirdfaq.org/faq277/Ta, wiem - oni generalnie zawsze chwalą ten silnik.
Niemniej to moje doświadczenie. Baza z duża ilością blobow puchnie. Powoduje to utrudnienie podczas backupy i replikacji. Można omijać cześć tabel ale to tez dodatkowa komplikacja. Dodatkowo zauważyłem ze tabele z blobami często ulegają uszkodzeniu indeksów. Teoretycznie nie ma to nic do rzeczy ale napatrzyłem się na leżące bazy które padały po wprowadzeniu blobow. Przynajmniej do FB 2.5.3 nie ufam blobom na tyle by składować ich duże ilości w obawie o pad bazy. Nie są to plotki i mity a po prostu wieloletnie obserwacje.Przewrotnie zapytam - a jaki
SUB_TYPEBLOBowe pole miało ustawione?Czy nie było jakiś dziwnych akcji z kopiowaniem pliku w trakcie działania silnika?
Pewnie nie, ale widziałem już i takich asów.I co ciekawe, najczęściej im się udawało "i działało".
Ale do czasu./ciach/
No cóż więcej dodać do reszty?
Wszystko już chyba napisane :)Różnie. Czasem były to bloby tekstowe, a czasem takie surowe. Ofc. bloby tekstowe były stosowane celowo - najczęściej to trzymania tekstów, opisów czy htmli. W surowych najczęściej lądowały obrazki i inne formaty binarne. Generalnie silnik zły nie jest, ale ma swoje zachcianki i po prostu trzeba uważać, dlatego omijam tutaj bloby, lub stosuje osobne bazy/pliki. W innych silnikach nie boję się blobów.
Pytam, ponieważ problemy z blobami tekstowymi (czyli SUB_TYPE 1) są ogólnie znane i jest ich naprawdę (albo było, w sumie nie jestem na bieżąco) sporo.
Tak czy inaczej, szybko przejrzałem swoje historyczne bazy FB i okazuje się, że nie używałem blobów tekstowych nawet do przechowywania takich takich danych.
Może właśnie dlatego mam dobre doświadczenia?
Nieee, nie działał silnik ;) Tzn. nie wtedy, kiedy padały te bazy - wtedy nie były tak gwałcone. Owszem zdarzało się asom na dev tak kopiować bazki i potem sie dziwić, ale na produkcji to stosuje się backupy gbakiem, lub kopiuje się plik bazy bo wcześniejszym jej zablokowaniu i złączeniem z deltą po operacji. Niemniej tutaj też raz był fuckup z złączeniem, więc z FB to jak z kryształowym kieliszkiem ;)
Z FB miałem naprawdę sporo problemów wydajnościowych w wersji 1.5, czyli historia...
Optymalizator w tamtej wersji praktycznie był nieśmiesznym żartem.
Jednak doszedłem do naprawdę niezłej wprawy i miałem spektakularne wyniki :D
Pamiętam też, że raz przepisałem skomplikowaną procedurę składowaną (i modyfikowałem indeksy), która robiła to samo tylko ok. 500x (tak, nie pomyliłem się) wydajniej.
Firebird w poprzednich wersjach potrafił naprawdę nieźle zaskoczyć i to nie zawsze pozytywnie pod kątem pracy optymalizatora zapytań (np. left join był wielokrotnie wolniejszy od 'inner join', albo kiedy warunek przeniosło się z klauzuli where do warunku złączenia - błyskawica. Dużo pomagał mi wtedy w pracy IBExpert).
Z MSSQL też miałem raz taką akcję, że w pewnym systemie raport stanu magazynu na dzień wykonywał się dłużej niż dobę.
Przepisałem go na jakieś 6 minut.
No, ale tam "programiści" (od siedmiu boleści) dali tak kosmicznie ciała, że trudno sobie wyobrazić podobną "kreatywność".