Forum Debian Users Gang

Zapewne zależy od zapytanie ile warunków oraz ważne jak zindeksowane i dobrane pola do przechowywanych danych.
Podstawa to normalizacja tabeli przynajmniej do 1N.

A co do wydajności to zależy wiele od silnika (MySQL, PostgreSQL), w samym MySQL jest też kilka mechanizmów składowani: InnoDB, MyISAM, BerkleyDB itp. wszytkie mają swoje zalety i wady. Najszybszy (w większości przypadków) jest MyISAM ale nie wspiera transakcji, co niekiedy jest kluczowe.

Ostatnio edytowany przez life (2012-05-18 13:00:19)

Możesz zdradzić co robi ten programik? Skoro potrzebuje tysiąca tabel., to umieram z ciekawości ;]

Zastosuj jakiś silnik z pełnotekstowym wyszukiwaniem.  Krocie tabel da odwrotny efekt od zamierzonego.

Tabele idą na zasadzie:

A_PL, B_PL, C_PL...Z_PL

oraz

A_EN, B_EN, C_EN...Z_EN

plus tabele łącznikowe:

A_PL_2_A_EN, A_PL_2_B_EN, A_PL_2_C_EN itd

W tabelach zwykłych jest tylko ID i wartość w postaci stringa, w łączących, ID i relacje na każdą z tabel.

Myślałem sobie że aby np. wykorzystać coś do smart filtra (podpowiadania jak to na google przy wyszukiwaniu), najlepiej podzielić to na jak najwięcej tabel, aby zamiast szukać w jednej, czy tam kilku, z setkami tysięcy wpisów (oczywiście to jest hipotetyczne wiadomo że obecnie jest tam tylko garstka wpisów, ale chciałem to zrobić przyszłościowo - w końcu ilość tłumaczeń słów z angielskiego na polski i vice versa to są dziesiątki, jak nie setki tysięcy wyrazów...), szukać na zasadzie:

Jeżeli pierwsza litera to A to pobieraj z A, jak B to z B itd. Na "chłopski" rozum to powinna być niezła optymalizacja... tyle że wtedy się zacząłem zastanawiać czy ilość tabeli nie będzie miała wpływu na wydajność zapytań - jak na ironię nigdzie nie mogę znaleźć takiego porównania.

Gdyby to miało być robione na jednej czy dwóch tabelach to widzę to na zasadzie:

FRAZA_PL, FRAZA_EN, FRAZA_PL_2_FRAZA_EN (wiadomo że słowa mogą mieć wiele znaczeń)

Tylko ciekaw jestem jak szybko to będzie przeszukiwane (nawet z indeksami) jeżeli by w takiej tabeli było np 100 000 rekordów... nie mam aż takie dużego doświadczenia z SQL'em stąd pytanko do Was :)

Wow pierwsza postac normalna... Toż to nie daje optymalizacji.
Raczej celowałbym w cos obiektowego, a nie relacyjnego.

@life: MySQL czy PostgreSQL same w sobie nie są jakimkolwiek silnikiem, to własnie np. InnoDB jest "silnikiem" bazy.

Moi drodzy, dzięki za info, od razu doprecyzuję - z której obecnie korzysta program to plikowy SQLite, oczywiście można to szybko zmienić.

Co do meritum - sorry że będę upierdliwy, ale czy ktoś z Was miał jakieś realne doświadczenie, bądź posiada wiedzę książkową która daje podstawy stwierdzić że duża ilość tabel będzie miała negatywne skutki? Może lepiej połączyć to o czym piszecie z rozdziałem na tabele? Żebyśmy się dobrze zrozumieli - znawca ze mnie wielki nie jest, ale zastanawiam się jak takie google czy inne firmy trzymają dane - aby przy ogromnych ilościach smartfiltry działały w czasie rzeczywistym i wydaje mi się że tam, bez optymalizacji same indeksy rady by nie dały stąd moje wątpliwości, a wlałbym projektować soft od razu jak najlepiej żeby potem jajek nie było (ok, google pewnie zamiast SQL korzysta z NoSQL, albo jeszcze czegoś innego - ale wiadomo o co mi chodzi) ;]

Pozdro.

Ze swojego doświadczenia z MySQL wiem:

Ilość tabel ma wpływ na pracę serwera jako maszyny a nie bazy MySQL

Baza MySQL będzie działać wolniej jak:
1) jest duża ilość danych do przeszukania w jednej tabeli
2) zapytanie przeszukuje w kilku tabelach
3) ilość wierszy zwracanych jest duża (nie robić zapytania SELECT * ...)

Własne doświadczenia opieram na pracy z bazami rzedu 10GB