eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingOptymalizacjaRe: Optymalizacja
  • Path: news-archive.icm.edu.pl!news.rmf.pl!agh.edu.pl!news.agh.edu.pl!news.onet.pl!.PO
    STED!not-for-mail
    From: Michal Kleczek <k...@g...com>
    Newsgroups: pl.comp.programming
    Subject: Re: Optymalizacja
    Date: Fri, 13 May 2011 10:56:48 +0200
    Organization: http://onet.pl
    Lines: 59
    Message-ID: <iqiroi$mf8$1@news.onet.pl>
    References: <iqimud$ql$1@news.onet.pl>
    NNTP-Posting-Host: 87-205-150-44.adsl.inetia.pl
    Mime-Version: 1.0
    Content-Type: text/plain; charset="UTF-8"
    Content-Transfer-Encoding: 8Bit
    X-Trace: news.onet.pl 1305277010 23016 87.205.150.44 (13 May 2011 08:56:50 GMT)
    X-Complaints-To: n...@o...pl
    NNTP-Posting-Date: Fri, 13 May 2011 08:56:50 +0000 (UTC)
    User-Agent: KNode/4.4.9
    Xref: news-archive.icm.edu.pl pl.comp.programming:190260
    [ ukryj nagłówki ]

    MoonWolf wrote:

    > Mamy w firmie różnice zdań i chciałem się zorientować w pewnej kwestii.
    >
    > Baza danych będzie prosta - rekord z 'nazwą' danej, jej wartością i
    > datą zapisania (każda dana to jeden rekord, danych będzie kilkanaście,
    > zapis co 10sek 24h/7/365. Źródeł tych danych będzie więcej, dla każdego
    > przewidziana jest osobna tabela, będzie tego nieokreślona liczba - na
    > pewno będą przybywać).
    >

    A dlaczego tak?
    To mi pachnie modelem EAV - nie lepiej dla kazdej "danej" oddzielna relacje
    (tabele)?

    > Pytanie jest takie: czy warto (a jeśli tak to w jakich okolicznościach)
    > 'upakowywać' dane składowane w bazie - na takiej zasadzie, że jeśli
    > dana się nie zmieniła to robimy update rekordu zmieniając datę na
    > aktualną (czyli w skrajnym wypadku w bazie będzie jeden rekord
    > dotyczący danej, która nigdy się nie zmieniła). Dane będą różne - ale
    > zawsze zdarzą się serie powtarzających się wartości.

    To zalezy od wymagan funkcjonalnych.
    Nie wiem dlaczego kolejne odczyty z urzadzen sa nieistotne jezeli ich
    wartosc sie nie zmienila w stosunku do poprzedniego, ale sa istotne jezeli
    sie zmienila. Dodatkowo istotna jest jeszcze informacja o czasie ostatniego
    odczytu.
    (Powyzsze jest tylko wnioskiem z tego, ze istnieje mozliwosc "upakowania")
    Jezeli istotny jest fakt, ze nastapila _zmiana_ wartosci (a nie wartosc sama
    w sobie) to moze w ogole inny model jest potrzebny?

    >
    > Z danych tych będą sporządzane wykresy

    LOL - no jasne ze beda jakies zestawienia (byc moze w postaci wykresow) - w
    koncu po cos te dane sa przechowywane.

    A tak powaznie - w zaleznosci od tego jakie te wykresy (czyli co z bazy
    chcesz wyciagnac), model danych bedzie inny.

    > (raczej dla każdego źródła
    > osobno - czyli zapytania w obrębie jednej tabeli) - tutaj właśnie
    > powstała różnica zdań. Niektórzy boją się dużej liczby danych do
    > obrobienia (po kilku latach) i długiego czasu generowania wykresu.
    > Przeciwnicy twierdzą, że po to jest baza danych, żeby składować dane a
    > takie kombinacje w kodzie aplikacji zniweczą oszczędności. I w ogóle
    > pachnie to 'premature optimization'.

    Tak.

    >
    > Dodatkowe pytanie - czy język programowania lub silnik bazy danych może
    > mieć wpływ na odpowiedź na to pytanie (celowo nie wspomniałem w czym to
    > jest robione)?

    Oczywiscie.

    --
    Michal

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

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: