Witam,

Wlasne jestem na etapie tworzenia wieksze projektu i mam nastepujacy problem.
Mam 3 klasy modelu:
- User (tabela: tusr)
- Company (tcompany)
- ContactInfo (tcontactinfo) : zapisuje tam maile, www, telefony rozrozniajac je po typie

Nie wiem jak sie uporac sie z taka sytuacja.
Uzytkownicy i firmy posiadaja informacje kontaktowe czyli jakby nie patrzac mamy sytuacje:
tuser.id 1------n tcontactinfo.id
tcompany.id 1-------- n tcontactinfo.id

A zeby tego bylo malo to jest tez taka sytuacja ze firmy moga miec przypisanych uzytkownikow
tcompany 1 ------- n User

I teraz jak skonstruowac model z kluczami obcymi itp. Wiadomo ze mozna by to zrobic bez kluczy obcych ale troche lyso

Z gory dzieki za pomoc

Dodam ze probowalem nawet zapisywac uzytkwonikow i firmy w jednej tablicy ale potem mialem problem z sytuacja, w ktorej tusr odwolywal sie do siebe samej bo firma moze miec uzytkownikow :/

Czy to przypadkiem nie są relacje wiele-do-wielu? Wiele kontaktów może należeć do wielu użytkowników; wielu użytkoników może mieć wiele kontaktów. I analogicznie dla reszty.
Jeśli mowa o generatorze admina to użyj:
http://www.symfony-project.org/book/1_0/14...rs#Many-to-Many Relationships (link jest zrypany - musisz skopiować go "rozumnie")

Nie wiem czy dobrze mysle ale dany kontakt (mail, telefon itp.) moze nalezec do jednego uzytkownika, a uzytkownik moze miec wiele kontaktow.
Czyli jesli chce sie skontaktowac z danym uzytkownikiem to wiem ze pod danym telefonem bedzie tylko on
Chyba dobrze rozumuje. Jak sie myle to prosze mnie poprawic.

Heh, Nekro trochę mało zgrabnie to napisałeś, ale chyba wiem co miałeś na myśli.


Jak widać, jest to łączenie 1 do wielu. Czyli załatwiamy to zgrabnie w schema.yml. (jak nie wiesz, to proponuję poczytaj w dokumentacji - jest to podstawa)


Rozwiązań wiele. Osobiście proponuję utworzyć w wygenerowanej klasach Tuser i Tcompany metodę getContactInfo().
A tam cóż innego jak coś w stylu (np. dla Tuser):


oczywiście nazwy wziąłem z kosmosu.

Odnośnie generatora Panowie, proponuję zabierać się za niego, tylko gdy będzie dobrze "obudowany" model w odpowiednie metody.

Czyli sugerujesz zeby polaczenie zrobic tylko miedzy user -> company a tabele tcontactinfo nie laczyc z zadna z nich

Czyli powiedzmy w skrocie cos takiego:

tcompany:
id
...

tusr:
id:
tcompany_id
....

tcontactinfo
id:
typ: (gdzie typ to mail,www,telefon)
wartosc:
domyslny:

I plus do tego odpowiednie metody do pobierania informacji kontaktowych w klasach dla tusr i tcompany??
Hmmm o tym nie pomyslalem....dzieki
Tylko mnie jeszcze jedna rzecz zastanawia. JAk bede wyswietlal liste uzytkownikow a na niej: Imie, nazwisko, mail, telefon, to dla jednego uzytkownika beda odpalane dodatkowe 2 zapytania do bazy dotyczace maila i telefonu. Majac 10 uzytkownikow na liscie to tych zapytan bedzie 20....nie uwazacie ze to moze miec wplyw na wydajnosc aplikacji Dodanie tych informacji do tabeli z uzytkownika nie wchodzi w gre bo zakladam ze uzytkownik moze miec wiele maili, a na liscie bedzie sie wyswietlala pozycja domyslna.

Narazie nasuwa mi sie rozwiazanie ze obok listy uzytkownikow, bede pobieral jednym zapytaniem cala liste z contactinfo dla id pobranych uzytkownikow oraz z wartoscia "default = true", w ten sposob ze kluczami tablicy beda identyfikatory uzytkownikow

Tego nie powiedziałem. Jak masz potrzebe, to lącz



Hmm, w tej schemie nie widzę relacji pomiędzy (tuser|tcompany) a tcontactinfo. Jak masz dla przykładu rekord:
w tuser o wartości:

• id - 1

i tcontact info o wartościach:

• id - 1
• typ - mail
• wartosc: mail@test.pl
• domyslny: true

To skąd wiadomo że te rekordy są (lub nie są) powiązane?



To zoptymalizuj, żeby pobierało informacje w 1 sql'u - nie podpowiem Ci jak



Trochę na około, ale można i tak.
Podsumowanie: po tych postach widzę, że masz problemy nie z samym symfony, co z propelem i budowaniem modelu danych. Proponuję Ci się dokształcić, w zakresie tworzenia relacji (może budowania diagramu encji - jak się widzi ułożone encje i relacje łatwiej się uczy). Następnie proponuję przejrzeć trochę dokumentację symfony odnośnie modelu.

No tak masz racje..mialem to na mysli a zapomnialem napisac.
Myslalem o takim czyms:

tusr
id

tcompany
id

tcontactinfo
id

relacje:

tcontactinfo_company
tcontactinfo_id
tcompany_id

tcontactinfo_user
tcontactinfo_id
tuser_id

Chyba ze to sie da jakos bardziej elegancko zrobic