eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingproblem projektowy w aplikacji bazodanowejRe: problem projektowy w aplikacji bazodanowej
  • Date: Thu, 29 Sep 2011 20:08:55 +0200
    From: lolo <n...@n...com>
    User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9.2.22) Gecko/20110902
    Thunderbird/3.1.14
    MIME-Version: 1.0
    Newsgroups: pl.comp.programming
    Subject: Re: problem projektowy w aplikacji bazodanowej
    References: <2...@n...onet.pl>
    In-Reply-To: <2...@n...onet.pl>
    Content-Type: text/plain; charset=ISO-8859-2; format=flowed
    Content-Transfer-Encoding: 8bit
    NNTP-Posting-Host: 83.14.214.74
    Message-ID: <4e84b435$1@news.home.net.pl>
    X-Trace: news.home.net.pl 1317319733 83.14.214.74 (29 Sep 2011 20:08:53 +0200)
    Organization: home.pl news server
    Lines: 36
    X-Authenticated-User: a...@s...home.pl
    Path: news-archive.icm.edu.pl!news.icm.edu.pl!nf1.ipartners.pl!ipartners.pl!news.home
    .net.pl!not-for-mail
    Xref: news-archive.icm.edu.pl pl.comp.programming:192548
    [ ukryj nagłówki ]


    > 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

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: