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