Primary Key - wybór między 5 kolumnami "funkcyjnymi" a 1 kolumna ID

0

Witam,

poradźcie ... bo ja już zwątpiłem i sam w końcu nie wiem, a internety tylko pogłębiają moje rozterki.
Mam tablice z ruchami materiałowymi, całkiem spora koło 5,5kk rekordów. Chce ustawić na niej PK ale tablica jest tak skonstruowana, że aby otrzymać unikalny klucz muszę użyć 5 kolumn (coś jak: kod, magazyn, data, czas, numer sekwencji). I teraz nie wiem czy lepiej budować klucz z tych 5 czy może ostatecznie lepiej by było dodać nową kolumnę ID ? Z założenia zawsze staram się budować klucze na podstawie aktualnych kolumn które z reguły są też najczęściej używane w join, where, etc.

Dodam, że typy danych tych 5 kolumn to będą varchar, date, int, smallint.

Z góry dzięki za opinie/podpowiedzi.

5

IMO najlepiej będzie stworzyć sztuczny PK - dzięki temu:

  • będziesz mógł łatwiej pytać o te dane (gdybyś miał do tego jakieś API przykładowo), ponieważ wystarczy wtedy przekazywać identyfikator, a nie pięć różnych wartości,
  • będziesz w stanie łatwo / łatwiej tworzyć klucze obce (jeśli zajdzie taka potrzeba),
  • nie przekroczysz limitu rozmiaru wiersza indeksu (zdaje się, że w SQL Serverze jest to 900 bajtów).

O ile nie przekroczysz limitu indeksu, warto mimo to stworzyć unikalny indeks na wszystkie pięć kolumn.

0

Dzięki Patryk. W sumie API i kluczy obcych brak - tablica jest wykorzystywana czysto do potrzeb tworzenia raportów (jest kopią tablicy z systemu ERP wykorzystywana na potrzeby raportowania w magazynie danych). Limitu też nie przekracza bo póki co ustawiłem klucz właśnie z tych 5 kolumn.
Także jako, że 2 pierwsze pkty nie dotyczą mojego przypadku, a proponujesz "mimo wszystko" założenie takiego indeksu to chyba pozostanę przy tych 5 kolumnach.

0

Zawsze kiedy widzę brak kluczy głównych w tabeli wiem że będą z tą tabelka kłopoty, chyba że to słownik

2

Wielokrotnie używałem kluczy naturalnych (kompozytowych) jako PK i nigdy nie miałem z tym kłopotu. Tyle, że to był mój, zaplanowany wybór, a nie sytuacja, gdy ktoś czegoś nie przewidział i tak wyszło. Wszystko zależy od konkretnej architektury, odwołań z innych tabel i potencjalnego rozwoju / zmiany struktury danych w przyszłości. Poza tym co napisał Patryk27, że czasami jest tak wygodniej, to jeśli miałbyś zmieniać system tylko po to, by dodać klucz zastępczy (surrogate), bo kiedyś może Ci się przyda, a obecnie nie masz z tym problemów, to ja bym poczekał, aż to może kiedyś stanie się bardzo realne i wtedy dokonał zmiany.

3

Dla zasady niemal zawsze w tabelach tworzę sztuczny PK na polu ID, a dla zapewnienia unikalności zestawu danych z wybranych pól mam unikalne indeksy albo constrainty "unique"

3

Ja ZAWSZE dodaję ID i zawsze nazywam go ID i zawsze jest to PK. A to dlatego, że podczepiam potem triggera, który robi audyt tabeli po PK. W przypadku wielu kolumn musiałbym pisać dla każdej tabeli osobno trigger, a tak to wiem, że jest to ID.

0

Dzięki wszystkim za info. Wygląda, że mam swoją odpowiedź.

5
sabat24 napisał(a):

Wielokrotnie używałem kluczy naturalnych (kompozytowych) jako PK i nigdy nie miałem z tym kłopotu. Tyle, że to był mój, zaplanowany wybór, a nie sytuacja, gdy ktoś czegoś nie przewidział i tak wyszło.

Wielokrotnie używałem kluczy naturalnych (nie kompozytowych) i zawsze prędzej czy później stanowiło to problem.
Ale jest wygodne przy testowaniu i pisaniu zapytań z palca - to bezsprzecznie prawda.

Będąc młodym adeptem uczyłem się takich bzdur od ludzi odpowiedzialnych za rozwój i wdrożenie bardzo dużych systemów klasy światowej (w roku 1998 system z USA oparty o MSSQL działający natywnie na Windows i Apple, to był kosmos). Kiedy ja zaczynałem pracę w branży, nie było czegoś takiego jak senior albo mentor. Do wszystkiego trzeba było dojść samemu i to często bez internetu. A więc jak już spotkałeś kogoś, kto wiedział więcej niż przeciętnie, to patrzyło się na niego jak na bóstwo... Miałem szczęście (mieszkając na głębokiej prowincji to jak 6 w totka), znałem dwóch takich gości :)

Klucz kompozytowy to w ogóle porażka, kiedy dana tabela jest w relacji do innej.
Łączenie po 5 polach?
Aby odświeżyć jeden rekord, trzeba mieć wartości wszystkich 5 pól, a nie jednego ID - to nie ma być kłopot?

Wszystko zależy od konkretnej architektury, odwołań z innych tabel i potencjalnego rozwoju / zmiany struktury danych w przyszłości.

Wszystko prawda, ale...
Będąc już doświadczonym (nawet bardzo, bardzo doświadczonym) adeptem zaprojektowałem bazę danych do własnego systemu. Byłem i jestem również ekspertem dziedzinowym. A więc naprawdę byłem absolutnie przekonany, że w momencie jak mnie tknęło "tu zrobimy klucz naturalny" będzie wszystko OK. Bo przecież wiem co robię, wiem jak to się będzie rozwijać i wiem komu i do czego będzie to potrzebne.
No i było super... przez 3 lata, a potem przyszła konieczność modyfikacji wartości tego klucza naturalnego.
Niby nie kłopot, ale ta tabela to jedna z głównych tabel całego systemu, a więc ma sporo zależności po kluczu głównym.
A że w MSSQL kaskadowa aktualizacja kuleje (do dziś może być tylko jedna ścieżka dojścia dla FK - to jest naprawdę słabe ale nauczyłem się z tym żyć), to nie było trywialne zadanie.

Poza tym co napisał Patryk27, że czasami jest tak wygodniej, to jeśli miałbyś zmieniać system tylko po to, by dodać klucz zastępczy (surrogate), bo kiedyś może Ci się przyda, a obecnie nie masz z tym problemów, to ja bym poczekał, aż to może kiedyś stanie się bardzo realne i wtedy dokonał zmiany.

Ja bym na nic nie czekał, tylko włożył tam klucz sztuczny i finito.
To nie jest przedwczesna optymalizacja, tylko dobra praktyka.
Po prostu.

Dodam jeszcze, że mam podobny mechanizm (dane zaciągane z obcego systemu ERP) i w takim przypadku zawsze wkładam jeszcze jedno pole do takich tabel/widoków - ID wiersza z obcego systemu. Wielokrotnie się przekonałem, że posiadanie takiej wartości jest pomijalne z punktu widzenia utrzymania w systemie, a znakomicie otwiera możliwości do dalszych (w razie potrzeby) fikuśnych modeli przetwarzania danych z systemu ERP.
Bo po prostu mam ID z ERP.

0

W skórcie: Ty mówisz o projektowaniu systemu, a ja się odnoszę do sytuacji autora o zmianie istniejącego. Dla mnie jest to praca potencjalnie na wyrost, gdyż aktualnie nie ma z tym żadnych problemów, cały system jest oparty o działanie na tych kluczach, a nie innych. Zmiana stanu systemu ze stabilnego tylko po to, by kiedyś może stworzyć jakąś relację do tej tabeli, albo stworzyć API i chcieć się łatwo odwołać. Albo dojdzie zmiana architektury, która dorzuci kolejne pole do obecnego klucza. Nie widzę problemu, by zmienić to wtedy, przy okazji konkretnej funkcji, niż zmienić to teraz na wszelki wypadek. Pod warunkiem, że właśnie autor nie tworzy jakiejś masy nowych relacji do tej tabeli.

W tej chwili w kilku firmach chodzą stabilne wersje moich systemów opartych na php 5.3 z pewnie całą kupą złych praktyk. Nie zamierzam jednak niczego tam ruszać, tylko dlatego, że przez te lata nauczyłem się wielu nowych rzeczy, wyszło php 7.x a rozwiązania tam zawarte są pewnie tragiczne.

0
sabat24 napisał(a):

W skórcie: Ty mówisz o projektowaniu systemu, a ja się odnoszę do sytuacji autora o zmianie istniejącego.

ORLY?
No to zacytuję OP:

I teraz nie wiem czy lepiej budować klucz z tych 5 czy może ostatecznie lepiej by było dodać nową kolumnę ID

Dla mnie jest to element, jak to nazwałeś, projektowania systemu.

Dla mnie jest to praca potencjalnie na wyrost, gdyż aktualnie nie ma z tym żadnych problemów, cały system jest oparty o działanie na tych kluczach, a nie innych.

Ale autor nie pisał o żadnych istniejących kluczach, a tylko zastanawia się co nimi może być i dlaczego jakieś rozwiązanie będzie lepsze.

Zmiana stanu systemu ze stabilnego tylko po to, by kiedyś może stworzyć jakąś relację do tej tabeli, albo stworzyć API i chcieć się łatwo odwołać.

Nie, nie tylko po to.
Trzeba jeszcze mieć świadomość jak serwer bazy danych działa i dlaczego z jego punktu widzenia PK jest szalenie istotne.
Poza tym, wprowadzenie PK może tylko pomóc i na pewno niczego nie zdestabilizuje.

Albo dojdzie zmiana architektury, która dorzuci kolejne pole do obecnego klucza. Nie widzę problemu, by zmienić to wtedy, przy okazji konkretnej funkcji, niż zmienić to teraz na wszelki wypadek. Pod warunkiem, że właśnie autor nie tworzy jakiejś masy nowych relacji do tej tabeli.

Wymyślasz jakieś teorie do swojej tezy...
A ja po prostu odnoszę się wprost do wypowiedzianej potrzeby autora: "Chce ustawić na niej (tabeli) PK".
I tyle.

W tej chwili w kilku firmach chodzą stabilne wersje moich systemów opartych na php 5.3 z pewnie całą kupą złych praktyk. Nie zamierzam jednak niczego tam ruszać, tylko dlatego, że przez te lata nauczyłem się wielu nowych rzeczy, wyszło php 7.x a rozwiązania tam zawarte są pewnie tragiczne.

Pewnie tak, ja się nie znam.
Nigdy nie tykałem PHP i nigdy go tykał się nie będę, ale ważniejsze, że nie jest to istotne w tym wątku

1 użytkowników online, w tym zalogowanych: 0, gości: 1