wyrażenie sql ograniczające wybór w polu listy

[mih]

witam,

walczę już z tym kilkanaście godzin, próbuję różnych metod, ale nic nie pomaga. Załączam zdjęcie relacji w mojej bazie, bazy niestety nie mogę bo mam ją w pracy połączoną do MySql.

Mam formularz, gdzie wprowadzam zamówienia, oraz podformularz, gdzie mam pozycje w tych zamówieniach. Najpierw uzupełniam formularz wszystkimi danymi (w tym zamawiającym - pole listy), a później dodaje pozycje, wybierając je z tabeli wyrobów poprzez pole listy (kolumna tabeli) w podformularzu, który ma formant tabeli. I chce ograniczyć wyroby, tak żeby zostały tylko te, które są przypisane do odpowiedniego zamawiającego. Mam więc 4 tabele (zakreśliłem je),4 relacje między nimi, próbowałem już chyba każdego możliwego połączenia każdych dwóch tabel (wewnętrzne, lewostronne, prawostronne), próbowałem usuwać jedną relacje tak żeby nie tworzyć koła zamkniętego i nic. Po tylu godzinach patrzenia na jeden schemat człowiek już głupieje, być może rozwiązanie jest bardzo proste, ale go nie widzę...

[Jan_J]

Zapewne powinno być

zamowienia join pozycie using(id_zamowienia)
join wyroby4 using(id_wyrobu)
....
where zamowienia.id_zamawiajacego = ...

Trochę ciężko, bo niby dlaczego w wyroby4 figuruje zamawiający? tak jakby wyrób nie istniał jako oferta, czy to produkcyjna czy magazynowa, tylko każdy wyrób był "ofertowany" z osobna dla konkretnego odbiorcy? chyba tak nie jest. Ale gdyby było, to wtedy tylko ten odbiorca byłby zamawiającym, więc zamówienia trzeba by inaczej konstruować.

Nie za bardzo też rozumiem bałaganu wokół wew_zew (jest referencja przechodnia od zamowienia przez pozycje_zam, ale jest też bezpośrednia), ale to nie stanowi przedmiotu problemu.

[mih]

Trochę ciężko, bo niby dlaczego w wyroby4 figuruje zamawiający? tak jakby wyrób nie istniał jako oferta, czy to produkcyjna czy magazynowa, tylko każdy wyrób był "ofertowany" z osobna dla konkretnego odbiorcy? chyba tak nie jest. Ale gdyby było, to wtedy tylko ten odbiorca byłby zamawiającym, więc zamówienia trzeba by inaczej konstruować.

nie są to wyroby oferowane przez tą firmę ze swojego katalogu. Jest to firma, która dostaje zamówienia na wyroby, które aktualnie potrzebuje firma, które je zamawia, wg ich dokumentacji z ich numerem wyrobu i nazwą. Dlatego każdy wyrób jest przypisany do danej firmy i nie ma możliwości, że konkretny wyrób będzie zamawiany przez 2 różne firmy.

Nie za bardzo też rozumiem bałaganu wokół wew_zew (jest referencja przechodnia od zamowienia przez pozycje_zam, ale jest też bezpośrednia), ale to nie stanowi przedmiotu problemu.

tutaj też musiałem kombinować przez wzgląd na taka a nie inną specyfikację firmy. Gdy przychodzi zamówienie od firmy zewnętrznej (zamawiający) na konkretny produkt (wyrób), to bardzo często dział, który przyjmuje to zamówienie wystawia zamówienie wewnętrzne, które trafia do działu przygotowania produkcji tej firmy. Dlatego w formularzu gdzie dodaje się zamówienia można również dodać zamówienie wewnętrzne, gdzie oprócz podformularza z pozycjami zamówieniowymi (którego dotyczy opisany problem) jest również podformularz oparty właśnie na tabeli wew_zew, gdzie można dodać pozycje zamówieniowe, za których realizacje jest odpowiedzialne dane zamówienie wewnętrzne. Dzięki temu w innym formularzu z harmonogramem produkcji kierownik działu przyjmującego dane zamówienie widzi przy każdej pozycji czy otrzymał już detale, które są mu potrzebne z działu przygotowania produkcji, aby rozpocząć produkcje konkretnej pozycji w swoim dziale. Gdy kierownik działu przygotowania produkcji zaznacza ptaszek, że zamówienie wewnętrzne jest zrealizowane, to kierownikowi działu spawania wskakuje ptaszek że ma wszystko co potrzebuje do danej pozycji zamówieniowej. Trochę to pokręcone ale nic lepszego nie wymyśliłem, a chciałem mieć te 2 rzeczy:

-zamówienia zew i wew w jednej tabeli
-realizacja zam wew = sygnał do działu przyjmującego zamówienie że mogą zacząć je realizować

Czy początek twojego poprzedniego posta oznacza że nie istnieje rozwiązanie mojego problemu?

[Jan_J]

Rozwiązanie na pewno istnieje, ale nadmiarowość zaszyta w schemacie bazy powoduje pewne problemy, tzn. schemat taki pozwala na przechowywanie niespójnych danych.
Spróbuję się przymierzyć do odpowiedzi wieczorem.