[SQL] UPDATE e INSERT o DELETE e INSERT ?
GiuseppeD
in una ListView ho le seguenti due situazioni:
1- es. al caricamento 5 righe, ne aggiungo 2 alla ListView
per l'UPDATE posso eseguire:
1.1 - UPDATE delle 5 righe iniziali e inserimento delle 2 nuove
1.2- DELETE delle 5 righe iniziali e inserimento delle 7 righe presenti
nella ListView.
L'identificativo del record non è in relazione con nessuno
Quale metodo di solito adottate ?
2- es. al caricamento 5 righe, ne elimino 2 dalla ListView
ragionamento come sopra
Grazie
giuseppeD
Luke
io generalmente faccio DELETE e INSERT, lo trovo piu' pulito e meno a
rischio di errori soprattutto se si usa un programma in rete (se si fa un
UPDATE su un record che non esiste devi gestire l'errore mentre il DELETE
non fa niente)
inoltre per sapere se una riga e' cambiata devi fare un sacco di confronti
(ovviamente a seconda di quanti valori possono cambiare)
Luca
Lupo
HGfcc.23075$rM4.1...@news4.tin.it] ha scritto:
Io adotto un sistema solo: faccio una cosa sola, nel momento in cui avviene.
Aggiungo una riga? La aggiungo nel database.
Elimino una riga? La elimino dal database.
Modifico? La modifico sul database.
"L'identificativo del record non è in relazione con nessuno"?
Non capisco... Manca un riferimento al record?
E come fai a dire "Update delle 5 righe iniziali" se non le conosci in modo
preciso?
Luke
> in una ListView ho le seguenti due situazioni:
[...]
> > L'identificativo del record non è in relazione con nessuno
[...]
> "L'identificativo del record non è in relazione con nessuno"?
> Non capisco... Manca un riferimento al record?
> E come fai a dire "Update delle 5 righe iniziali" se non le conosci in
modo
> preciso?
credo intenda dire che gli ID dei record usati nella ListView non vengono
usati per relazioni con altre tabelle
GiuseppeD
news:4071...@x-privat.org...
> > Salve a tutti,
> > in una ListView ho le seguenti due situazioni:
>
> [...]
>
>
> [...]
>
> > "L'identificativo del record non č in relazione con nessuno"?
> > Non capisco... Manca un riferimento al record?
> > E come fai a dire "Update delle 5 righe iniziali" se non le conosci in
> modo
> > preciso?
>
> credo intenda dire che gli ID dei record usati nella ListView non vengono
> usati per relazioni con altre tabelle
Carico la Lista con un idcategoria e Path/nomefile.estensione
Per un idcategoria posso caricare piů path
al Add sulla ListView verifico se il path č presente.
Quindi se carico, nella Lista, un idcategoria con 5 path,
se l'operatore aggiunge altri due path, che non posso salvare al momente
dell'Add,
mi trovo gestire 5 record vecchi e due nuovi.
per i 5 vecchi utilizzo l'accoppiata idcategoria + path, per l'UPDATE,
ma anche per i nuovi, l'inserimento č l'accoppiata idcategoria + path.
Dovendo eseguire il tutto a fine operazione č meglio cancellare i 5 presenti
in tabella,
e inserire i 7 record presenti nella ListView, con una Transazione, come
suggerito da Luke;
o UPDATE per i 5 record vecchi e INSERT solo per i due nuovi ?
Ave
giuseppeD
Lupo
rvicc.18156$hc5.8...@news3.tin.it] ha scritto:
> "Luke" <aaa...@aaaaaa.aa> ha scritto nel messaggio
> news:4071...@x-privat.org...
>>> Salve a tutti,
>>> in una ListView ho le seguenti due situazioni:
>>
>> [...]
>>
>>>> L'identificativo del record non è in relazione con nessuno
>>
>> [...]
>>
>>> "L'identificativo del record non è in relazione con nessuno"?
>>> Non capisco... Manca un riferimento al record?
>>> E come fai a dire "Update delle 5 righe iniziali" se non le conosci
>>> in modo preciso?
>>
>> credo intenda dire che gli ID dei record usati nella ListView non
>> vengono usati per relazioni con altre tabelle
>
> Carico la Lista con un idcategoria e Path/nomefile.estensione
> Per un idcategoria posso caricare più path
> al Add sulla ListView verifico se il path è presente.
Bene, si può dire che IDcategoria+Path\Nomefile è la chiave univoca
> Quindi se carico, nella Lista, un idcategoria con 5 path,
> se l'operatore aggiunge altri due path, che non posso salvare al
> momente dell'Add,
Perchè? Solo perchè non vuoi, mi può star bene, ma solo per questo...
> mi trovo gestire 5 record vecchi e due nuovi.
> per i 5 vecchi utilizzo l'accoppiata idcategoria + path, per l'UPDATE,
> ma anche per i nuovi, l'inserimento è l'accoppiata idcategoria + path.
> Dovendo eseguire il tutto a fine operazione è meglio cancellare i 5
> presenti in tabella,
> e inserire i 7 record presenti nella ListView, con una Transazione,
> come suggerito da Luke;
> o UPDATE per i 5 record vecchi e INSERT solo per i due nuovi ?
Beh, visto come la metti, i problemi sono due, secondo me da gestire
separatamente, record per record o con due comandi SQL: l'update delle
informazioni esistenti + l'aggiunta delle nuove e l'eliminazione delle
vecchie.
Personalmente, sempre costretto dalle tue imposizioni, looperei fra le
chiavi (non necessariamente la Key) della ListView e, per non saper nè
leggere nè scrivere, ne verificherei l'esistenza. Se esiste e se il caso,
farei l'aggiornamento, se non esiste la aggiungo. Poi looperei fra le chiavi
del database e eliminerei quelle che non esistono nel listview.
Se fossi libero, farei le cose nel momento in cui avvengono. Non desidero
insistere, ma mi cito, stavolta al contrario, ma il concetto non cambia:
qual è la sostanziale differenza fra il disporre di un'informazione a un
secondo di distanza dalla precedente o a un anno (si fa per dire) di
distanza? La mia risposta è sempre la stessa: nessuna. Per chiarire: anche
se tu riuscissi a far tutto con un singolo comando SQL, esisterebbe sempre
la possibilità che un'altra postazione trovi una situazione parziale, non
corrispondente alla realtà finale, anche se questa diventasse vera un
secondo (o un anno) dopo.
GiuseppeD
news:c4sf08$2l39g7$1...@ID-174464.news.uni-berlin.de...
Taglio
Penso di optare per la doppia azione
UPDATE per gli esistenti e
INSERT per i nuovi
> Se fossi libero, farei le cose nel momento in cui avvengono. Non desidero
> insistere, ma mi cito, stavolta al contrario, ma il concetto non cambia:
> qual è la sostanziale differenza fra il disporre di un'informazione a un
> secondo di distanza dalla precedente o a un anno (si fa per dire) di
> distanza? La mia risposta è sempre la stessa: nessuna. Per chiarire: anche
> se tu riuscissi a far tutto con un singolo comando SQL, esisterebbe sempre
> la possibilità che un'altra postazione trovi una situazione parziale, non
> corrispondente alla realtà finale, anche se questa diventasse vera un
> secondo (o un anno) dopo.
In questo caso non ho conflitto di multiutenza
Ave
giuseppeD
Lupo
vnjcc.18408$hc5.8...@news3.tin.it] ha scritto:
>> Beh, visto come la metti, i problemi sono due, secondo me da gestire
>> separatamente, record per record o con due comandi SQL: l'update
>> delle informazioni esistenti + l'aggiunta delle nuove e
>> l'eliminazione delle vecchie.
>>
>> Personalmente, sempre costretto dalle tue imposizioni, looperei fra
>> le chiavi (non necessariamente la Key) della ListView e, per non
>> saper nč leggere nč scrivere, ne verificherei l'esistenza. Se esiste
>> e se il caso, farei l'aggiornamento, se non esiste la aggiungo. Poi
>> looperei fra le chiavi del database e eliminerei quelle che non
>> esistono nel listview.
>
> Penso di optare per la doppia azione
> UPDATE per gli esistenti e
> INSERT per i nuovi
Ok. E l'eliminazione delle non piů esistenti?
>
>> Se fossi libero, farei le cose nel momento in cui avvengono.
...
>
> In questo caso non ho conflitto di multiutenza
... a maggior ragione... sempre IMHO
Luca Menegotto
On Mon, 05 Apr 2004 16:19:51 GMT, "GiuseppeD"
<NoSpam_ebq...@tin.it> wrote:
>1.1 - UPDATE delle 5 righe iniziali e inserimento delle 2 nuove
E magari metto tutto in una bella transazione, cosi' non mi crea
difficolta'. Questo, ovviamente, nell'ipotesi in cui per le prime 5 ci
sia stata qualche variazione. Se non c'e' stata, un bell'INSERT INTO e
via il pensiero.
>
>2- es. al caricamento 5 righe, ne elimino 2 dalla ListView
>ragionamento come sopra
Questo e' ancora piu' semplice: DELETE FROM xxx WHERE ID = 1111 OR ID
= 222. Qui e' un'operazione unica, per cui la transazione non serve.
Il principio di base - che anche a me e' stato insegnato, ell'epoca -
e': se c'e' un sistema efficiente per fare una cosa su un database,
non ti affannare a reinventare l'acqua calda! Nota che ovviamente la
cosa si applica soprattutto quando si parla di DBMS.
Ciao!
Luca