Re: [postgresql-it] Consiglio su separazione campi di una tabella
- From: Giorgio Ponza <ponzagiorgio@xxxxxxxxx>
- To: postgresql-it <postgresql-it@xxxxxxxxxxxxx>
- Date: Wed, 02 Apr 2008 12:07:28 +0200
Ing. Claudio Rossi wrote:
Se ho capito in modo corretto, il tuo database non e' normalizzato.
Potresti scrivermi lo schema della tabella (o almeno un esempio
simile) e dire quali campi sono quelli che richiedono ulteriori insert
e quali rimangono uguali invece?
Molto volentieri, ecco lo schema della tabella a cui ho scritto sulla
destra --> FISSO se il campo viene scritto solo all'inserimento del
record e mai modificato, oppure --> UPDATE se invece viene aggiornato
almeno una volta
CREATE TABLE positions
(
pos_id BIGINT DEFAULT nextval('seq_positions'), --> FISSO
pos_serial VARCHAR NOT NULL, --> FISSO
pos_longitude DOUBLE PRECISION NOT NULL, --> FISSO
pos_latitude DOUBLE PRECISION NOT NULL, --> FISSO
pos_speed SMALLINT NOT NULL DEFAULT 0, --> FISSO
pos_date TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, --> FISSO
pos_type INTEGER NOT NULL DEFAULT 1000, --> FISSO
pos_altitude INTEGER DEFAULT 0, --> FISSO
pos_valid BOOLEAN NOT NULL DEFAULT TRUE, --> FISSO
pos_analog_in BYTEA, --> FISSO
pos_digital_in BYTEA, --> FISSO
pos_digital_out BYTEA, --> FISSO
pos_distance DOUBLE PRECISION NOT NULL DEFAULT 0, --> UPDATE
elab_distance BOOLEAN NOT NULL DEFAULT FALSE, --> UPDATE
pos_address VARCHAR, --> FISSO
pos_housenumber VARCHAR, --> FISSO
pos_zip VARCHAR, --> FISSO
pos_place VARCHAR, --> FISSO
elab_alarm BOOLEAN NOT NULL DEFAULT FALSE, --> UPDATE
tot_alarms INTEGER NOT NULL DEFAULT 0, --> UPDATE
pos_trip VARCHAR DEFAULT NULL, --> UPDATE
pos_calctype INTEGER NOT NULL DEFAULT 0, --> UPDATE
pos_direction VARCHAR, --> UPDATE
pos_timediff BIGINT DEFAULT 0, --> UPDATE
elab_timediff BOOLEAN NOT NULL DEFAULT FALSE, --> UPDATE
elab_counters BOOLEAN NOT NULL DEFAULT FALSE --> UPDATE
) WITHOUT OIDS;
Sono in tutto 16 campi fissi e 10 aggiornabili. Quello che pensavo io
era di spostare i 10 campi aggiornabili in una tabella separata (visto
che contengono molti meno dati dei 16 fissi), in relazione 1-1.
Il ragionamento che facevo io era sul vacuum full, in quanto con questa
soluzione la tabella con tante tuple segnate 'vacuumable' sarebbe piu'
piccola (dal punto di vista dello spazio occupato) e teoricamente il
tempo impiegato migliore.
Da questo ragionamento poi, volendo essere piu' teorici, si potrebbe
fare un discorso su come comportarsi in questi casi, cioe' conviene
separare sempre le tabelle in questo modo?
Se hai voglia, oltre magari a darmi un suggerimento per questo problema
specifico, potresti condividere con me (e gli altri della lista) le tue
idee su questo tipo di problemi (riconducibili magari anche alla
normalizzazione).
Grazie ancora
Giorgio Ponza
Ciao a tutti,
volevo chiedervi un consiglio su un'idea che mi e' venuta.
Premetto che utilizzo PostgreSQL 8.2.5
Ho una tabella che mantiene le posizioni GPS di tante centraline che
girano in Italia. Questi punti vengono elaborati N volte (ad esempio una
volta vengono calcolate le distanze, altre volte i viaggi, le
statistiche etc). Queste elaborazioni sono separate e devono rimanere
separate.
Di questa tabella, 17 campi vengono scritti solo la prima volta
(all'atto dell'inserimento) e 10 invece vengono ripetutamente rielaborati.
Siccome i punti cominciano a diventare tanti (decine di migliaia di
punti vengono aggiunti ogni giorno), sto notando un rallentamento
durante il vacuum full che eseguo ogni notte.
Ho pensato che magari potrei separare la tabella in 2, dove in una metto
i campi 'fissi' e nell'altra i campi 'modificabili'. In questo modo
avrei lo svantaggio della JOIN se voglio tutti i dati, ma le tuple
segnate come 'vacuumabili' dovrebbero avere una dimensione ridotta, e
quindi il vacuum forse ne trarrebbe vantaggio.
Qualcuno di voi ha gia' avuto questo problema e magari ha trovato una
soluzione intelligente? Oppure secondo voi in questo modo complicherei
solo lo schema senza dare vantaggi al vacuum? (purtroppo non ho la
possibilita' di fare prove in produzione :D ).
Grazie a tutti
Giorgio Ponza
_______________________________________________
Postgresql-it mailing list
Postgresql-it@xxxxxxxxxxxxx
http://lists.psql.it/mailman/listinfo/postgresql-it
Other related posts:
