=?iso-8859-2?B?RHppd25lIHBvbXlzs3kgdyBTUUwg?=
Mwa - 17-02-2007 00:16
=?iso-8859-2?B?RHppd25lIHBvbXlzs3kgdyBTUUwg?=
Cześć
Mam projekt który wymagałby po 100 kolumn na rekord więc wykąbinowałem
strókture z 3 tabelami w pierwszej jest ID "rekordu" i ew. jakieś
podstawowe dane w drógiej jest lista kolumn a trzecia to tabela łącząca (z
indexami "unikalny" żeby się nie poplątało) i wartością
Czy Ktoś mugłby opisać potencjalne nieszczęścia wynikające z takiej
stróktury ??
na dzień dobry widze problemy z wydajnością i większe zurzycie miejsca na
dysku poniewasz te "wirtualne" kolumny mają taką samą długość/typ, co
jeszcze ??
to jest na mySQL ale jestem też ciekaw opini na pgSQL i msSQL poniewasz
czasem ich urzywam
Pozdrawiam Marcin
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
=?ISO-8859-2?Q?Micha=B3_Zaborowski?= - 17-02-2007 00:16
Witam,
Z opisu i na oko wynika, że można zrobić np. 3-4 tabele w realcji
1-1. Pogrupować dane tak, żeby to miało ręce i nogi - i powinno
działać. Zrobienie tak jak napisałeś też pewnie zadziała, ale nie
będzie optymalne. Może dla MySQLa nie będzie robić różnicy, ale na
PostgreSQLu lepiej zachowują się rozwiązania znormalizowane.
Co do nieszczęść - jak wszystko jest znormalizowane, łatwiej się
dokumentuje. Całość jest czytelna i jasna. Jak programista odejdzie
używalność czegoś takiego gdzie w jednym worku jest 50 różnych rzeczy
i tylko ten programista wiedział - "dlaczego, z przyczyn historycznych"
typy danych 1 i 6 są tożsame... Jak się doda brak słowników - tabelka
z masą cyferek - robi wrażenie, zwłaszcza jak ma się coś z tym zrobić.
;)
--
Pozdrawiam,
Michał Zaborowski (TeXXaS)
Mwa - 19-02-2007 00:09
Dziękuje za odpowiedź
To było rozwiązanie formularza w PHP mającego po 100 pól (i co gorsze
zleceniodawca wspominał że może je zmienić).
Problem z typami nie występuje praktycznie w PHP (wiem że nie napisałem że
tego urzywam, sorry) zewzględu na "dyskretną" konwersje typów, to więc
trzeba urzyć największego tekstowatego czyli umnie varchar(255)
z relacją 1-1 miałem niemiłe doświadczenie jakiś czas temu na mySQL 4
kiedy to przy kilkudziesięciu tysiącach rekordów baza wisiała, spodziewam
się że na 3 tabelach pewnie było by jeszcze gorzej ;)
co do msSQL to miałem przyjemność się z tym zetknąć kiedy przerabiałem
skrypt php z mySQL na msSQL, wieksze zapytanie na my się wykonywało 2min a
na identycznej strukturze i danych ms 3s ;).
na postGreSQL prawie nie pracuje tylko się troche bawie, ale czytałem na
tej grópie że nowa wersja jest tak samo szybka jak mySQL przy prostych
zapytaniach no a na bardziej złożonych to wiadomo. przy zabawie
pl/pgSQL'em wydaje mi się wolniejszy do t-SQLa ale może pg trzeba jakoś
skonfigurować dodatkowo. co pgSQLa to pewnie będe jeszcze troszke głópich
pytań zadawał na tej grupie
Pozdrawiam Wszystkich
> Witam,
>
> Z opisu i na oko wynika, że można zrobić np. 3-4 tabele w realcji
> 1-1. Pogrupować dane tak, żeby to miało ręce i nogi - i powinno
> działać. Zrobienie tak jak napisałeś też pewnie zadziała, ale nie
> będzie optymalne. Może dla MySQLa nie będzie robić różnicy, ale na
> PostgreSQLu lepiej zachowują się rozwiązania znormalizowane.
>
> Co do nieszczęść - jak wszystko jest znormalizowane, łatwiej się
> dokumentuje. Całość jest czytelna i jasna. Jak programista odejdzie
> używalność czegoś takiego gdzie w jednym worku jest 50 różnych rzeczy
> i tylko ten programista wiedział - "dlaczego, z przyczyn historycznych"
> typy danych 1 i 6 są tożsame... Jak się doda brak słowników - tabelka
> z masą cyferek - robi wrażenie, zwłaszcza jak ma się coś z tym zrobić.
> ;)
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Herakles - 20-02-2007 00:03
Mwa wrote:
> Cześć
>
> Mam projekt który wymagałby po 100 kolumn na rekord więc wykąbinowałem
> strókture z 3 tabelami w pierwszej jest ID "rekordu" i ew. jakieś
> podstawowe dane w drógiej jest lista kolumn a trzecia to tabela łącząca (z
> indexami "unikalny" żeby się nie poplątało) i wartością
fuuuuu
>
> Czy Ktoś mugłby opisać potencjalne nieszczęścia wynikające z takiej
> stróktury ??
> na dzień dobry widze problemy z wydajnością i większe zurzycie miejsca na
> dysku poniewasz te "wirtualne" kolumny mają taką samą długość/typ, co
> jeszcze ??
>
> to jest na mySQL ale jestem też ciekaw opini na pgSQL i msSQL poniewasz
> czasem ich urzywam
>
>
> Pozdrawiam Marcin
>
>
grzesiek - 20-02-2007 00:04
Michał Zaborowski napisał(a):
> Witam,
>
> Z opisu i na oko wynika, że można zrobić np. 3-4 tabele w realcji
> 1-1. Pogrupować dane tak, żeby to miało ręce i nogi - i powinno
> działać. Zrobienie tak jak napisałeś też pewnie zadziała, ale nie
> będzie optymalne. Może dla MySQLa nie będzie robić różnicy, ale na
> PostgreSQLu lepiej zachowują się rozwiązania znormalizowane.
>
> Co do nieszczęść - jak wszystko jest znormalizowane, łatwiej się
> dokumentuje. Całość jest czytelna i jasna. Jak programista odejdzie
> używalność czegoś takiego gdzie w jednym worku jest 50 różnych rzeczy
> i tylko ten programista wiedział - "dlaczego, z przyczyn historycznych"
> typy danych 1 i 6 są tożsame... Jak się doda brak słowników - tabelka
> z masą cyferek - robi wrażenie, zwłaszcza jak ma się coś z tym zrobić.
> ;)
>
Ja natomiast mialem rekord skladajacy sie z ponad 300 kolumn.
Pogrupowalem to na tabele ( okolo 24 jesli dobrze pamietam)i nie dawalem
kluczom wlasciwosci auto_increment, tylko to samo id przypisywane z
poziomu skryptu. O wiele latwiej bylo objac jakos ta baze, a na
wydajnosci moze to i troszke spadlo, ale kto sie polapie w takiej ilosci
kolumn, nie mowiac o pisaniu zapytania. Baza to MySQL.
Jak pisze Michał Zaborowski w moim przypadku zmienil sie programista i
rzeczywiscie biedaczek zalamal sie na sam widok wydruku schematu bazy
danych, ale dzieki pogrupowaniu w tabele latwiej bylo mu to pojac.
Bogdan Parzonko - 20-02-2007 00:04
=?ISO-8859-2?Q?Re:_Dziwne_pomys=B3y_w_SQL_?=
Mwa <noHuman@gazeta.pl> napisał(a):
> Cześć
>
> Mam projekt który wymagałby po 100 kolumn na rekord więc wykąbinowałem
> strókture z 3 tabelami w pierwszej jest ID "rekordu" i ew. jakieś
> podstawowe dane w drógiej jest lista kolumn a trzecia to tabela łącząca (z
> indexami "unikalny" żeby się nie poplątało) i wartością
>
> Czy Ktoś mugłby opisać potencjalne nieszczęścia wynikające z takiej
> stróktury ??
> na dzień dobry widze problemy z wydajnością i większe zurzycie miejsca na
> dysku poniewasz te "wirtualne" kolumny mają taką samą długość/typ, co
> jeszcze ??
>
> to jest na mySQL ale jestem też ciekaw opini na pgSQL i msSQL poniewasz
> czasem ich urzywam
>
>
> Pozdrawiam Marcin
Rozumiem że chciałeś dopisać żę większąć z tych 100 kolumn (kolumny z tej
drugiej tabeli ) będzie miała wartości puste tym samym brak wpisów w tej
trzeciej, co pozwala na zoszczędzenie miejsca, wówczas to może mieć jakiś
sens, ale przy dzisiejszych dyskach gra nie warta swiczki.
Skoro mysql udostępnia 255 kolumn to dlaczego ich nie wykorzystać, z typem
varchar miejsce też zaoszczędzisz. Warto tak jak ktoś wspominał użyć
powiązania realacji/tabel 1 do 1 przy czym tabelę (jej kolumny) roździelić tak
że na pewnych kolumnach w tej drugiej tabeli wykonywane są częste updaty.
Tak bym to zrobił.
pozdrawiam
--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
zanotowane.pldoc.pisz.plpdf.pisz.pleffulla.pev.pl
|
Wydajność baz danych w zależności od poziomu izolacji ANSI/ISO
Czy zna (obsługuje) ktoś program Iso Draw ?
MYSQL - kodowanie w ISO-PL
strona plus baza w iso do utf-8
Kodowanie: z iso na utf
Konwesja znaków w dump'ie bazy danych - ISO -> utf-8 -> ISO -> utf-8
=?iso-8859-2?q?Co_oznacza_b=B3=B1d_Warning:_mysql=5Fconnect() _[function.mysql-connect]:_Can't_connect_to_local_MySQL_server_through_sock et_'/var/run/mysqld/mysqld.sock'_(2)_in?=
=?iso-8859-2?q?Informatyka,_Java,_EJB,_Ajax,_Spring=2E_Czy=BF by_to_koniec_=B6wiata,_czy_te=BF_nasze_uczelnie_b= EAd=B1_uczy=B3y_w_ko=F1cu!_czego_praktycznego_=2E= 2E=2E=2E?=
=?iso-8859-2?q?Ati_Mobility_Radeon_X300_W_Notebooku_Jak_Zwi=E Akszy=E6_Ilo=B6=E6_Grafiki_Poprzez_Wsp=F3=B3dziele nie_Z_Ramu=3F=3F=3F?=
=?ISO-8859-2?Q?=AFegnam_si=EA=2E=2E=2E?=
zanotowane.pldoc.pisz.plpdf.pisz.plown-team.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 |
|
