[postgres][php] Schemat bazy danych do wielu wskaznikow na czlowieka, Czy to dobry schemat do przedstawionego problemu ? Opcje

[calebos]

Czesc

Mam zadanie w ktorym jest bardzo wiele wartosci na obiekt ( czlowiek,jego loginy w systemach). Dokładając wyliczane wskazniki bedzie to kilkaset kolumn.

Oczywiscie będę ograniczał max ilosc kolumn do pokazania na www natomiast chce dać userowi możliwosc wybrania ze wszystkiego.
Do tego pojawia się problem tego że ilosc tych danych się zmienia. Np ktoś wymysli jakis nowy wskaznik wiec to u mnie 'nowa kolumna'.

Nie chcac ciagle modyfikowac schematu bazy danych pomyslalem sobie ze przeniosę schemat o poziom wyzej. Tzn nie rozwazam tu nad tablicami per mój problem na doradce itp tylko w jednej tablicy przyjmuje WARTOSCI a w drugiej mam do nich slownik w natępujący sposób.

[SQL] pobierz, plaintext 
REATE TABLE system_data_day
(
  id integer NOT NULL DEFAULT NEXTVAL('system_data_id_seq'::regclass),
  id_wartosci integer NOT NULL,
  wartosc_z_dnia timestamp without time zone NOT NULL,
  wartosc numeric(10,2) NOT NULL DEFAULT 0,
  CONSTRAINT pri_key_data PRIMARY KEY (id),
  CONSTRAINT id FOREIGN KEY (id_wartosci)
      REFERENCES system_data_nazwy (id) MATCH SIMPLE
      ON UPDATE RESTRICT ON DELETE RESTRICT
)
[SQL] pobierz, plaintext 

oraz

[SQL] pobierz, plaintext 
CREATE TABLE system_data_nazwy
(
  id serial NOT NULL,
  obiekt_nazwa text NOT NULL,
  wartosc_nazwa text NOT NULL,
  CONSTRAINT pri_key_data_nazwa PRIMARY KEY (id),
  CONSTRAINT unique_system_data_nazwy UNIQUE (obiekt_nazwa, wartosc_nazwa)
)
[SQL] pobierz, plaintext 

Ponieważ ostatecznym wynikiem jaki potrzebuje to JSON z wieloma kolumnami to jako dane ostateczne do tabelki generuje sobie takie jsony ze stanem wartosci na dzien i pozniej radzę sobie PHP z ostatecznymi zapotrzebowaniami klienta ( wybor kolumn,sortowania itp).

Pytanie co o tym myślicie.
Generalnei trzymajac sobie dane w postaci
PRACOWNIK | WARTOSC_A | WARTOSC_B ..... mam niejako łatwe zadanie z generowaniem ostatecznego wyniku dla tabelek ale jakiekolwiek zmiany wymagaja ingerencji w schemat bazy ( dokładanie kolumny,modyfikacje zapytań).

Moja postać daje proste opcje. Chce dorzucic cos nowego do dokładam wiersze a nie kolumny. Wadą natomiast jest to że tabelka ktora trzyma wartośći dla moich pracowników osiąga kilkadziesiąt milionow ( w produkcji pewnie dojdzie do kilkuset milionów). Czy powinienem się bać tej wartosci ?
Macie moze jakis inny pomysl ?

[Zbłąkany]

O widokach nie czytał? Twój pomysł jest głupi, bo po przekroczeniu pewnej wartości rekordów komputer tego nie uciągnie (albo tak Ci zacznie orać dysk, że się zdziwisz) i będziesz mieć problem (IMG:style_emoticons/default/tongue.gif) . Poza tym każda baza powinna być znormalizowana, choćby po to, by nie mieszać ze sobą danych, które do siebie nie pasują tematycznie lub pod względem typu. Chcesz minimalistyczne rozwiązanie? Cztery tabele: features(id, value), feature_values(id, value), users(id, rest of fields), main_relation(user_id, feature_id, feature_value_id, timestamp). Takie rozwiązanie ma jedną wadę: każda akcja/cecha/opcja musi być tego samego typu. A co gdy masz jakąś liczbę i chciałbyś na niej przeprowadzić proste działanie matematyczne? Wyciągnięcie, konwersja, działanie i z powrotem konwersja do tekstu? Zastanów się nad tym.