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).

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ą?

do góry

W dniu 2009-12-17 13:56, Jacek Czerwinski pisze:
> Nie za bardzo ta grupa, ale na grupie baz nie bywam ...
to jesteś usprawiedliwiony. Idziesz do mięsnego,
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

http://tocheckserver.pl

do góry

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.



>> 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.

do góry

"Jacek Czerwinski" <...@...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ń.

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

do góry

W dniu 2009-12-17 17:20, Jacek Czerwinski pisze:
>Widzisz jakiś istotny konflikt? w ogóle ACID to chyba nie jest
>zagadnienie bliskie kluczom
nie tyle konflikt, ile istotę działania i organizację danych
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.
;)

--
Krzysztof Warunek

http://tocheckserver.pl

do góry

Mateusz Loskot pisze:
> "Jacek Czerwinski" <...@...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ń.
To nie jest dobry pomysł - nigdy; jak do takiej tabeli dodać relację np.
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

do góry

"wloochacz" <w...@n...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

do góry

On 17/12/2009 12:56, Jacek Czerwinski wrote:
> 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.

do góry

W dniu 2009-12-17 21:10, HillBilly pisze:
>
> "wloochacz" <w...@n...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.
E tam - bez przesady. Jeśli ma się do czynienia z bazą danych, która porządnie
obsługuje kaskadową aktualizację, to nie
ma żadnego problemu. Dobrym przykładem takiej bazy jest Firebird, złym - MS SQL w
dowolnej wersji.

--
wloochacz

do góry

Jacek Czerwinski wrote:
> 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

do góry