klucz po uniqueidentifier
pisarczyk - 14-12-2006 16:09
klucz po uniqueidentifier
Witam serdecznie !
Nasz zespó? ma do przepisania istniej?cy i funkcjonuj?cy program w oparciu o
baz? na MS-SQL 2000.
Kiedy mieli?my zacz?? prac? 'na czysto" po okresie wst?pnym w?adza zapoda?a
temat do przemy?lenia:
baza ma by? pod MS-SQL 2005 i zmodyfikowa? tak by klucze g?ówne w tabelach z
dotychczasowych int zmieni? na uniqueidentifier.
Oczywi?cie zastanawiali?my si? nad konsekwencjami:
1. Czy klucze s? skuteczne, trwa?e, tabele/bazy nie uszkadzaj? si??
2. Czy relacje dzia?aj? poprawnie (b?dziemy wykorzystywa? wszystkie rodzaje
relacji) ?
3. Czy nie ma problemu z dwoma i wi?cej tego typu polami w jednej tabeli?
4. Czy nie ma problemu ze zmian? warto?ci pola na null (np. konsekwencja
usuni?cia rodzica, a pozostawienie dzieci)?
Wszyscy cz?onkowie zespo?u w swoich dotychczasowych projektach jako klucze
g?ówne widzieli int, nikt nie ma do?wiadcze? ze stosowaniem uniqueidentifier
jako klucza g?ównego.
Zapewne lista konsekwencji jest d?u?sza, jakie jeszcze mog? nas czeka?
niespodzianki?
Jakie s? Wasze do?wiadczenia?
Pozdrawiam
Darek
Marcin A. Guzowski - 14-12-2006 16:09
pisarczyk napisa?(a):
> Witam serdecznie !
> Nasz zespó? ma do przepisania istniej?cy i funkcjonuj?cy program w oparciu o
> baz? na MS-SQL 2000.
> Kiedy mieli?my zacz?? prac? 'na czysto" po okresie wst?pnym w?adza zapoda?a
> temat do przemy?lenia:
> baza ma by? pod MS-SQL 2005 i zmodyfikowa? tak by klucze g?ówne w tabelach z
> dotychczasowych int zmieni? na uniqueidentifier.
Co do bazy, to decyzja s?uszna, co do kluczy g?ównych na typie
uniqueidentifier - wr?cz przeciwnie.
> Oczywi?cie zastanawiali?my si? nad konsekwencjami:
> 1. Czy klucze s? skuteczne, trwa?e, tabele/bazy nie uszkadzaj? si??
Dziwne pytania.. Je?eli co? jest kluczem, to zak?adamy ?e poci?ga to
za sob? wszystkie konsekwencje takiego stanu. To, ?e uniqeid. troch?
"dziwnie" wygl?da, jeszcze o niczym nie ?wiadczy.
> 2. Czy relacje dzia?aj? poprawnie (b?dziemy wykorzystywa? wszystkie rodzaje
> relacji) ?
j.w., tylko zast?p s?owo "kluczem" s?owem "relacj?"
> 3. Czy nie ma problemu z dwoma i wi?cej tego typu polami w jednej tabeli?
Mia?e? kiedykolwiek taki problem z jakimkolwiek typem danych??
SQL Server (i inne RDBMs) to nie pude?ka z tektury..
> 4. Czy nie ma problemu ze zmian? warto?ci pola na null (np. konsekwencja
> usuni?cia rodzica, a pozostawienie dzieci)?
Na prawd? masz ciekawe pomys?y :)
ps, o NULLach w SQL Serverze:
http://strefa.guzowski.info/archives/25,2006,11,04.html
> Wszyscy cz?onkowie zespo?u w swoich dotychczasowych projektach jako klucze
> g?ówne widzieli int, nikt nie ma do?wiadcze? ze stosowaniem uniqueidentifier
> jako klucza g?ównego.
> Zapewne lista konsekwencji jest d?u?sza, jakie jeszcze mog? nas czeka?
> niespodzianki?
Zasadnicza konsekwencja jest jedna - wydajno??. Skupcie si? na tym, bo
to jest najsilniejszy i jedyny zasadniczy argument.
Uniqueidentifier to szczególny typ danych, jego warto?? wygenerowana
przez funkcj? NEWID() gwarantuje unikalno?? w skali globalnej - i
w?a?nie o to w nim chodzi. Ale nie ma nic za darmo. Uniqueidentifier
jest 4 razy wi?kszy ni? int (16 bajtów).
?elazn? zasad? SQL Servera jest stosowanie jak najmniejszych kluczy
g?ównych - czyli chodzi tak na prawd? o int-a z indentity. Nie wiem
czy wiesz, ale w strukturze fizycznej indeksu nieklastrowanego
(B-tree) strona danych nie jest wskazywana bezpo?rednio. Odbywa si? to
(po?rednio) w?a?nie przez warto?? klucza g?ównego. Je?eli wi?c klucz
g?ówny jest wi?kszy (zamiast 4B intowego jest 16B uniquedentifier),
indeksy maj? po prostu du?o wi?ksze rozmiary. Dla du?ych tabel
przek?ada si? to automatycznie na wydajno??, gdy? na jednej index page
(8KB) mie?ci si? du?o mniej informacji i si?? rzeczy SQL Server b?dzie
potrzebowa? wi?cej odczytów IO do skutecznego skorzystania z indeksu.
Nigdy nie zgodzi?bym si?, ?eby w systemach, za które odpowiadam,
kluczem g?ównym by? uniqueidentifier. Je?eli jest potrzeba jego
stosowania, to ok - niech to b?dzie dodatkowa kolumna z constraintem
UNIQUE lub bez - w zale?no?ci od potrzeb. Klucz g?ówny to rzecz
krytyczna z punktu widzenia wydajno?ci, musi to by? wi?c mo?liwie
ma?ych rozmiarów klucz sztuczny (nigdy naturalny).
--
Pozdrawiam,
Marcin Guzowski
http://guzowski.info
pisarczyk - 14-12-2006 16:10
Witam serdecznie !
> > 1. Czy klucze s? skuteczne, trwa?e, tabele/bazy nie uszkadzaj? si??
> Dziwne pytania.. Je?eli co? jest kluczem, to zak?adamy ?e poci?ga to
> za sob? wszystkie konsekwencje takiego stanu. To, ?e uniqeid. troch?
> "dziwnie" wygl?da, jeszcze o niczym nie ?wiadczy.
To, ?e "dziwnie" wygl?da nie jest dla mnie problemem (cho? w pewnych
sytuacjach jest, ale inna sprawa). Chodzi mi o aspekty techniczne, przede
wszystkich pewne i bezawaryjne dzia?anie bazy.
> > 2. Czy relacje dzia?aj? poprawnie (b?dziemy wykorzystywa? wszystkie
rodzaje
> > relacji) ?
> j.w., tylko zast?p s?owo "kluczem" s?owem "relacj?"
Nie, nie zast?pi?, mia?em na my?li:
1. Klucz: PK
2. Relacja: zwi?zek mi?dzy tabelami
> > 3. Czy nie ma problemu z dwoma i wi?cej tego typu polami w jednej
tabeli?
> Mia?e? kiedykolwiek taki problem z jakimkolwiek typem danych??
> SQL Server (i inne RDBMs) to nie pude?ka z tektury..
Mia?em do czynienia z kilkoma rodzajami, nigdy nie mia?em problemów, bo
zawsze stosowa?em numeric/long/int (w zale?no?ci od rodzaju bazy). Chodzi?o
mi o to, czy skoro pole jest UI dla tabeli to czy DB nie zbiesi si? je?li
b?dzie tam drugie pole UI dla FKey.
> > 4. Czy nie ma problemu ze zmian? warto?ci pola na null (np. konsekwencja
> > usuni?cia rodzica, a pozostawienie dzieci)?
> Na prawd? masz ciekawe pomys?y :)
To nie s? moje pomys?y, jak wcze?niej pisa?em mamy przepisa? ju? istniej?cy
program w oparciu o istniej?c? baz?, nie ja by?em projektantem bazy, nie
mamy pe?nomocnictwa do ingerencji w jej logik?. To stan oficjalny.
Prywatnie: nigdy bym tak bazy nie zaprojektowa?.
> ps, o NULLach w SQL Serverze:
> http://strefa.guzowski.info/archives/25,2006,11,04.html
Tak, oczywi?cie zgadzam si? z Tob?, zapoznawaj?c z problematyk? takich baz
(moje pierwsze to by?y dBaseIII+ i BTrieve, ale kto jeszcze o nich pami?ta)
w literaturze zwracano na to uwag?. Wobec tego projektowa?em je tak by nulle
w ogóle nie wyst?powa?y (prawie mi si? to uda?o).
W tym przypadku jak pisa?em wy?ej nic do bazy nie mog? mie?, pracodawca
b?dzie ponosi? konsekwencje decyzji.
> Zasadnicza konsekwencja jest jedna - wydajno??. Skupcie si? na tym, bo
> to jest najsilniejszy i jedyny zasadniczy argument.
Jest to aplikacja zbli?ona swym charakterem do ERP, wielko?? u?ytkownika
odpowiada mniej wi?cej ?redniemu (lub ciut wi?kszemu) przedsi?biorstwu, nie
b?dzie tam milionów rekordów. Natomiast ma to by? aplikacja webowa,
zwróci?em wi?c uwag? na zwi?kszenie ilo?ci w transmisji danych. Troch? mnie
martwi brak konsekwencji u pracodawcy. Najpierw za?o?enie by?o takie by dba?
o wydajno?? (m.in. równie? mia?a by? mo?liwo?? pracy na ipodach w terenie),
a teraz przy mojej uwadze o ilo?ci przep?ywaj?cych danych problem sta? si?
nie istotny.
> Uniqueidentifier to szczególny typ danych, jego warto?? wygenerowana
> przez funkcj? NEWID() gwarantuje unikalno?? w skali globalnej - i
> w?a?nie o to w nim chodzi. Ale nie ma nic za darmo. Uniqueidentifier
> jest 4 razy wi?kszy ni? int (16 bajtów).
Tak, wiem pisa?em o tym wy?ej.
> ?elazn? zasad? SQL Servera jest stosowanie jak najmniejszych kluczy
> g?ównych - czyli chodzi tak na prawd? o int-a z indentity. Nie wiem
> czy wiesz, ale w strukturze fizycznej indeksu nieklastrowanego
> (B-tree) strona danych nie jest wskazywana bezpo?rednio. Odbywa si? to
> (po?rednio) w?a?nie przez warto?? klucza g?ównego. Je?eli wi?c klucz
> g?ówny jest wi?kszy (zamiast 4B intowego jest 16B uniquedentifier),
> indeksy maj? po prostu du?o wi?ksze rozmiary. Dla du?ych tabel
> przek?ada si? to automatycznie na wydajno??, gdy? na jednej index page
> (8KB) mie?ci si? du?o mniej informacji i si?? rzeczy SQL Server b?dzie
> potrzebowa? wi?cej odczytów IO do skutecznego skorzystania z indeksu.
Tak, to jest oczywiste.
> Nigdy nie zgodzi?bym si?, ?eby w systemach, za które odpowiadam,
Ja jestem tylko programist? :)
Na swoim tak udawa?o mi si? bazy projektowa?, ?e nie mia?em nigdy z nimi
?adnych problemów (tak w sensie technicznym jak i merytorycznym). Problemem
by?o tylko czego klient jeszcze b?dzie potrzebowa? i ile da czasu na
realizacj?.
> kluczem g?ównym by? uniqueidentifier. Je?eli jest potrzeba jego
> stosowania, to ok - niech to b?dzie dodatkowa kolumna z constraintem
> UNIQUE lub bez - w zale?no?ci od potrzeb. Klucz g?ówny to rzecz
> krytyczna z punktu widzenia wydajno?ci, musi to by? wi?c mo?liwie
> ma?ych rozmiarów klucz sztuczny (nigdy naturalny).
Dok?adnie podzielam Twój pogl?d.
Dzi?ki za zainteresowanie. Szczerze pisz?c to czeka?em na m.in. Twojego
posta.
Pozdrawiam
Darek
Marcin A. Guzowski - 14-12-2006 16:10
pisarczyk napisa?(a):
> To, ?e "dziwnie" wygl?da nie jest dla mnie problemem (cho? w pewnych
> sytuacjach jest, ale inna sprawa). Chodzi mi o aspekty techniczne, przede
> wszystkich pewne i bezawaryjne dzia?anie bazy.
Stara?em Ci si? tylko powiedzie?, ?e typ kolumny, na której jest
ustawiony PK w tabeli/tabelach nie ma wp?ywu na pewno??/bezawaryjno??
dzia?ania bazy.
>>> 2. Czy relacje dzia?aj? poprawnie (b?dziemy wykorzystywa? wszystkie
> rodzaje
>>> relacji) ?
>> j.w., tylko zast?p s?owo "kluczem" s?owem "relacj?"
> Nie, nie zast?pi?, mia?em na my?li:
> 1. Klucz: PK
> 2. Relacja: zwi?zek mi?dzy tabelami
Tak te? to zrozumia?em. Chodzi?o mi o to, ?eby? nie martwi? si?
realizacj? jakichkolwiek constraintów na poziomie technicznym -
niezale?nie od typu kolumn. SQL Server to nie zabawka i produkt jest
ju? na tyle dojrza?y, ?e mo?na mu zaufa? w tym wzgl?dzie.
>>> 4. Czy nie ma problemu ze zmian? warto?ci pola na null (np. konsekwencja
>>> usuni?cia rodzica, a pozostawienie dzieci)?
>> Na prawd? masz ciekawe pomys?y :)
> To nie s? moje pomys?y, jak wcze?niej pisa?em mamy przepisa? ju? istniej?cy
Pomys?y nie Twoje, ale bezpodstawne obawy - tak :)
>> ps, o NULLach w SQL Serverze:
>> http://strefa.guzowski.info/archives/25,2006,11,04.html
> Tak, oczywi?cie zgadzam si? z Tob?, zapoznawaj?c z problematyk? takich baz
> (moje pierwsze to by?y dBaseIII+ i BTrieve, ale kto jeszcze o nich pami?ta)
> w literaturze zwracano na to uwag?. Wobec tego projektowa?em je tak by nulle
> w ogóle nie wyst?powa?y (prawie mi si? to uda?o).
NULLi nie wyeliminujesz z ?ycia i logiki bazy. By?a ostatnio o tym
wi?ksza dyskusja na tej grupie - pad?o kilka celnych uwag. Nawet kiedy
usuniesz NULLe z tabel przez przeró?ne DEFAULTy, to i tak NULL pojawi
si? np. w sytuacji LEFT JOINa. Z NULLami wi?c nie walczymy, tylko
podpisujemy traktat pokojowy i si? do niego stosujemy :)
> W tym przypadku jak pisa?em wy?ej nic do bazy nie mog? mie?, pracodawca
> b?dzie ponosi? konsekwencje decyzji.
>
>> Zasadnicza konsekwencja jest jedna - wydajno??. Skupcie si? na tym, bo
>> to jest najsilniejszy i jedyny zasadniczy argument.
> Jest to aplikacja zbli?ona swym charakterem do ERP, wielko?? u?ytkownika
> odpowiada mniej wi?cej ?redniemu (lub ciut wi?kszemu) przedsi?biorstwu, nie
> b?dzie tam milionów rekordów.
Szczerze mówi?c ja bym si? ba? zak?ada?, ?e w systemie typu ERP nie
pojawi si? pr?dzej czy pó?niej milion rekordów.
>> Nigdy nie zgodzi?bym si?, ?eby w systemach, za które odpowiadam,
> Ja jestem tylko programist? :)
Po pierwsze - nie "tylko", lecz "a?".
Po drugie - skoro wyja?ni?e?, ?e nie jeste? koderem, który wklepuje
tylko kod, a - programist? (deweloperem, wi?c i specjalist? IT),
którego g?ównym zadaniem jest my?lenie i kombinowanie:
to wychodzi nam na to, ?e powiniene? reagowa? w sytuacji pojawiania
si? rze?by na horyzoncie. Przynajmniej ja tak widz? misj? tego zawodu :)
> Dzi?ki za zainteresowanie. Szczerze pisz?c to czeka?em na m.in. Twojego
> posta.
Mi?o mi to s?ysze?, w ka?dym razie ja bym na Twoim miejscu jeszcze
troch? powalczy? z decydentami o te klucze - oczywi?cie - poprzez
dyskusj? na argumenty, a nie np. zastosowanie strajku g?odowego :)
Wydaje mi si?, ?e na takiej zasadzie powinien zachowywa? si? ka?dy
profesjonalista/fachowiec w swojej dziedzinie.
--
Pozdrawiam,
Marcin Guzowski
http://guzowski.info
pisarczyk - 14-12-2006 16:10
> Stara?em Ci si? tylko powiedzie?, ?e typ kolumny, na której jest
> ustawiony PK w tabeli/tabelach nie ma wp?ywu na pewno??/bezawaryjno??
> dzia?ania bazy.
> Chodzi?o mi o to, ?eby? nie martwi? si?
> realizacj? jakichkolwiek constraintów na poziomie technicznym -
> niezale?nie od typu kolumn.
W?a?nie oczekiwa?em jasnej deklaracji. Pod?o?ysz g?ow?/r?k? (zale?y od
przys?owia) skoro takiej kombinacji nie stosowa?e??
> SQL Server to nie zabawka i produkt jest
> ju? na tyle dojrza?y, ?e mo?na mu zaufa? w tym wzgl?dzie.
W?a?nie obawy o dojrza?o?? by?y jednym z powodów zadania pytania.
> Pomys?y nie Twoje, ale bezpodstawne obawy - tak :)
Dzi?ki, ?e rozwia?e? moje obawy. Sorry, ale ?ycie nauczy?o mnie zachowywa?
ostro?no??.
> NULLi nie wyeliminujesz z ?ycia i logiki bazy. By?a ostatnio o tym
> wi?ksza dyskusja na tej grupie - pad?o kilka celnych uwag.
Musia?em przeoczy? w?tek, mo?esz przypomnie? jego tytu??
> >> Zasadnicza konsekwencja jest jedna - wydajno??. Skupcie si? na tym, bo
> >> to jest najsilniejszy i jedyny zasadniczy argument.
Zobaczymy na ile w?adza jest elastyczna. Osobi?cie uwa?am si? za
projektanta/programist? bardziej do?wiadczonego od w?adzy, ale jestem nowy,
wi?c zastosuj? stare przepisy o prze?o?onych w pkt. 1 i 2.
> Szczerze mówi?c ja bym si? ba? zak?ada?, ?e w systemie typu ERP nie
> pojawi si? pr?dzej czy pó?niej milion rekordów.
Oczywi?cie takiego za?o?enia nie przyjmuj?, ale my?l? ?e zanim user wpisze
tyle danych to sprz?t zd??y zmieni?, i jeszcze w?tpliwe czy z powodu tej
aplikacji.
> > Ja jestem tylko programist? :)
> Po pierwsze - nie "tylko", lecz "a?".
> Po drugie - skoro wyja?ni?e?, ?e nie jeste? koderem, który wklepuje
> tylko kod, a - programist? (deweloperem, wi?c i specjalist? IT),
> którego g?ównym zadaniem jest my?lenie i kombinowanie:
> to wychodzi nam na to, ?e powiniene? reagowa? w sytuacji pojawiania
> si? rze?by na horyzoncie. Przynajmniej ja tak widz? misj? tego zawodu :)
Jak pisa?em wcze?niej decyzja nale?y do w?adzy, b?dzie okazja przekona? si?
jak? si?? maj? argumenty merytoryczne.
> Mi?o mi to s?ysze?, w ka?dym razie ja bym na Twoim miejscu jeszcze
> troch? powalczy? z decydentami o te klucze - oczywi?cie - poprzez
> dyskusj? na argumenty, a nie np. zastosowanie strajku g?odowego :)
Trzymaj kciuki :)
> Wydaje mi si?, ?e na takiej zasadzie powinien zachowywa? si? ka?dy
> profesjonalista/fachowiec w swojej dziedzinie.
Niestety, dziwny gatun ze mnie. Nie mam seksualnego podej?cia do pracy.
Ogl?da?em Twoj? stron?. Napisa?e? m.in. ?e piszesz w ASP.NET. Mo?esz
zdradzi? czy stosujesz dodatkowe kontrolki, a je?li tak to które? Najpierw
wypracowywali?my metody post?powania dla standardowych, teraz w?adza
zasugerowa?a mo?liwo?? przegl?dni?cia i zakupu dodatkowych. ?ci?gn?li?my
demo z telerik.com i jeste?my pod wra?eniem, wszystkie metody wypracowali?my
w ci?gu jednego dnia ! Czy mo?esz zasugerowa? jeszcze lepsze?
Pozdrawiam
Darek
Marcin A. Guzowski - 14-12-2006 16:10
pisarczyk napisa?(a):
>> Chodzi?o mi o to, ?eby? nie martwi? si?
>> realizacj? jakichkolwiek constraintów na poziomie technicznym -
>> niezale?nie od typu kolumn.
> W?a?nie oczekiwa?em jasnej deklaracji. Pod?o?ysz g?ow?/r?k? (zale?y od
> przys?owia) skoro takiej kombinacji nie stosowa?e??
Pod?o?? paznokie?. Spor? cz??? czasu w pracy sp?dzam na testowaniu
ró?nych pozornie dziwnych rozwi?za?, szukanie dziury w ca?ym itd.,
tak?e robi?em ju? ró?ne numery z PK i nigdy SQL Server si? nie rozjecha?.
>> NULLi nie wyeliminujesz z ?ycia i logiki bazy. By?a ostatnio o tym
>> wi?ksza dyskusja na tej grupie - pad?o kilka celnych uwag.
> Musia?em przeoczy? w?tek, mo?esz przypomnie? jego tytu??
W?tek:
[SQL] A gdybym zawsze tworzy? kolumny typu NOT NULL...
(Message-ID: <ekovjq$dma$1@atlantis.news.tpi.pl>)
>>>> Zasadnicza konsekwencja jest jedna - wydajno??. Skupcie si? na tym, bo
>>>> to jest najsilniejszy i jedyny zasadniczy argument.
> Zobaczymy na ile w?adza jest elastyczna. Osobi?cie uwa?am si? za
> projektanta/programist? bardziej do?wiadczonego od w?adzy, ale jestem nowy,
> wi?c zastosuj? stare przepisy o prze?o?onych w pkt. 1 i 2.
Jak jeste? tam nowy, to masz ?wietn? okazj? zab?ysn?? :)
>> Szczerze mówi?c ja bym si? ba? zak?ada?, ?e w systemie typu ERP nie
>> pojawi si? pr?dzej czy pó?niej milion rekordów.
> Oczywi?cie takiego za?o?enia nie przyjmuj?, ale my?l? ?e zanim user wpisze
> tyle danych to sprz?t zd??y zmieni?, i jeszcze w?tpliwe czy z powodu tej
> aplikacji.
Najci??szych problemów wydajno?ciowych baz danych do?o?eniem sprz?tu
si? nie rozwi??e (sprawdzone empirycznie..). Tylko m?dry database
design jest gwarantem sukcesu (zabrzmia?o jak reklama).
>> Wydaje mi si?, ?e na takiej zasadzie powinien zachowywa? si? ka?dy
>> profesjonalista/fachowiec w swojej dziedzinie.
> Niestety, dziwny gatun ze mnie. Nie mam seksualnego podej?cia do pracy.
Widzisz w tym podej?ciu cho? odrobin? sexu? :)
> Ogl?da?em Twoj? stron?. Napisa?e? m.in. ?e piszesz w ASP.NET. Mo?esz
> zdradzi? czy stosujesz dodatkowe kontrolki, a je?li tak to które?
Zale?y do czego. Zd??y?em si? przekona?, ?e czasem lepsze efekty daje
zrobienie w?asnej kontrolki na bazie prostego DataGrida, ni?
podci?ganie pod okre?lon? funkcjonalno?? komercyjnych skomplikowanych
"kombajnów".
Je?eli chodzi o komercyjne produkty, to do weba stosowali?my kontrolki
z Devexpressu (http://www.devexpress.com). To ca?a rodzina produktów,
rozwijaj? je bardzo dynamicznie - na pewno warto si? im przyjrze?
dok?adniej. Mam jednak mieszane uczucia, ale to mo?e nie by?a wina
samych kontrolek, tylko dziwnych potrzeb funkcjonalnych, których jak
si? okaza?o - aplikacja webowa nie by?a w stanie sensownie realizowa?. Ps.
Wed?ug mnie DX ma na pewno fajnie kontrolki do desktopa.
> Najpierw
> wypracowywali?my metody post?powania dla standardowych, teraz w?adza
> zasugerowa?a mo?liwo?? przegl?dni?cia i zakupu dodatkowych. ?ci?gn?li?my
> demo z telerik.com i jeste?my pod wra?eniem, wszystkie metody wypracowali?my
> w ci?gu jednego dnia ! Czy mo?esz zasugerowa? jeszcze lepsze?
Wszystko zale?y od potrzebnych funkcjonalno?ci. Je?eli s? w miar?
standardowe, to jeste?my w domu - zastosowanie gotowych kontrolek
komercyjnych znacznie skraca czas produkcji. Je?eli jednak trzeba je
przerabia?, to mo?e to by? du?o trudniejsze ni? zrobienie w?asnych
kontrolek bazuj?cych na tych darmowych (niekoniecznie z Frameworka).
--
Pozdrawiam,
Marcin Guzowski
http://guzowski.info
pisarczyk - 24-12-2006 00:36
> Podłożę paznokieć.
:)
> Sporą część czasu w pracy spędzam na testowaniu
> różnych pozornie dziwnych rozwiązań, szukanie dziury w całym itd.,
> także robiłem już różne numery z PK i nigdy SQL Server się nie rozjechał.
to kolejna dobra wiadomość
> [SQL] A gdybym zawsze tworzył kolumny typu NOT NULL...
Dzięki przeczytam ...
> Najcięższych problemów wydajnościowych baz danych dołożeniem sprzętu
> się nie rozwiąże (sprawdzone empirycznie..). Tylko mądry database
> design jest gwarantem sukcesu (zabrzmiało jak reklama).
nie jak reklama, tylko jak dobra rada dla mniej doświadczonych
> Jeżeli chodzi o komercyjne produkty, to do weba stosowaliśmy kontrolki
> z Devexpressu (http://www.devexpress.com). To cała rodzina produktów,
> rozwijają je bardzo dynamicznie - na pewno warto się im przyjrzeć
> dokładniej. Mam jednak mieszane uczucia, ale to może nie była wina
> samych kontrolek, tylko dziwnych potrzeb funkcjonalnych, których jak
> się okazało - aplikacja webowa nie była w stanie sensownie realizować. Ps.
> Według mnie DX ma na pewno fajnie kontrolki do desktopa.
Te kontrolki również przeglądnęliśmy. Zdaniem wszystkich z telerika mają
większe możliwości.
> Wszystko zależy od potrzebnych funkcjonalności. Jeżeli są w miarę
> standardowe, to jesteśmy w domu - zastosowanie gotowych kontrolek
> komercyjnych znacznie skraca czas produkcji. Jeżeli jednak trzeba je
> przerabiać, to może to być dużo trudniejsze niż zrobienie własnych
> kontrolek bazujących na tych darmowych (niekoniecznie z Frameworka).
Dokładnie tak, przerabiałem taki temat (ale w innym nrzędziu).
Jeszcze raz dzięki za cenne uwagi.
Pozdrawiam
Darek
zanotowane.pldoc.pisz.plpdf.pisz.pleffulla.pev.pl
|
teoria, klucz obcy jako glowny oraz hibernate
[pgsql] Klucz glowny bedacy referencja???
Postgres, widok i klucz obcy do niego
Klucz złożony - prosba o wzor create
[pgsql] Kolumny unique =?ISO-8859-2?Q?dw=F3ch_tabel?=
MS SQL i unique (nie pozwala na wstawienie dwa razy null)
Klucz główny tekstowy czy int?
[MSSQL 2000] procedura kopiująca rekordy i indeks UNIQUE
Złączenie i klucz złożony
MySQL - klucz glowny
zanotowane.pldoc.pisz.plpdf.pisz.plmelooonka.opx.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 |
|
