🚀 go-pugleaf

Piotr Kolodziej <pkol@otago.gda.pl> wrote:
: GiZu wrote in message <6nfr6e$oel$5@fox.ds14.agh.edu.pl>...
:>moje pytania to:
:>
:>1) czy baza SQL-owa się nadaję do takich celów ?

: Do celów serwowania obrazków? Jak widać, nadaje się ;)
: Jeśli tylko obsługuje duże obiekty binarne, to nie widzę
: większego kłopotu.

z przechowywaniem raczej nie ma większych problemów...

:>2) jak zrealizowane w niej jest przeszukiwanie ?

: Z reguły po indeksach. Zauważ, że nie przeszukujesz po cechach
: obrazków, lecz po np. współrzędnych geograficznych. Czyli
: tak naprawdę nie przetwarzasz dużych obiektów binarnych.

tu się zgodzę, podejście do tego w ten sposób wydaje się 
oczywiste (patrząc pod kątem baz relacyjnych)

: Chociaż.... Są rozszerzenia baz relacyjnych pod kątem np. składowania
: dużych dokumentów, np. w formacie Worda ;))))) ale i nie tylko.
: Przykład ? ContextOption w Oracle'u, który w Oracle8 zaczął się
: nazywać cartridge'm coby CORBie było bliżej ;))))

z tym się niespotkałem, a brzmi dosyć egzotycznie. chociaż chyba to
jest baza obiektowo-relacyjna :-)

: Zapewnia on m.in. możliwości efektywnego przeszukiwania dokumentów.
: Ale wracając do fotek. Struktura tabeli wyglądałaby z grubsza tak:
: - długość geo
: - szerokość geo
: - obrazek

czyli minimum operacji. nic więcej z tego się niewydobędzie :-)
podejście relacyjne w tym wypadku ogranicza jednak inne metody
wyszukiwania.

: Indeksujesz współrzędne z 2 pierwszych kolumn i wyszukiwanie będzie
: efektywne.

dokładnie, w tym wypadku będzie to klucz do wyszukiwania.

: No dobrze. A co się dzieje, gdy np. chcę wyszukiwać po cechach
: obrazków (mapy) np. procent powierzchni morza, procent powierzchni
: czegoś tam jeszcze. Tworzę wtedy nadmiarowe kolumny, w które
: JEDNORAZOWO wpisuję te wartości wyliczane przy wstawianiu/modyfikacji
: obrazka. Nadmiarowość jest uzasadniona, gdyż każdorazowe wyliczenie
: przy każdym wyszukiwaniu byłoby bardzo kosztowne.

to chyba jest oczywiste :-) wyliczenie dla tysiąca obiektów jednej
cechy przy jednym wyszukaniu... (chyba że baza jest jeszcze większa) -
i pomyśleć sobie, że jest kilka zapytań jednocześnie do serwera... Nie
nam raczej nie chodzi o głupie rozwiązania. W tym wypadku serwer który
by to obsługiwał - mógłby przyjąć 10 użytkowników jednocześnie, i nawet
oni potrafili by go 'zarżnąć' :-)

: I te pola oczywiście indeksuję do celów wyszukiwania.

:>3) czy nie lepsze byłyby do tych celów bazy obiektowe
:>a nie relacyjne..

: A co masz na myśli mówiąc "obiektowe" ?
: Bo prawdę mówiąc, to jak sobie przypomnę cechy, jakie wg
: entuzjastow obiektowości miały np. w 1991-1992r. wyróżnać bazy
: obiektowe, to z czystym sumieniem mogę Ci powiedzieć, że w
: większości współczesnych baz relacyjnych daje się je uzyskać.

raczej nie. obiektowe bazy danych nie mają jeszcze dokładnie określonej
specyfikacji - ale wróży im się ładną karierę (wg. prognoz sprzed
kilku lat, powinny stanowić obecnie większość rynku bazodanowego).
Mimo to do tej pory nie udało się stworzyć konkretnej specyfikacji,
wszystko jest w wersjach core, draft itepe :-). 

Bazy relacyjne natomiast mają doskonale opracowaną specyfikacje.

: Może poza polimorfizmem, ale gdyby dobrze pokombinować....
: AFAIK nie ma żadnej komercyjnej bazy obiektowej w powszechnym
: użyciu. Może już służą do wyrafinowanych zastosowań, typu CAD'y itd,
: ale nic mi o tym nie wiadomo.

znam garść nazw, ale nie mówią mi one zbyt wiele :-) min. 

Jasmine, Gemstone, O2, Object Store, Objectivity/DB, Versant ODMBS

na razie jest tego niewiele na rynku. no i obecnie wchodzą rozwiązania
typu obiektowo-relacyjne bazy danych, co jest rozwiązaniem tymczasowym
(niezgodność koncepcji - wszystko polega na konwersjach obiekt <-> tabela
i innych). 

: Powód??? Prozaiczny. Choćby stabilność i wydajność przy liczbie
: uzytkowników znacznie większej od 1.

tego nie rozumiem.. bazy obiektowe są niestabilne ? 

nie jestem specjalistą od baz danych. moje informacje są na ten temat
bardzo ogólnikowe. jednak z tego co się orientuję, to bazy obiektowe
doskonale nadają się jako bazy multimedialne, z tego to powodu, że opis
danych (obiektów) w bazie jest bardzo naturalny/rzeczywisty. Podejście
relacyjne jest podejściem sztucznym. Dla bazy obiektowej można
zdefiniować metody, zastosować dziedziczenie i inne rzeczy stosowane w
językach obiektowych (c++/java/small talk). Tak więc dodając obiekt do
bazy danych nie musisz martwić się wypełnianiem tych pól - jest to
robione za ciebie przez metody zawarte w opisie obiektu. Tak więc
wyszukiwanie w bazie danych dla obiektów graficznych może być o wiele
bardziej złożone - można dodać więcej kryteriów, których dodanie do
bazy relacyjnej jest niewygodne i nieefektywne. Ponoć przeszukiwanie
bazy relacyjnej zawierającej duże dane (min. zdjęcia) jest bardzo
nieefektywne, zaś w bazach obiektowych jest to zrealizowane na
referencjach, co wpływa na szybkość wykonania operacji...

jak już pisałem, jestem w tej dziedzinie lajkonikiem :-), więc to co tu
piszę, to tylko moje wyobrażenia na ten temat. Trochę informacji o
bazach obiektowych i relacyjno-obiektowych znalazłem pod adresem
http://galaxy.uci.agh.edu.pl/~vahe/obd.htm 
może to kogoś zainteresuje  - a jest tam kilka ciekawych artykułów
(strona asystenta, u którego mieliśmy zajęcia z baz danych :-)

: Pozdrawiam
: Piotr

pozdrawiam

GiZu

-- 
Paweł Kołodziejczyk
mailto:giz@ds14.agh.edu.pl 

Life would be so much easier if we could just look at the source code.