Pytanie o klucze baz
Jacek Czerwinski
Teoria relacyjnych baz danych, jak m�wi o kluczach, nigdzie nie m�wi,
�e klucz (pierwotny, obcy, jakikolwiek) musi byc tylko na jednej
kolumnie. Wielokolumnowy tez jest pe�noprawnym kluczem.
Praktyka, na czele z MS-SQL z kt�rym ostatnio cz�sto si� spotykam,
niemal wymusza pojedynczy klucz pierwotny (automatycznie wype�niany,
liczbowy i niezmienny).
Jest podej�cie obiektowe i mapowanie danych, wydaje mi si�, �e znane mi
rozwi�zania bardzo lubi� pojedynczy klucz. cho�by dlatego, �e bardzo
�atwo go wype�ni� dla nowych rekord�w. Z wielokolumnowym dla 2,3 kolumny
ju� jest mocne zastanawianie, czym to wype�ni�.
Automatyczny integer czy klucz o "sensie aplikacyjnym" ? String,
kategoria, typ itd.
Jak na to patrze�, pomi�dzy teori� a praktyk�?
Krzysztof Warunek
> Nie za bardzo ta grupa, ale na grupie baz nie bywam ...
po warzywa...? Bo mo�e w warzywniaku te� nie bywasz.
Ale swoje 5gr dorzucďż˝ do tematu, choďż˝ nijak siďż˝ ma do
programowania stricte.
> Teoria relacyjnych baz danych, jak m�wi o kluczach, nigdzie nie m�wi, �e
> klucz (pierwotny, obcy, jakikolwiek) musi byc tylko na jednej kolumnie.
> Wielokolumnowy tez jest pe�noprawnym kluczem.
K�aniaj� si� mechanizmy dzia�ania.
> Praktyka, na czele z MS-SQL z kt�rym ostatnio cz�sto si� spotykam,
> niemal wymusza pojedynczy klucz pierwotny (automatycznie wype�niany,
> liczbowy i niezmienny).
co w tym z�ego?
> Jest podej�cie obiektowe i mapowanie danych, wydaje mi si�, �e znane mi
> rozwi�zania bardzo lubi� pojedynczy klucz
warto poczytaďż˝:
http://en.wikipedia.org/wiki/Object_database
http://en.wikipedia.org/wiki/Object_Role_Modeling
> Automatyczny integer czy klucz o "sensie aplikacyjnym" ? String,
> kategoria, typ itd.
czym dla ciebie jest "sens aplikacyjny" czy jest ponad acid?
Temat z kosmosu. Po, co n-kolumnowy klucz skoro nie poda�e� sensu
jego istnienia - bo z Twojej wypowiedzi przebija, wi�cej=lepiej -
cho� �adnego praktycznego, ba nawet teoretycznego przyk�adu nie
poda�e�, co pozwala w�tpi� w to czy rozumiesz s�owo klucz.
http://en.wikipedia.org/wiki/Alternate_key
http://en.wikipedia.org/wiki/Primary_key
http://en.wikipedia.org/wiki/Relational_model
--
Krzysztof Warunek
Jacek Czerwinski
> W dniu 2009-12-17 13:56, Jacek Czerwinski pisze:
>> Praktyka, na czele z MS-SQL z kt�rym ostatnio cz�sto si� spotykam,
>> niemal wymusza pojedynczy klucz pierwotny (automatycznie wype�niany,
>> liczbowy i niezmienny).
> co w tym z�ego?
Raczej dobrego, do�� to pozytywnie odbieram.
>> Automatyczny integer czy klucz o "sensie aplikacyjnym" ? String,
>> kategoria, typ itd.
> czym dla ciebie jest "sens aplikacyjny" czy jest ponad acid?
[kategoria towaru] + [symbol magazynowy], uchwytne pogl�dowo dane �wiata
'rzeczywistego' - jako klucz pierwotny (versus abstrakcyjny Id).
To jest m�j "sens aplikacyjny".
z ACID-em nie k��ci si� to w moich oczach za bardzo (wymaga drobnych
zabieg�w programistycznych, staranno�ci, obs�ugi wyj�tk�w itd). Widzisz
jaki� istotny konflikt? w og�le ACID to chyba nie jest zagadnienie
bliskie kluczom
Znam aplikacje (akurat starsze) tak zaprojektowane (w/w wymagania sďż˝
odniesione na wymagania bazy danych: unikalno�c, obcy, not null, to jest ok)
Znam (nowsze) nastawione na pojedynczy klucz liczbowy, zwďż˝. na MS-SQL.
NIE WIEM czy moje spostrze�enie takiego przemieszczania si� (praktyki)
na linii stare-nowe mam prawo uog�lnia� (przy czym teoria jest nadal nie
naruszona).
St�d ten - �wiadomie og�lny - w�tek.
> co pozwala w�tpi� w to czy rozumiesz s�owo klucz.
jakoďż˝ tam wyrabiam intelektualnie.
Dzi�ki za linki, potwierdzi�y si� m.in. moje niejasne odczucia, �e OOP i
ORM (=Object Relational Mapping bo dwuznaczny skr�t) wp�ywa jako
argument za wyborem automatycznego, pojedynczego, niezmiennego klucza
integerowego. Skoro tak, to jestem (przynajmniej mniej wi�cej) zdrowy
psychicznie.
Mi�dzy innymi (dla wyznawc�w teorii spiskowych) oznacza to, ze nie tylko
MS stoi za tym integerem.
Aha, temat nie wzi�� si� z kosmosu, tylko z dyskusji kawowo-projektowej.
Mateusz Loskot
news:hgdlor$ndl$1...@news.onet.pl...
> Krzysztof Warunek pisze:
>> W dniu 2009-12-17 13:56, Jacek Czerwinski pisze:
>
>>> Praktyka, na czele z MS-SQL z kt�rym ostatnio cz�sto si� spotykam,
>>> niemal wymusza pojedynczy klucz pierwotny (automatycznie wype�niany,
>>> liczbowy i niezmienny).
>> co w tym z�ego?
>
> Raczej dobrego, do�� to pozytywnie odbieram.
Widzia�em "standardy kodowania" dla baz, gdzie
automagicznie generowany klucz jest wr�cz zalecany
i oczywi�cie niezmienny w trakcie jakichkolwiek operacji typu UPDATE
Istniej� sytuacje w kt�rych klucz g��wny (primary key) w og�le nie jest
ustalany a istnieje kilka kombinacji (candidate key) pozwalaj�ce
na unikalne ustalenie rekordu, zale�nie od potrzeb i zapyta�.
Pozdrawiam
--
Mateusz Loskot, http://mateusz.loskot.net
pl.comp.lang.c FAQ: http://pl.cpp.wikia.com/wiki/FAQ
C++ FAQ: http://parashift.com/c++-faq-lite
Krzysztof Warunek
>Widzisz jaki� istotny konflikt? w og�le ACID to chyba nie jest
>zagadnienie bliskie kluczom
po stronie systemu bazodanowego. je�eli system wymaga CK int
po to �eby zapewni� acid, wydajno��, szybko�� to nie widz� w tym
problemu np. czyt. ni�ej.
Zresztďż˝ byďż˝ taki programik dbm.exe(czy jakoďż˝ tak) od Nantucket
w pakiecie z Clipperem - do tworzenia tabel, przy zapisywaniu
pytaďż˝ czy na pewno zapisywaďż˝, bo nie ma PK int.
Przy RDBMS sprawa wygl�da jeszcze bardziej skomplikowanie.
> Mi�dzy innymi (dla wyznawc�w teorii spiskowych) oznacza to, ze nie tylko
> MS stoi za tym integerem.
za tym stoi, kt�ry� z wielkich dBase, paradoxx, foxpro - nie pami�tam,
kt�ry - zak�ada� pole int+key niejawnie, je�li takie nie zosta�o
zdefiniowane
Przy dzisiejszych RDBMS sprawa wygl�da jeszcze bardziej skomplikowanie.
> Aha, temat nie wzi�� si� z kosmosu, tylko z dyskusji kawowo-projektowej.
;)
wloochacz
> "Jacek Czerwinski" <x...@y.z.pl> wrote in message
> news:hgdlor$ndl$1...@news.onet.pl...
>> Krzysztof Warunek pisze:
>>> W dniu 2009-12-17 13:56, Jacek Czerwinski pisze:
>>
>>>> Praktyka, na czele z MS-SQL z kt�rym ostatnio cz�sto si� spotykam,
>>>> niemal wymusza pojedynczy klucz pierwotny (automatycznie wype�niany,
>>>> liczbowy i niezmienny).
>>> co w tym z�ego?
>>
>> Raczej dobrego, do�� to pozytywnie odbieram.
>
> Widzia�em "standardy kodowania" dla baz, gdzie
> automagicznie generowany klucz jest wr�cz zalecany
> i oczywi�cie niezmienny w trakcie jakichkolwiek operacji typu UPDATE
>
> Istniej� sytuacje w kt�rych klucz g��wny (primary key) w og�le nie jest
> ustalany a istnieje kilka kombinacji (candidate key) pozwalaj�ce
> na unikalne ustalenie rekordu, zale�nie od potrzeb i zapyta�.
jeden-do-wielu? Za pomoca triggera? Fuj - jeszcze trzeba by dodaďż˝ indeks
dodac na tej nowej tabelce, bo inaczej wyszukiwanie b�dzie si� �limaczy�...
Poza tym pytaczowi nie chodzi�o o candidate key, tylko o natural primary
key - imo.
Generalnie - ca�y temat rozbija si� o dwie kwestie:
1) klucz naturalny jest wygodny, poniewa� nie trzeba ��czy� tabel, �eby
user widzia� co to za id jest. On to po prostu widzi. Wada to taka, �e
to user powinien taki klucz zak�ada� - inaczej nie ma sensu, bo
dochodzimy do generowanego automagicznie (identity, guid)
2) klucz z�o�ony, czasem wydaje si� dobrym pomys�em - do czasu je�li nie
zechcemy doda� podrz�dnej tabeli i zdefiniowa� klucza obcego - trzeba te
wszystkie warto�ci z tabli nadrz�dnej piecz�owicie przepisa� do
podrz�dnej. A na dodatek informacja jest nadmiarowa.
IMO zamiast podstawowego klucza z�o�onego, lepiej zrobi� sztyczny PK +
ograniczenie typu unique.
Co do kluczy naturalnych - czasem, ale to naprawdďż˝ czasami - jest
przydatny i to naprawd� zale�y od tego co to za aplikacja i jakiego
rodzaju dane obrabia.
Znam pewien ERP, gdzie PK (i ID w app) jest tylko i wy��cznie kluczem
naturalnym - user musi wszystko wpisa� z �apy (id towaru, id klienta, id
magazynu itd.). I to dzia�a i nawet mi to nie przeszkadza :)
--
wloochacz
HillBilly
"wloochacz" <wloo...@nospam.dgbit.spameromnie.pl> wrote in message
news:hge1fj$6n9$1...@inews.gazeta.pl...
.
>
> IMO zamiast podstawowego klucza z�o�onego, lepiej zrobi� sztyczny PK +
> ograniczenie typu unique.
> Co do kluczy naturalnych - czasem, ale to naprawdďż˝ czasami - jest
> przydatny i to naprawd� zale�y od tego co to za aplikacja i jakiego
> rodzaju dane obrabia.
> Znam pewien ERP, gdzie PK (i ID w app) jest tylko i wy��cznie kluczem
> naturalnym - user musi wszystko wpisa� z �apy (id towaru, id klienta, id
> magazynu itd.). I to dzia�a i nawet mi to nie przeszkadza :)
>
Raz si� ju� przejecha�em w �yciu na naturalnym PK i w �yciu tego b��du nie
pope�ni�. Nawet je�li w pierwszej fazie wydaje si� to �wietnym pomys�em, to
potem odbija si� to niez�� czkawk�, szczeg�lnie, gdy dochodzi do wszelkiej
ma�ci jego modyfikacji. Dlatego z urz�du polecam tw�r: automagiczny
PK+ograniczenie unique na kolumnie, kt�ra mog�aby by� PK. To samo tyczy si�
tabel z kluczem wielokolumnowym. �adnych kluczy naturalnych.
--
newsik
Bronek Kozicki
> Nie za bardzo ta grupa, ale na grupie baz nie bywam ...
>
> Teoria relacyjnych baz danych, jak m�wi o kluczach, nigdzie nie m�wi, �e
> klucz (pierwotny, obcy, jakikolwiek) musi byc tylko na jednej kolumnie.
> Wielokolumnowy tez jest pe�noprawnym kluczem.
>
> Praktyka, na czele z MS-SQL z kt�rym ostatnio cz�sto si� spotykam,
> niemal wymusza pojedynczy klucz pierwotny (automatycznie wype�niany,
> liczbowy i niezmienny).
nie, nieprawda. Przynajmniej taka nie jest _moja_ praktyka. Chociaďż˝
przyznaje, dla wielkich tabel (miliony wierszy), jednokolumnowy klucz
jest bardziej praktyczny.
B.
wloochacz
ma �adnego problemu. Dobrym przyk�adem takiej bazy jest Firebird, z�ym - MS SQL w dowolnej wersji.
--
wloochacz
Mateusz Ludwin
> Nie za bardzo ta grupa, ale na grupie baz nie bywam ...
>
> Teoria relacyjnych baz danych, jak m�wi o kluczach, nigdzie nie m�wi,
> �e klucz (pierwotny, obcy, jakikolwiek) musi byc tylko na jednej
> kolumnie. Wielokolumnowy tez jest pe�noprawnym kluczem.
>
> Praktyka, na czele z MS-SQL z kt�rym ostatnio cz�sto si� spotykam,
> niemal wymusza pojedynczy klucz pierwotny (automatycznie wype�niany,
> liczbowy i niezmienny).
To u�ywaj Oracle, proste.
> Jest podej�cie obiektowe i mapowanie danych, wydaje mi si�, �e znane mi
> rozwi�zania bardzo lubi� pojedynczy klucz. cho�by dlatego, �e bardzo
> �atwo go wype�ni� dla nowych rekord�w. Z wielokolumnowym dla 2,3 kolumny
> ju� jest mocne zastanawianie, czym to wype�ni�.
>
> Automatyczny integer czy klucz o "sensie aplikacyjnym" ? String,
> kategoria, typ itd.
>
> Jak na to patrze�, pomi�dzy teori� a praktyk�?
Klucze wielokolumnowe to standard z punktu widzenia baz danych, ale nie ORM. Na
poziomie SQL stosowanie takich kluczy jest naturalne i oczywiste, bo pracujesz
na poziomie wierszy. Wyobra� sobie np. tr�jwymiarowe dane w jednej tabeli -
klucz trzykolumnowy jest oczywisty.
W j�zyku obiektowym to si� �rednio sprawdza, bo zwykle i tak pobiera si� kawa�ek
grafu obiekt�w. Po prostu model dla ORM jest z punktu widzenia relacyjnych baz
danych bardzo prymitywnym modelem.
--
Mateusz Ludwin mateuszl [at] gmail [dot] com
gregorius
Pozdrawiam
--
gregorius
Odpowiadaj�c usu� spamerom_nie. z adresu.