-
1. Data: 2011-09-29 11:55:10
Temat: problem projektowy w aplikacji bazodanowej
Od: j...@p...onet.pl
Tworzę w PHP+MySQL witrynę o nieruchomościach i mam pewien problem projektowy.
Na stronie głównej jest lista drop-down z rodzajami nieruchomości (mieszkanie,
kawalerka, itd.). Poniżej jest formularz z danymi nieruchomości (miejscowość,
rok budowy, czy jest garaż, itp.). Zrobiłem tak, że w zależności od wybranego
rodzaju nieruchomości, pokazują się różne pola z danymi (np. dla budynku jest
liczba pięter, a dla kawalerki - nie).
W bazie danych mam:
CREATE TABLE `ogloszenia`.`estate_types` (
`estate_type_id` varchar(5) NOT NULL COMMENT 'Rodzaj nieruchomosci',
`estate_type_name` varchar(33) NOT NULL COMMENT 'Nazwa rodzaju nieruchomosci',
PRIMARY KEY (`estate_type_id`),
KEY `index_estate_type_name` (`estate_type_name`) USING BTREE
) ENGINE=MyISAM DEFAULT CHARSET=latin2 COMMENT='Rodzaje nieruchomosci'
CREATE TABLE `ogloszenia`.`estate_types_visibility` (
`estate_type_id` varchar(5) NOT NULL COMMENT 'Identyfikator rodzaju
nieruchomosci',
`use_region` varchar(2) NOT NULL DEFAULT '+' COMMENT 'Widocznosc pola
wojewodztwa',
`use_town` varchar(25) NOT NULL DEFAULT '+' COMMENT 'Widocznosc pola
miejscowosci',
`use_district` varchar(25) NOT NULL DEFAULT '+' COMMENT 'Widocznosc pola
dzielnicy',
`use_address` varchar(1) NOT NULL DEFAULT '+' COMMENT 'Widocznosc pola adresu',
`use_floor_no` varchar(5) NOT NULL DEFAULT '+' COMMENT 'Widocznosc pola numeru
pietra',
`use_floors` varchar(5) NOT NULL DEFAULT '+' COMMENT 'Widocznosc pola liczby
pieter',
`use_area` varchar(11) NOT NULL DEFAULT '+' COMMENT 'Widocznosc pola powierzchni',
`use_rooms` varchar(10) NOT NULL DEFAULT '+' COMMENT 'Widocznosc pola liczby
pokoi',
`use_offices` varchar(10) NOT NULL DEFAULT '+' COMMENT 'Widocznosc pola liczby
pomieszczen',
`use_year_built` varchar(5) NOT NULL DEFAULT '+' COMMENT 'Widocznosc pola roku
budowy',
`use_ownership` varchar(3) NOT NULL DEFAULT '+' COMMENT 'Widocznosc pola formy
wlasnoËści',
`use_standard` varchar(2) NOT NULL DEFAULT '+' COMMENT 'Widocznosc pola
standardu',
`use_house` varchar(1) NOT NULL DEFAULT '+' COMMENT 'Widocznosc pola domka
letniskowego',
`use_buildings` varchar(1) NOT NULL DEFAULT '+' COMMENT 'Widocznosc pola
zabudowan',
`use_garrage` varchar(1) NOT NULL DEFAULT '+' COMMENT 'Widocznosc pola garazu',
`use_parking` varchar(1) NOT NULL DEFAULT '+' COMMENT 'Widocznosc pola miejsca
parkingowego',
`use_kitchen` varchar(1) NOT NULL DEFAULT '+' COMMENT 'Widocznosc pola widnej
kuchni',
`use_balcony` varchar(1) NOT NULL DEFAULT '+' COMMENT 'Widocznosc pola balkonu',
`use_gas` varchar(1) NOT NULL DEFAULT '+' COMMENT 'Widocznosc pola gazu',
`use_current` varchar(1) NOT NULL DEFAULT '+' COMMENT 'Widocznosc pola prÂĄdu',
`use_sewerage` varchar(1) NOT NULL DEFAULT '+' COMMENT 'Widocznosc pola
kanalizacji',
`use_furniture_type` varchar(3) NOT NULL DEFAULT '+' COMMENT 'Widocznosc pol
umeblowania',
`use_equipment` varchar(8) NOT NULL DEFAULT '+' COMMENT 'Widocznosc pol
wyposazenia',
`use_guard` varchar(1) NOT NULL DEFAULT '+' COMMENT 'Widocznosc pola ochrony',
`use_pictures` varchar(1) NOT NULL DEFAULT '+' COMMENT 'Widocznosc pol zdjec /
filmow',
`use_remarks` varchar(1) NOT NULL DEFAULT '+' COMMENT 'Widocznosc pola
dodatkowego opisu'
) ENGINE=MyISAM DEFAULT CHARSET=latin2 COMMENT='Widocznosc pol zaleznych od
rodzaju nieruchomosci'
Mój problem polega na tym, że nie jestem pewien czy informacja o widoczności pól
powinna być przechowywana w bazie danych (tabela estate_types_visibility). Może
wystarczyłaby tablica JavaScriptowa używana przez funkcję
onchange="showPropertyRows()"? Zrobiłem przechowywanie tych informacji w bazie
danych ponieważ kluczem jest:
`estate_type_id` varchar(5) NOT NULL COMMENT 'Identyfikator rodzaju nieruchomosci'
Zatem tyle jest rekordów ile rodzajów nieruchomości. Gdybym nie miał tabeli w
bazie danych (a tylko tablicę JavaScriptową), to musiałbym przy każdej zmianie
słownika rodzajów nieruchomości zaktualizować kod JavaScript, a tak wystarczy,
że zmienię wpisy w bazie danych (w obu tabelach), bo stosowną tablicę
JavaScriptową dla showPropertyRows() generuję PHPem.
Potrzebuję waszej opinii: które rozwiązanie jest lepsze: z tabelą
estate_types_visibility czy bez?
Byłbym wdzięczny za pomoc.
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl
-
2. Data: 2011-09-29 18:08:55
Temat: Re: problem projektowy w aplikacji bazodanowej
Od: lolo <n...@n...com>
> Mój problem polega na tym, że nie jestem pewien czy informacja o widoczności pól
> powinna być przechowywana w bazie danych (tabela estate_types_visibility). Może
> wystarczyłaby tablica JavaScriptowa używana przez funkcję
> onchange="showPropertyRows()"? Zrobiłem przechowywanie tych informacji w bazie
> danych ponieważ kluczem jest:
> `estate_type_id` varchar(5) NOT NULL COMMENT 'Identyfikator rodzaju
nieruchomosci'
typ w rekordach ogłoszeń i tak musisz mieć by łatwiej filtrować
> Zatem tyle jest rekordów ile rodzajów nieruchomości. Gdybym nie miał tabeli w
> bazie danych (a tylko tablicę JavaScriptową), to musiałbym przy każdej zmianie
> słownika rodzajów nieruchomości zaktualizować kod JavaScript, a tak wystarczy,
> że zmienię wpisy w bazie danych (w obu tabelach), bo stosowną tablicę
> JavaScriptową dla showPropertyRows() generuję PHPem.
> Potrzebuję waszej opinii: które rozwiązanie jest lepsze: z tabelą
> estate_types_visibility czy bez?
w obu przypadkach chodzi de facto o interface strony klienckiej (także w
przypadku panelu administracyjnego) i w obu powinien być generowany
statyczny js do cache'owania na poziomie przeglądarki/serwera
kwestia łatwości zarządzania - zmiana słownika = ręczne grzebanie w
strukturze tabel czy administracja poprzez jakiś panel administracyjny?
modyfikacja struktury rekordów ma swoje zalety (można filtrować po
czymkolwiek), ale część to wyłącznie info poboczne - bardziej egzotyczne
i definiowalne przez usera parametry serializowałem (tablica parametrów
-> pole tekstowe) - parametry, typy, nazwy administracyjne, opisy,
domyślne wartości ... wsio prościutko definiowalne przez pliki/tablice
php/xml/yaml i generowane do administracji, do klienta itp. - oczywisty
dodatkowy koszt deserializacji pól dodatkowych, ale praktycznie tylko na
poziomie pojedynczego rekordu a jakby się uprzeć to i wyfiltrować też
można było "po istnieniu" w zserializowanym polu nazw zmiennych (zapis
tylko zdefiniowanych) - w przypadku konieczności optymalizacji
wydajności można zawsze dobudować tabele indeksowe