Wydajnosc
nowy - 16-10-2007 00:00
Wydajnosc
Witam
mam taką dziwna sytuacje
Moja główna tabela ma 70 kolumn
czy będzie lepiej rozłożyć ja na 3 tabele (w jakiś logiczna myśl) i
spiąć ja relacja
czy zostawić tak jak jest
i co wtedy z wydajnością
baza to MS SQL 2005 EX
Wszelkie info mile widziane
wloochacz - 16-10-2007 00:00
[ciach]
> Wszelkie info mile widziane
To jest dopiero konkretne pytanie! ;-)
Odpowiedź znam tylko jedną; to zależy.
--
wloochacz
nowy - 16-10-2007 00:00
wloochacz pisze:
> [ciach]
>> Wszelkie info mile widziane
> To jest dopiero konkretne pytanie! ;-)
> Odpowiedź znam tylko jedną; to zależy.
>
OD czego
co jeszcze jest potrzebne
wg mnie to proste pytanie
czy tabela ma mieć 70 kolumn
czy zrobić 3 tabele średnio po 20 kolumn z tymi samymi danymi
Grzegorz DANOWSKI - 16-10-2007 00:00
Użytkownik "nowy" <bombelo@poczta.onet.pl> napisał w wiadomości
news:fev85b$khr$1@nemesis.news.tpi.pl...
> wloochacz pisze:
>> [ciach]
>>> Wszelkie info mile widziane
>> To jest dopiero konkretne pytanie! ;-)
>> Odpowiedź znam tylko jedną; to zależy.
>>
> OD czego
> co jeszcze jest potrzebne
>
>
> wg mnie to proste pytanie
> czy tabela ma mieć 70 kolumn
>
> czy zrobić 3 tabele średnio po 20 kolumn z tymi samymi danymi
Najpierw się zastanów czy tak dużej tabeli nie da się znormalizować, bo
raczej żadko istnieje potrzeba użycia 70 atrybutów. Może np. masz 31 kolumn
z planami na kolejne dni następnego miesiąca? Poza tym jeśli już musisz mieć
te 70 kolumn, to pomyśl jakie dane będą używane w zapytaniach - jeśli np.
większość zapytań będzie dotyczyła tylko niewielkiej liczby atrybutów, a
dodatkowo pozostałe kolumny będą relatywnie ciężkie (długie stringi) to może
warto sztucznie wyodrębnić te atrybuty (jeśli do tego nie prowadzi
normalizacja). Ale jeśli za każdym razem będziesz ściągał wszystkie 70
kolumn, to podział na 3 tabele tylko pogorszy wydajność.
--
Pozdrawiam
Grzegorz
wloochacz - 16-10-2007 00:01
[ciach]
>> OD czego
>> co jeszcze jest potrzebne
Projekt, projekt jest potrzebny.
Co to za dane i w jaki sposób będą używane?
>> wg mnie to proste pytanie
>> czy tabela ma mieć 70 kolumn
>>
>> czy zrobić 3 tabele średnio po 20 kolumn z tymi samymi danymi
>
> Najpierw się zastanów czy tak dużej tabeli nie da się znormalizować, bo
> raczej żadko istnieje potrzeba użycia 70 atrybutów. Może np. masz 31 kolumn
> z planami na kolejne dni następnego miesiąca? Poza tym jeśli już musisz mieć
> te 70 kolumn, to pomyśl jakie dane będą używane w zapytaniach - jeśli np.
> większość zapytań będzie dotyczyła tylko niewielkiej liczby atrybutów, a
> dodatkowo pozostałe kolumny będą relatywnie ciężkie (długie stringi) to może
> warto sztucznie wyodrębnić te atrybuty (jeśli do tego nie prowadzi
> normalizacja). Ale jeśli za każdym razem będziesz ściągał wszystkie 70
> kolumn, to podział na 3 tabele tylko pogorszy wydajność.
No więc właśnie, to ZALEŻY! :)
--
wloochacz
dap997 - 16-10-2007 00:01
nowy wrote:
> Witam
>
> mam taką dziwna sytuacje
>
> Moja główna tabela ma 70 kolumn
>
> czy będzie lepiej rozłożyć ja na 3 tabele (w jakiś logiczna myśl) i
> spiąć ja relacja
>
> czy zostawić tak jak jest
>
> i co wtedy z wydajnością
>
>
> baza to MS SQL 2005 EX
>
>
> Wszelkie info mile widziane
Sprawdz :)
A tabele normalizuje się zgodnie z postaciami normalnymi.
http://pl.wikipedia.org/wiki/Posta%C...bazy_danych%29
dap
nowy - 17-10-2007 00:01
wloochacz pisze:
> [ciach]
>>> OD czego
>>> co jeszcze jest potrzebne
> Projekt, projekt jest potrzebny.
> Co to za dane i w jaki sposób będą używane?
>
>>> wg mnie to proste pytanie
>>> czy tabela ma mieć 70 kolumn
>>>
>>> czy zrobić 3 tabele średnio po 20 kolumn z tymi samymi danymi
>>
>> Najpierw się zastanów czy tak dużej tabeli nie da się znormalizować,
>> bo raczej żadko istnieje potrzeba użycia 70 atrybutów. Może np. masz
>> 31 kolumn z planami na kolejne dni następnego miesiąca? Poza tym jeśli
>> już musisz mieć te 70 kolumn, to pomyśl jakie dane będą używane w
>> zapytaniach - jeśli np. większość zapytań będzie dotyczyła tylko
>> niewielkiej liczby atrybutów, a dodatkowo pozostałe kolumny będą
>> relatywnie ciężkie (długie stringi) to może warto sztucznie wyodrębnić
>> te atrybuty (jeśli do tego nie prowadzi normalizacja). Ale jeśli za
>> każdym razem będziesz ściągał wszystkie 70 kolumn, to podział na 3
>> tabele tylko pogorszy wydajność.
> No więc właśnie, to ZALEŻY! :)
>
generalnie to 45% pola daty, kolejne 45% to pola textowe (300)znaków -
pole uwag do dat
pozostałe 10% to klucze obce do innych tabel
nie robie wielu operacji na datach
generalnie tylko 6 dat jest branych do jakichkolwiek obliczeń
wszystkie daty i pola uwag są wyświetlane w programie w 2 różnych oknach
6dat w pierwszym oknie
reszta to takie szczegóły
Wiec lepiej w kilku tabelach w zależności jak to wyświetlam ???
Szymon - 17-10-2007 00:01
nowy pisze:
> wloochacz pisze:
>> [ciach]
>>>> OD czego
>>>> co jeszcze jest potrzebne
>> Projekt, projekt jest potrzebny.
>> Co to za dane i w jaki sposób będą używane?
>>
>>>> wg mnie to proste pytanie
>>>> czy tabela ma mieć 70 kolumn
>>>>
>>>> czy zrobić 3 tabele średnio po 20 kolumn z tymi samymi danymi
>>>
>>> Najpierw się zastanów czy tak dużej tabeli nie da się znormalizować,
>>> bo raczej żadko istnieje potrzeba użycia 70 atrybutów. Może np. masz
>>> 31 kolumn z planami na kolejne dni następnego miesiąca? Poza tym
>>> jeśli już musisz mieć te 70 kolumn, to pomyśl jakie dane będą używane
>>> w zapytaniach - jeśli np. większość zapytań będzie dotyczyła tylko
>>> niewielkiej liczby atrybutów, a dodatkowo pozostałe kolumny będą
>>> relatywnie ciężkie (długie stringi) to może warto sztucznie
>>> wyodrębnić te atrybuty (jeśli do tego nie prowadzi normalizacja). Ale
>>> jeśli za każdym razem będziesz ściągał wszystkie 70 kolumn, to
>>> podział na 3 tabele tylko pogorszy wydajność.
>> No więc właśnie, to ZALEŻY! :)
>>
> generalnie to 45% pola daty, kolejne 45% to pola textowe (300)znaków -
> pole uwag do dat
> pozostałe 10% to klucze obce do innych tabel
>
>
> nie robie wielu operacji na datach
> generalnie tylko 6 dat jest branych do jakichkolwiek obliczeń
>
> wszystkie daty i pola uwag są wyświetlane w programie w 2 różnych oknach
> 6dat w pierwszym oknie
> reszta to takie szczegóły
>
>
> Wiec lepiej w kilku tabelach w zależności jak to wyświetlam ???
Nie, lepiej w kilku tabelach w zależności od logicznej struktury
programu/bazy/danych. Zależy jaki masz projekt, co to za dane i to nie
ma znaczenia czy pola tekstowe czy nie. Poczytaj o 3 postaci normalnej,
na początek powinno wystarczyć, potem możesz poczytać dlaczego w dużych
bazach jej nie używać :)
szaman - 19-10-2007 00:00
> wg mnie to proste pytanie
> czy tabela ma mieć 70 kolumn
>
> czy zrobić 3 tabele średnio po 20 kolumn z tymi samymi danymi
>
>
Zastanawia mnie skąd wziąłeś ten podział na trzy a może lepiej będzie na
70 ? ;-)
Z własnego doświadczenia doradzam zrób jedną tabelę.
Co do normalizacji to jak najbardziej musisz wiedzieć co to takiego i
nauczyć się stosować a gdy już się nauczysz i będziesz to miał, że tak
powiem w nawyku i to z dokładną znajomościa zagadnienia i problemów na
wszystkich szczeblach produkcji aplikacji to wtedy musisz zacząć myśleć
o denormalizacji. Normalizacja bowiem często stoi w sprzeczności z
wydajnością bazy.
Co do tych moich doświadczeń to : miałem niegdyś zagadnienie typu 92
pola do tabeli z których 90% to pola tekstowe i to dużych rozmiarów,
ponadto 90% z nich powinna być zesłownikowana dla wartości występujących
więcej niż raz (taki typ słownika mający ułatwić wprowadzanie i
wyszukiwanie a nie ograniczać wartości). Rzecz jasna natrafiłem na
ograniczenia bazy a przede wszystkim maksymalny rozmiar rekordu - w
efekcie musiałem podzielć tą tabelę na 8 mniejszych w relacji jeden do
jednego. Napracowałem się z oprogramowaniem całości bo przecież
wszystkie select'y, insert'y, update'y, delete'y musiały być wykonywane
na tym oktecie. Po kilku latach przenosiłem to na lepszą bazę danych i
wolałem przerobić całość na jedną tabelę mimo, że wiązało się to z
przeróbką również aplikacji - nie mniej robiłem to z ochotą bo było to
upraszczanie sytuacji. Tym przykładem chciałem pokazać, że bardzo liczy
się a często wręcz najbardziej nie wydajność bazy a pracochłonność jej
pisania a potem utrzymania.
Co do testów wydajności to myślę, że jedna tabela też będzie szybciej
działać niż łączenie kilku, no i utrzymywanie niezbędnych do takiego
łączenia indeksów.
Przecież teraz naszły takie czasy, że aby sprostać nowym wymaganiom
wydajności (w szczególności spowodowanym rozmiarami baz) stosuje się
wręcz podejście obiektowe przechowując w jednym "rekordzie" całe złożone
zhierarchizowane struktury, które normalnie musiał byś zdekomponować
do szeregu tabel a przy odczycie skomponować obiekt (co zajmuje i czas
programisty i bazy).
zanotowane.pldoc.pisz.plpdf.pisz.pleffulla.pev.pl
|
Polski Corel 11 i update'y
SAP i Linux
czcionka
[Firebird]Kilka zapytań zebrać w jedno
SQL i genealogia
przekierowanie STDOUT i STDERR?
format eps
oracle vs sybase bo jestem w kropce....
[PostgreSQL] Kompilacja pod Windows
MSSQL2005 Express
zanotowane.pldoc.pisz.plpdf.pisz.plwawa19wwa91.pev.pl
Cytat
Decede mihi sole - nie zasłaniaj mi słonca.
Gdy kogoś kochasz, jesteś jak stworzyciel świata - na cokolwiek spojrzysz, nabiera to kształtu, wypełnia się barwą, światłem. Powietrze przytula się do ciebie, choćby był mróz, a ty masz w sobie tyle radości, że musisz ją rozdawać wokoło, bo się w tobie nie mieści
Hoc fac - tak czyń.
A tergo - od tyłu; z tyłu.
I czarne włosy posiwieją. Safona |
|
