Witam,

nie mogę nigdzie znaleźć odpowiedzi na pytanie czy klucze obce mogą "wskazywać" na widok- Tj. chciałbym aby klucz obcy w tabeli A odnosił się do rekordu w widoku - wywala mi jednak błąd przy zapisie, że klucz nie został spełniony. (Wiem że mogę sprawdzić w tabeli z której został stworzony widok, ale bardziej odpowiadałoby mi gdybym sprawdzał w widoku z pewnych względów).

pozdrawiam

Tak na 'chłopski rozum' to jest to raczej nie możliwe, ponieważ widok nie jest żadną tabelą tylko zapytaniem.
W związku z tym mechanizmy kontroli ograniczeń typu FOREIGN KEY nie mają struktury, na której mogłyby operować.

@athabus
A podaj dlaczego nie chcesz zakładać FK tak jak przystało na rzeczywistej tabeli?

@prond
Jeszcze jakby to był widok na jednej tabeli, to pal licho mogło by iść, ale gdy widok jest skomplikowany, to czasem nawet jakby człowiek miał podjąć decyzje co zrobić to by nic nie wyszło.
Do tego widoki w MySQL są niezapisywalne.
Ogólnie widoki stanowią otoczkę danych, więc nie wiem dlaczego jakiekolwiek tabele miały by się do nich odwoływać. To jakby wyświetlać stronę na podstawie jakiś danych, a potem gdzieś korzystać z tej strony jako źródła danych, a nie z pierwotnego... Trochę bez sensu, co nie?

Oj historia jest długa. W skrócie - korzystam z symfony z Propelem.
Mam dość skomplikowaną strukturę w sklepie -> podstawą jest widok Product który jest joinem około 5-6 tabel - do tego join ten jest wielostopniowy tj. np. product -> join productGroup -> join ProductCategory. Podstawą produktu jest tabela ProductBase która jednak aby powstał z niej produkt musi wykonać wiele joinów więc stworzyłem sobie widok aby łatwiej na tym operować.

Teraz z widoku produkt korzysta wiele różnych innych obiektów takich jak promocje, przeceny, kupony rabatowe, stany magazynowe itd itd.
Jeśli mam klucz obcy to symfony wygeneruje mi bardzo ładnie metody do "współdziałania" tych wszystkich obiektów - jeśli natomiast klucz obcy jest założony na ProductBase (czyli tej tabeli z "gołym" produktem) to muszę napisać kilkadziesiąt metod ręcznie łączących to wszystko do kupy albo zgodzić się na większą (często dużo większą) liczbę zapytań.

To tak w skrócie -ogólnie problem jest dość złożony - rozwiąże go po prostu tworząc tabelę readOnly z cachem produktów bo nic lepszego mi do głowy nie przychodzi.

Jak dla mnie problem powinno się rozwiązać na poziomie Propela (czy może jego obiektów, sam nie wiem, aż tak mocny z Propela nie jestem przy bardziej zagmatwanych problemach), czyli tak złączyć Product z ProductBase. W jaki sposób, no cóż, zależy co chcesz osiągnąć.

(Tak swoją droga, to w PostgerSQL widoki mogą być aktywne, wtedy na poziomie bazy by się obsługiwało relacje, a chyba takiego czegoś nie ma w MySQL)

Hm, może coś z tego:
http://propel.phpdb.org/docs/user_guide/ch...bjectModel.html
Sam nie wiem, nie używałem, a nie mogą jakoś do końca ogarnąć jaką daje to użyteczność. (a teraz nie mam na to czasu)