Primary key jako string - perwersja czy rozsadne rozwiazanie

0

Witam,
Spotkalem sie z baza danych w PostgreSQL, w ktorej autor generowal primary key jako aktualny czas (VARCHAR). Wydaje mi sie to programistycznym WTFem, bo zawsze eleganckie byly liczbowe klucze glowne np. typu serial.

Czy jest to jednoznacznie zla praktyka programistyczna, czy moze istnieje ku temu racjonalne wytlumaczenie? Dodam, ze to duza aplikacja w Java EE w pewnej korporacji.

0

Typ danych w tym przypadku ma drugorzędne znacznie. Problemem może być wystąpienie dwóch zdarzeń w tym samym czasie i kolizja na tak wybranym kluczu głównym gotowa.

Nie wiem jakie są reguły biznesowe w rzeczonej aplikacji i czy zdarzenia biznesowe mogą wystąpić równocześnie. Może jest tylko jedno stanowisko obsługi i nie ma możliwości na tyle szybkiego wprowadzania danych, żeby kolizja wystąpiła.

Niezależnie od faktycznego stanu, stosowanie daty jako klucza głównego/elementu klucza głównego wydaje mi się słabym pomysłem :)

Widziałem wiele razy sytuacje, gdy było to problemem, przykład pierwszy z brzegu: historia zmian statusu jakiegoś obiektu, klucz składający się z (obiekt_id, czas zmiany) może wprowadzić niejednoznaczność w interpretacji, gdy jedna aplikacja/moduł wstawia datę bez części godzinowej/..., a druga z częścią godzinową. Teraz wystarczy, że w ciągu dnia wystąpią 2 zmiany i nie wiadomo co było pierwsze.

1

Ta data to jest jakiś chory pomysł. String niby lepszy, tylko po co? Porównywanie i indeksowanie jest zapewne wolniejsze niż typów całkowitoliczbowych.

0

Jak napisał @somekind indeksowanie liczb całkowitoliczbowych jest szybsze niż varchar i np. Ja zwykle jak projektuje bazę danych to PK ustawiam jako liczbę typu int. Dodatkowo mamy auto inkrementacje zmiennej.

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