Forum PHP.pl

Da się tylko trzeba widzieć, iż SET określa jaką kolumnę zmieniamy a nie po jakiej się łączymy. Najlepiej by było gdybyś znał składnie UPDATE i SELECT z JOIN to by pomógło rozwiązać problem. A tym czasem

[SQL] pobierz, plaintext 
UPDATE a JOIN b ON a.id = b.id SET a.k4 =b.k4
[SQL] pobierz, plaintext 

No tak, mieszkałem w małym mieście i przyzwyczaiłem się do jednego kodu .



Czyli w zasadzie kod pocztowy wiąże się z ulicą i być może numerem domu, a nie z miastem. To znacznie utrudnia sprawę. Szkoda chyba czasu na szukanie i analizę, szczególnie gdy aplikacja ma dotyczyć wielu krajów.
Najgorsze z tego wszystkiego to uzupełnianie słowników. Jeżeli nie masz przyzwoitej listy to ciężko będzie to zrealizować.

Pewnie lepiej będzie w aplikacji zostawić użytkownikowi pola (miasto, kod_pocztowy, ulica) do ręcznego uzupełnienia, skryptem Java autouzupełniać w przypadku, gdy np. dane miasto istnieje już w bazie, a gdy nie dodawać do bazy.

Kwestia jak wielka ma być aplikacja, ile nieruchomości będzie się w niej znajdować. Na wielkości rzędu 1 - 10k pewnie nie będzie się opłacać tak kombinować, a użytkownik nie odczuje dyskomfortu uzupełniając ręcznie pole adres (wraz z kodem pocztowym i miastem).

Najważniejsze to wziąć ołówek, dużą kartkę i wszystko sobie rozrysować (tabele, relacje, kolumny, wymagane dane, dane opcjonalne, orientacyjna liczba rekordów w danej tabeli itd.). Bez dobrego projektu, ciężko stworzyć dobrą aplikację.

Nie wziąłem.

Dodatkowo stworzyłbym tabelki:

PARAMETERS
----------------
id_parameters PK
param_name
--unit (jako wartość np. m2)

TYPE_PARAMETERS
---------------------
id_parameters FK
id_type FK
tutaj kluczem głównym będzie złożenie kluczy obcych

Do tabelki REALESTATES można dodać kolumny, które będą wspólne dla każdego typu nieruchomości np. cena + kolumnę parametrs (o tym za chwilę), do tabeli PARAMETERS można wpisać wszystkie parametry nieruchomości, które są rózne, a w tabelce TYPE_PARAMETERS będzie znajdować się połączenie tabel PARAMETERS i TYPE co spowoduje, że każdemu rodzajowi nieruchomości będzie można określić oddzielny parametr.

W aplikacji np. na ekranie dodawania nowej nieruchomości, wypisałbym wszystkie parametry pasujące do danego typu nieruchomości, a po uzupełnieniu przez użytkownika tworzył tablicę i zapisywał do tabeli REALESTATES (kolumna parameters) korzystając z funkcji serialize().

Ewentualnie stworzyć jeszcze jedną tabele (nazwijmy ją TYPE_PARAM_REALE), która będzie tworzyła relację tabeli REALESTATES i TYPE_PARAMETERS, wtedy funkcja serialize() nie będzie konieczna, bo w tej tabeli dla każdej nieruchomości będzie kilka rekordów z parametrem i jego wartością:

TYPE_PARAM_REALE
---------------------
id_TYPE_PARAMETERS
id_rel
value

id_TYPE_PARAMETERS i id_rel tworzą klucz główny

Realizować można to np. tak:
Pracownik wybiera typ nieruchomości 'mieszkanie', które w naszej tabeli TYPE ma id = 1. Wypisujemy mu parametry jakie są dostępne dla tego typu:

[SQL] pobierz, plaintext 
SELECT id_TYPE_PARAMETERS, param_name FROM parameters p
JOIN type_parameters tp ON p.id_parameters = tp.id_parameters AND tp.id_type = 1
[SQL] pobierz, plaintext 

Pracownik dodaje nową nieruchomość, uzupełnia odpowiednie pola, a w aplikacji wykonują się dwa INSERTY jeden dodający nieruchomość do tabeli REALESTATES, drugi INSERT do tabeli TYPE_PARAM_REALE (id_TYPE_PARAMETERS wyciągnąłeś zapytaniem powyżej, id_rel można wyciągnąć przez mysql_insert_id(), value to wartość wpisana w formularzu).

Może ktoś doświadczony wypowie się jeszcze...