eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingPytanie o klucze bazRe: Pytanie o klucze baz
  • Data: 2009-12-17 19:40:29
    Temat: Re: Pytanie o klucze baz
    Od: wloochacz <w...@n...dgbit.spameromnie.pl> szukaj wiadomości tego autora
    [ pokaż wszystkie nagłówki ]

    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

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: