eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingPytanie o klucze baz
Ilość wypowiedzi w tym wątku: 11

  • 1. Data: 2009-12-17 12:56:06
    Temat: Pytanie o klucze baz
    Od: Jacek Czerwinski <...@...z.pl>

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


  • 2. Data: 2009-12-17 14:51:08
    Temat: Re: Pytanie o klucze baz
    Od: Krzysztof Warunek <k...@t...pl>

    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


  • 3. Data: 2009-12-17 16:20:42
    Temat: Re: Pytanie o klucze baz
    Od: Jacek Czerwinski <...@...z.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.



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


  • 4. Data: 2009-12-17 17:41:38
    Temat: Re: Pytanie o klucze baz
    Od: "Mateusz Loskot" <m...@l...net>

    "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


  • 5. Data: 2009-12-17 18:42:36
    Temat: Re: Pytanie o klucze baz
    Od: Krzysztof Warunek <k...@t...pl>

    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


  • 6. Data: 2009-12-17 19:40:29
    Temat: Re: Pytanie o klucze baz
    Od: wloochacz <w...@n...dgbit.spameromnie.pl>

    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


  • 7. Data: 2009-12-17 20:10:32
    Temat: Re: Pytanie o klucze baz
    Od: "HillBilly" <h...@m...com>


    "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


  • 8. Data: 2009-12-17 21:38:17
    Temat: Re: Pytanie o klucze baz
    Od: Bronek Kozicki <b...@s...net>

    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.


  • 9. Data: 2009-12-18 08:03:13
    Temat: Re: Pytanie o klucze baz
    Od: wloochacz <n...@n...dgbit.pl>

    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


  • 10. Data: 2009-12-18 09:42:29
    Temat: Re: Pytanie o klucze baz
    Od: Mateusz Ludwin <n...@s...org>

    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

strony : [ 1 ] . 2


Szukaj w grupach

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: