linux user group brescia

>Indexes are a common way to enhance database performance.
ecco, a me non serve, serve al db

>Per l'autoincremento (e in generale per quei casi in cui si vuole un
valore
>successivo di default) si parla di sequenza.
grazie, mi scuso, da ora in poi cerchero' di parlare solo in standard SQL99
:-)

>Cioe' questo attributo autoincrementante fa da chiave primaria per una
>tabella "master" mentre altre tabelle hanno attributi che hanno constraint
di
>integrita' referenziale verso di esso? Si puo' fare, certo.
e' quel che ho fatto !

>Guarda, per me sei a posto cosi'. E' solo che quando spieghi io non
capisco
>una sega :-)
guarda, dal vivo non sembro cosi' pirla, almeno spero...

> > ineriths?
>Si' OK. Ma tu perche' pensavi di usarlo?
per usare tabelle relazionate tra loro senza penare tanto,
ma alla prima occhiata sembra che vada a rovescio di quel che mi serve,
anche se studiandoci meglio una strada per ottenere quel che voglio
probabilmente ci sarebbe.
ma ormai e' andata ..

>> ecco, a questo non avevo pensato, posso mettere una primary key
>> e un serial NOT NULL di riferimento per l'integrita' referenziale.
>Se metti PRIMARY KEY il seriale della tabella "primaria" e FOREIGN KEY
>quello della tabella "secondaria" che si riferisca a anagrafica.id non
>funziona? Il NOT NULL non serve.
ecco, ci risiamo, mi sono spiegato male
una colonna serial not null unique
e un' altra colonna primary key
l'ho fatto e va e principalmente mi serve perche' access vuole una primary
key,
e se ci metto un seriale non capisce che il valore lo mette in automatico
postgres
cosi' ne ho due, una seriale not null unique che e' quella che mi serve per
relazionare le tabelle
e una primary key (p.es. ragione sociale) da inserire a mano.

ormai ci siamo, ho un bel dump funzionante con tutto dentro, ripasso di
fino i campi obbligatori, le valute,
inserisco i permessi e stasera o domani carico i dati e poi comincio con il
test dei front-end.

>Good Luck!
grazie
ciao
furio