Jedna większa czy kilka mniejszych powiązanych tabel? Opcje

[Thomashek]

Witam

Opiszę na początku, jak wygląda większa tabela: pola id, nazwa, adres, dane1, dane2, dane3, abc, def, ghj, ... (do 20 - 30 pól; nazwy nieistotne). Struktura serwisu przewiduje jedną listę zbiorczą, w której będą w kolumnach prezentowane dane nazwa, adres i abc. Dopiero po wybraniu szczegółów danej pozycji ukażą się pozostałe dane.

I tu pytanie: lepiej zachować taką strukturę danych czy utworzyć dodatkową tabelę powiązaną na podstawie id z pierwszą, która to będzie zawierać pola wyświetlane dopiero w szczegółach? Tzn. mam na myśli coś na kształt:
tabela1:
id
nazwa
adres
abc

tabela2:
id
dane1
dane2
dane3
abc
def
ghj
...

Z góry dziękuję za odpowiedź

[c3zi]

Witam,

Pewnie, ze lepiej zrealizowac to z podzialem na tabele. Btw. poczytaj o normalizacji baz danych ...

Pozdrawiam.

[dymsza1]

nie zgodze sie z tym co mowiesz to zalezy od ilosci danych . przy duzych tablach (setki tysiecy wpisow )warto denormalizowac dane. ale jak bedzie

[Indeo]

Znormalizowane tabele są często niewygodne w użyciu. Przy zwykłych stronach, których aparat bazodanowy definiuje się raz a bazy są obsługiwane wyłącznie przez jeden program (stronę) to wystarcza. Ale przy dużych bazach danych , na których pracuje wiele różnych programów ciągłe inicjowanie składania odwołań do kilku tabel jest męczące i zbędnie obciąża serwer. Mnie jako analityka sprzedaży opracowującego ciągle nowe zapytania do baz danych pod kątem analitycznym denerwuje ciągła konieczność "podpinania" nazw kontrahentów poprzez nr_ewidencyjny i często idę na łatwiznę i przy tworzeniu niektórych tabel dodaję sobie to pole tak aby mieć bezpośredni do niego dostęp, a nie tylko nr_ewidencyjny, którym mogę sobie brać dane kontrahenta z tabeli kontrahentów. Po prostu kiedy badam jakiś problem będący rekurencyjną zależnością tabeli samej do sobie i 15 innych tabel - ostatnią rzeczą jaką chce mi sie jeszcze robić jest podpinanie oczywistych tabel z kontrahentami, adresami posesji itp. Do pewnego momentu pomagają w tym widoki ale widoki pomagają tylko organizacyjnie - w praktyce są wolne i bardzo obciążają serwer. W dużych bazach danych po zakończeniu pewnych okresów dla których wiadomo już że dane nie ulegną zmianie (np sprzedaż w danym miesiącu) tworzy sie specjalne tabele z gotowymi obliczeniami tak aby klient pytający o sprzedaż danej usługi w miesiącu mógł uzyskać odpowiedź z zapytania do jednej tabeli a nie od nowa za każdym razem obliczać dokładnie to samo.
Jednym słowem kiedy zapytania robią się powtarzalne i ciężkie dla serwera to zapisuje się ich wyniki na stałe tak aby z pojedynczej tabeli można było pobrać dużo informacji.

Ale w zastosowaniach internetowych o których pisze tu większość osób baza znormalizowana, a więc statystycznie posiadająca w tabelach więcej odwołań do innych tabel niż pól niebędących odwołaniami jest słusznym rozwiązaniem.