Efektywność bazy / rozbicie na tabele Opcje

[Wykrywacz]

Zastanawiam czy ma znaczenie na prędkości działania wielkość tabeli w bazie.

Sprawa tyczy się tego, że albo będę musiał do już sporej tabeli dopisać jeszcze 3 pola, albo stworze nową
gdzie stworze 3 identyczne pola w stosunku do tej istniejącej i dopisze 3 nowe.

Zastanawiam się czy jest to jaka kolwiek różnica w takim wypadku dla mysql'a czy nie, dodam ze dość spore obciążenia ma ta dotychczasowa, dla ew. tej nowej przewiduje znacznie mniejsze, ale i tak znaczne.

[SongoQ]

Zastanawiam czy ma znaczenie na prędkości działania wielkość tabeli w bazie.

Oczywiscie ze tak.

Ogolnie to zalezy od ilosci tych danych i jak bedziesz laczyl to relacja i wyciagal dane. Zrob testy i sam sie przekonasz co lepsze.

[Wykrywacz]

Może źle nazwałem.
Czy dla wydajności bazy lepiej dociążyć istniejące tabele
czy lepiej stworzyć osobne.

Nie jestem wstanie tego przetestować, chodźby z uwagi na ilości i wykonywanie zadań jednoczenie, znaczy się w tym samym czasie przez wielu userów. Stąd pytam o teoretykę. I zdaje sobie sprawę że czym większa tabele tym wolniej pracuje, pytanie czy baza z większą tabelą powinna pracować szybciej czy z 2 mniejszymi.

[dr_bonzo]

Mozesz zrobic kopie bazy, spisac wywolywane zapytania i je wykonac na kopii tej bazy.

A do optymalizacji nie jest potrzebna teoria tylko praktyka -- uruchomisz i dziala szybciej to dziala szybciej.

Czy dla wydajności bazy lepiej dociążyć istniejące tabele
czy lepiej stworzyć osobne.

1. najpierw baza powinna byc znormalizowana, potem ja optymalizuj
2. i znow masz wybor miedzy wiekszym rekordem (dodales nowe kolumny) -> wieksza tabela, a zlaczeniami z ta nowa tabela, no i to musisz sprawdzic, bo oba rozwiazania moga ci spowolnic system

[fridek]

Rzuć okiem na testy:
http://karpisz.mech.pk.edu.pl/db_norm.htm

Masz porównanie szybkości, w przypadku danych rozbitych na tabele i trzymanych razem.

[prond]

Zerknąłem na podany artykuł, ale nie można się opierać na przedstawionych tam wynikach w sytuacji kiedy korzystamy np. z MySQL, czy PostgreSQL, czy ORACLE i wykorzystujemy w miarę dobrze ich możliwości:
- jeśli dobrze zrozumiałem to na wspomnianych w artykule tabelach jest robiony sequence scan, a co za tym idzie pewnie tabele są łączone nested loop'em i w zasadzie tylko ten wariant jest tam rozpatrywany
- zawsze można założyć indeksy - index scan jest znacznie szybszy
- bazy takie jak PostgreSQL, czy ORACLE można zmusić (ale też same to potrafią dzięki GEQO) do wyboru najoptymalniejszego algorytmu łączenia

Suma sumarum - przetestuj sam, dla jakiego przypadku będzie system działał szybciej.