klucze glowne zlozone
jivanmukt...@poczta.onet.pl
przyzwyczajony do takiego projektowania bazy danych, ale ostatnio znajomy
zwrocil mi uwage, ze lepiej jest uzyc prostego klucza autoincrement.
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl
geos
> Czy stosowanie kluczy primary zlozonych z wielu pol ma jakies wady? Jestem
> przyzwyczajony do takiego projektowania bazy danych, ale ostatnio znajomy
> zwrocil mi uwage, ze lepiej jest uzyc prostego klucza autoincrement.
od strony teoretycznej nie ma przeciwwskazań. problem pojawia się gdy
taki klucz złożony jednej encji identyfikuje inną encję w modelu, a ta z
kolei jeszcze inną itp. klucze propagują się wtedy kaskadowo i
zwyczajnie zajmują miejsce w zależnych tabelach. wtedy warto pomyśleć o
kluczu sztucznym, najczęściej całkowitoliczbowym, zamiast naturalnego
złożonego. klucz naturalny złożony przechowuje się wtedy jak zwykłe
atrybuty w tabeli. klucze sztuczne są na masową skalę stosowane w
hurtowniach danych.
pozdrawiam,
geos
jivan...@poczta.onet.pl
Rozumiem, ze wtedy warto zalozyc na takie atrybuty indeks unique.
geos
>> klucz naturalny z�o�ony przechowuje si� wtedy jak zwyk�e atrybuty w tabeli.
> Rozumiem, ze wtedy warto zalozyc na takie atrybuty indeks unique.
zapytania s� jednym z czynnik�w warunkuj�cym istnienie struktur
nadmiarowych wzgl�dem danych. je�li masz potrzeb� wyszukiwania podaj�c
pe�ny klucz naturalny to jak najbardziej. nierzadko jednak warunki
zapyta� s� takie, �e wystarczy zwyk�y indeks na poszczeg�lnych
kolumnach-komponentach tego klucza, albo na niekt�rych kolumnach.
potrzeby warunkuj� rozwi�zanie; je�li nie b�dzie przydatny to nie ma
sensu zak�ada� go na si��.
pozdrawiam,
geos
Piotr M Kuć
> jivan...@poczta.onet.pl wrote:
>>> klucz naturalny złożony przechowuje się wtedy jak zwykłe atrybuty w tabeli.
>>
>> Rozumiem, ze wtedy warto zalozyc na takie atrybuty indeks unique.
>
> zapytania są jednym z czynników warunkującym istnienie struktur
> nadmiarowych względem danych. jeśli masz potrzebę wyszukiwania podając
> pełny klucz naturalny to jak najbardziej. nierzadko jednak warunki
> zapytań są takie, że wystarczy zwykły indeks na poszczególnych
> kolumnach-komponentach tego klucza, albo na niektórych kolumnach.
> potrzeby warunkują rozwiązanie; jeśli nie będzie przydatny to nie ma
> sensu zakładać go na siłę.
Jemu chodzi o to, że wprowadzając klucz sztuczny warto założyć
indeks unikalny na kolumny które wcześniej tworzyły klucz naturalny.
Wg mnie warto, żeby zabezpieczyć się przed błędami aplikacji.
--
Pozdrawiam, Piotr.Kuc-(szympans)-kuciak.net
Piotr Kuć
Sławomir Szyszło
wklepał(-a):
>Jemu chodzi o to, że wprowadzając klucz sztuczny warto założyć
>indeks unikalny na kolumny które wcześniej tworzyły klucz naturalny.
>Wg mnie warto, żeby zabezpieczyć się przed błędami aplikacji.
Warto też zastanowić się czy taki klucz rzeczywiście będzie *zawsze* unikalny.
Rzeczywiste sytuacje czasem zaskakują. Np. spotkałem się z taką, gdzie kluczem
unikalnym były: seria dokumentu, numer dokumentu, status i numer wersji
(wersjonowanie dokumentów było w tej samej tabeli).
Po czasie okazało się, że zachodzi potrzeba anulowania dokumentów wprowadzonych
omyłkowo. Operator zmieniał zatem status dokumentu na Anulowany i wprowadzał
kolejny z tą samą serią, numerem i poprawnymi danymi (status był już inny).
Problem pojawił się wtedy, gdy operator pomylił się drugi raz i znów chciał ten
dokument anulować. Wtedy klucz unikalny już mu na to nie pozwolił, bo istniał
anulowany dokument o tej samej serii, numerze i statusie (Anulowany).
--
Sławomir Szyszło
Primus inter FAQires & Grand Inquisitor no.0 of pl.comp.bazy-danych
FAQ pl.comp.bazy-danych http://www.dbf.pl/faq/
Archiwum http://groups.google.com/groups?group=pl.comp.bazy-danych
Paweł Matejski
> Dnia 25 Jan 2011 19:12:43 +0100, Piotr M Kuć<kuc...@nospam.invalid>
> wklepał(-a):
>
>> Jemu chodzi o to, że wprowadzając klucz sztuczny warto założyć
>> indeks unikalny na kolumny które wcześniej tworzyły klucz naturalny.
>> Wg mnie warto, żeby zabezpieczyć się przed błędami aplikacji.
>
> Warto też zastanowić się czy taki klucz rzeczywiście będzie *zawsze* unikalny.
> Rzeczywiste sytuacje czasem zaskakują. Np. spotkałem się z taką, gdzie kluczem
> unikalnym były: seria dokumentu, numer dokumentu, status i numer wersji
> (wersjonowanie dokumentów było w tej samej tabeli).
>
> Po czasie okazało się, że zachodzi potrzeba anulowania dokumentów wprowadzonych
> omyłkowo. Operator zmieniał zatem status dokumentu na Anulowany i wprowadzał
> kolejny z tą samą serią, numerem i poprawnymi danymi (status był już inny).
>
> Problem pojawił się wtedy, gdy operator pomylił się drugi raz i znów chciał ten
> dokument anulować. Wtedy klucz unikalny już mu na to nie pozwolił, bo istniał
> anulowany dokument o tej samej serii, numerze i statusie (Anulowany).
W takim wypadku można użyć indeksu warunkowego, o ile baza wspiera takie rozwiązanie. :)
--
P.M.
Sławomir Szyszło
<ma...@nospam.madej.pl.eu.org> wklepał(-a):
>W takim wypadku można użyć indeksu warunkowego, o ile baza wspiera takie rozwiązanie. :)
Bardziej chodziło mi o pokazanie, że nie wszystko unikalne co się świeci. ;)
A indeksu warunkowego nie znam - jakaś odmiana funkcyjnego?
hubert depesz lubaczewski
>>W takim wypadku można użyć indeksu warunkowego, o ile baza wspiera takie rozwiązanie. :)
> Bardziej chodziło mi o pokazanie, że nie wszystko unikalne co się świeci. ;)
> A indeksu warunkowego nie znam - jakaś odmiana funkcyjnego?
inna nazwa - indeks częściowy.
przykład:
create unique index nazwa on users (username) where is_active = true;
indeks zawiera tylko te rekordy które pasują do warunku. w związku z
czym ewentualne obostrzenie (unique) też dotyczy tylko takich rekordów.
depesz
--
Linkedin: http://www.linkedin.com/in/depesz / blog: http://www.depesz.com/
jid/gtalk: dep...@depesz.com / aim:depeszhdl / skype:depesz_hdl / gg:6749007
Artur Muszyński
> Jemu chodzi o to, że wprowadzając klucz sztuczny warto założyć
> indeks unikalny na kolumny które wcześniej tworzyły klucz naturalny.
> Wg mnie warto, żeby zabezpieczyć się przed błędami aplikacji.
Pytający nie pisał, czy klucz jest naturalny, czy sztuczny.
Typowa sytuacja, w której powinien być sztuczny klucz złożony:
CREATE TABLE produkty (
id serial primary key,
name varchar not null
);
CREATE TABLE cechy (
id serial primary key,
name varchar not null
);
CREATE TABLE produkty_cechy (
id_produktu int not null references produkty (id)
on delete cascade,
id_cechy int not null references cechy (id)
on delete cascade,
primary key (id_produktu, id_cechy)
);
Wada, jak pisał geos, że rzeczywiście w pewnych drzewiastych przypadkach
struktura bazy trochę bardziej się rozrasta, ale IMHO nawet wtedy warto
starać się nie wprowadzać dodatkowego klucza typu serial.
Powody:
1. każdy dodatkowy indeks to nakład przy insercie i update
2. serial niesie ryzyko przepełnienia licznika
3. lekka denormalizacja tutaj nie szkodzi, a często zmniejsza ilość
złączeń w zapytaniach.
artur