Jakiś czas temu zacząłem przygodę z RoR i właśnie natknąłem się na coś, co wydaje mi się wręcz nieprawdopodobne. Czy mechanizm migracji rzeczywiście nie zapewnia tworzenia kluczy obcych w bazie danych? Do tej pory tylko raz miałem do czynienia z bazą, która nie posiadała podobnych ograniczeń i było to przyczyną wiecznych problemów. Jak rozumiem, nie ma innej metody, jak tylko zdefiniowanie kluczy obcych bezpośrednio w SQL-u?
PS. To mój pierwszy post na Forum, więc proszę o wyrozumiałość.
Niestety to prawda i jest to moim zdaniem jeden z bardzo dużych minusów railsów. Niby większość osób wie, że tak się powinno robić, ale jak nie jest to automatycznie wymuszane przez framework, to nie każdy o tym pamięta (sam kilka razy zapomniałem i później miałem sporo zabawy).
Polecam gema foreigner: https://github.com/matthuhiggins/foreigner
W ogóle trochę śmieszne jest dla mnie podejście wielu railsowców, którzy bardzo pracują nad tym, żeby jak najmniej rzeczy siedziało w bazie danych. Nie raz i nie dwa dzięki triggerom czy innym fajnym wynalazkom udawało mi się zoptymalizować i wyczyścić różne potworki w aplikacjach.
ActiveRecord działa na poziomie abstrakcji, na którym nie może zapewnić obsługi foreign key constraints (nie wszystkie bazy to obsługują). Sprawdź https://github.com/matthuhiggins/foreigner
Dzięki. Myślałem, że może mam jakieś stare materiały do nauki frameworka (ewentualnie nie doczytałem w dokumentacji) i stąd te braki. Zerknąłem na tego gema i widzę, że złagodzi moje rozczarowanie. Tym bardziej, że obsługuje postgresa. Pierwszy zgrzyt za mną 
Nie pamiętam, jak to było u Fowlera, ale czy brak ograniczeń klucza obcego wynika z samego wzorca czy z chęci obsługi większej ilości baz? Jeśli tylko to drugie, to przecież dla silników, które nie obsługują FK można było zastosować puste metody.
PS. Wypróbowałem foreignera i w zasadzie uzyskałem to, czego oczekiwałem.
Nie pamiętam, jak to było u Fowlera, ale czy brak ograniczeń klucza obcego wynika z samego wzorca czy z chęci obsługi większej ilości baz? Jeśli tylko to drugie, to przecież dla silników, które nie obsługują FK można było zastosować puste metody.[/quote]
Nie wiem czy to wyszło od Fowlera czy DHH sobie dopasował do swojej filozofii “baza danych jest fuj”, ale dla mnie w ogóle takie podejście prowadzi do niezdrowych sytuacji - framework nie może zapewnić integralności danych.
Jeżeli chodzi o obsługę wielu baz danych, to imho to jest jeden z najbardziej debilnych argumentów na nieużywanie SQLa. Ile widzieliście aplikacji, w których zmieniana była jedna baza relacyjna z inną przy pozostawieniu kodu aplikacji? Z reguły używam w aplikacjach postresqla i używam wszystkiego co tylko mi się akurat przydaje: kluczy obcych, triggerów, tablic, hstore’a, JSON. Przy małych aplikacjach nie ma to znaczenia, ale powyżej pewnej skali albo przy pewenych skomplikowanych problemach tego typu rzeczy niesamowicie potrafią ułatwić sprawę.
Mi się “kompatybilność” z czymkolwiek kończy po parunastu minutach, przy pierwszym ILIKE.