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

Odpowiedz Nowy wątek
2019-03-12 10:30
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.

Pozostało 580 znaków

2019-03-12 11:07

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.


edytowany 3x, ostatnio: Patryk27, 2019-03-12 11:44

Pozostało 580 znaków

2019-03-12 11:22
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.

Pozostało 580 znaków

2019-03-12 13:00
0

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

Dzięki za komentarz, skądinąd bardzo słuszny - ale nie rozumiem jak to się ma do tematu ? - BlackBad 2019-03-12 13:27
Może ma się do tematu tak że klucza głównego numerycznego nie masz i masz potężne kłopoty. Zamiast od początku ogarnąć klucz to ktoś tego zaniedbał a dzisiaj kombinujesz bo okazało się że go potrzebujesz. - kate87 2019-03-12 13:44
Dalej nie rozumiem. Nic nie wspominałem o żadnych "poważnych kłopotach" ale prawda ktoś kto na początku tworzył ten proces żadnych kluczy nie stworzył więc teraz ja to porządkuje. Rozumiem, na podstawie Twojego komentarza powyżej, że też optujesz za kluczem numerycznym czyli dodatkową kolumną ID. - BlackBad 2019-03-12 14:09
Generalnie optuje za kluczami numerycznymi narzucanymi od samego początku jeśli wiem że tabela po pierwsze będzie duża, a po drugie w momencie kiedy masz np 3-4 tabele jako pk i próbujesz łączyć tabele po takich kluczach to po prostu masz to utrudnione. - kate87 2019-03-12 15:18

Pozostało 580 znaków

2019-03-12 14:57
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.

Pozostało 580 znaków

2019-03-12 19:03
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"

edytowany 2x, ostatnio: grzegorz_so, 2019-03-12 20:46

Pozostało 580 znaków

2019-03-12 20:44
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.

Pozostało 580 znaków

2019-03-13 07:30
0

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

Pozostało 580 znaków

2019-03-14 11:05
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.

Mogę się tylko podpisać pod tym, tak należy robić. :) - robertos7778 2019-03-14 13:05
Od wersji 2005 klucze zawsze tworze jako własny typ create type i jak jest potrzeba zmiany to zmieniam definicje typu i na tabelach w polach FK wszystko ładnie śmiga, takie obejście do zmieniania wszystkich zależnych kolumn... - Panczo 2019-03-19 23:00

Pozostało 580 znaków

2019-03-14 16:31
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.

edytowany 1x, ostatnio: sabat24, 2019-03-14 16:32

Pozostało 580 znaków

2019-03-14 19:09
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

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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