wydajnosc db - duzo duzych polilinii

Witam

W bazie danych zamierzam trzyma wspolrzedne dosyc duzych polilinii (skladajacych sie od kilkuset do kilkunastu tysiecy punktow). Takich polilini bedzie dodawanych do 150 dziennie.

Kazda z tych polinili bedzie wyswietlana wiele czesciej niz dodawana. Tzn. kazdorazowo kazda polinie bedzie trzeba poskladac z tych punktow i wyswietlic. Kilku uzytkownikow bedzie moglo chciec rownoczenie wyswietlac rozne polilinie.

Moje pytanie jest takie:
Czy lepiej w bazie danych trzymac kazdy punkt polilinii jako osobny rekord? czy lepiej tworzyc osobny rekord (np. polilinia_2) i w jednym polu tekstowym trzymac wszystkie punkty kazdej polilini?

Trzymajac kazdy punkt osobno baza bardzo szybko "spuchnie". Zakladajac srednio 100 polilini z 1000 punktow i przez 1 rok daje 36,5 mln rekordow rocznie.
Trzymajac wszystkie punkty kazdej polilini w jednym rekordzie bede mial 36.5 tys rekordow, ale kazdy moze miec duze pole tekstowe.

Jak to bedzie z wydajnoscia?? Czy np. postgresql lub inna baza danych bedzie bardziej wydajna niz mysql??

Ciekawy problem :)
Na początek mam kilka pytań.
W jaki sposób będą wyszukiwane linie. Czy uzytkownik będzie je wybierał z listy dostępnych czy też wyklikiwał punkt po punkcie i w ten sposób linia będzie dodawana do bazy jeżeli nie istnieje?
Czy dane można w jakiś rozsądny sposób indeksować, bo to że indeks można założyć to wiadomo, pytanie na co.
Czy wchodzi w grę trzymanie linii jako xmla?

MySQL w przypadku trzymania każdego punktu w osobnym rekordzie i konieczności dostępu do całej polilinii będzie najgorszym możliwym rozwiązaniem, ponieważ nie obsługuje indeksów grupujących.
W przypadku MySQLa pozostaje Ci trzymać jeden rekord / polilinię. Rozwiązanie bardzo mało elastyczne, bo prawie nic z tym zrobić nie możesz, jeśli chodzi o wyszukiwanie - tzn. możesz odczytywać i zapisywać całe polilinie na raz, nie możesz np. zrobić operacji "znajdź polilinię najbliższą do danego punktu".

W przypadku trzymania jednego rekordu / punkt każdy RDBMS posiadający indeksy grupujące (np. PostgreSQL, Oracle, DB/2, MS SQL) będzie dobry.

Obczaj sobie jeszcze PostGISa - specjalnie do trzymania danych przestrzennych - może się nada.

zalozmy ze uzytkownik rysuje subie obrazek (np. zwierzatko). wskazuje myszka punkty i rysuje. Dla kazdego punktu sa przypisywane wspolrzedne x,y. Nastepnie moze zapisac ten obrazek (np. kotek).
Nastepnie inni uzytkownicy moga przegladac ten obrazek. Wiec musze pobrac te dane z db i wyswietlic.

A wiec ktos kto przeglada dane pobiera na podstawie nazwy obrazka, nie ma wplywu na konkretne punkty. Pobrane sa one 1x i tyle.
Ale np. uzytkownik (wlasciciel obrazka) moze chciec cos poprawic, przesunac jakies punkty, wiec tutaj musi byc juz dostep do konkretnych punktow.

Nie jest wazne polozenie konkretnych punktow z jednej polilinii do punktow z innej polilinii.

biore takze pod uwage trzymanie danych (wspolrzednych punktow dla konkretnej polilinii w pliku xml). Tylko czy jest pozniej jakis sens ladowac taki plik xml do bazy danych (blob)?

Skoro wyszukiwanie następuje po czymś innym niż nasze dane to można je trzymać w pojedynczej kolumnie. W sumie i tak interesują cię całe obrazki, a przed wyświetleniem niezależnie od tego jak będą trzymane (punkt per rekord czy tez obrazek per rekord) muszą trafić na jakiś parser i translator, które sprawdzą rysunek i przetłumaczą dane na grafikę. Bardziej interesujące jest to, że wybieranie/wstawianie/modyfikacja po punkcie spowoduje ogromną ilość operacji na bazie. Część z nich, wstawianie, modyfikacja, są to operacje blokujące, które z założenia mają pewien narzut. Uzasadnione staje się zatem trzymanie obrazka jako pojedynczego rekordu.
Co do xmla, to zastanawiałem się nad SVG i czy nie można by było tego zastosować.