Newsgroup: it.comp.software.database
Titolo: Id univoci e azzeramento contatori

nella progettazione di un nuovo DB, e' prevista la gestione di un contatore 
univoco tramite Trigger e/o StoredProcedure;
fino a qui non sembrano esserci controindicazioni ma il dubbio e' questo:
es. Tabella Clienti
- eseguo l'importazione dei dati esistenti da un file csv, vengono generati 
gli ID basati sul contatore calcolato dal trigger,
e per ipotesi si abbia ClienteA associato all'ID_Cliente = 540, e che l'ID 
abbia raggiunto un valore 3000
- se viene eseguita una nuova importazione, si puo' si Azzerarare la Tabella 
Clienti, ma il contatore ripartira' da 3001.
Il db e' Firebird 2.1 ma la logica vale anche per Oracle o SqlServer
  //calcola progressivo
  SqlSp_Spese.StoredProcName := 'CON_TB_SPESE_ID';
  SqlSp_Spese.ExecProc;
vi e' un modo per azzerare i contatori ? , ovvio non da console  a mano si 
fa.
Maurizio
 

 fa.
Intendi
SET GENERATOR "nome" TO 0;
O usando Sequence:
http://www.firebirdsql.org/manual/generatorguide-sqlsyntax.html
| Client SQL
| SET GENERATOR <GeneratorName> TO <NewValue>;
| 
| This is useful to preset generators to a value other than 0 (which is the
| default value after you created it) in e.g. a script to create the
| database. Just like CREATE GENERATOR, this is a DDL (not DML) statement.
| 
| 
| Preferred syntax for Firebird 2 and up:
| ALTER SEQUENCE <SequenceName> RESTART WITH <NewValue>;
Comunque usare degli id autoincrement in quel modo è abbastanza un suicidio
imho.

 
hum...
dubbio...
non e' che hai assegnato a un valore autoincrementante un significato non 
previsto?
un campo autoincrementante *NON* serve per contare il numero di righe in 
tabella, quindi il fatto che parta da 0 o da 3000 non ti deve creare 
problemi.
se invece fai dei ragionamenti basati sul fatto che max(id) = count(*), 
imho devi rivedere un po' di cose nella struttura del db.
se cancelli la riga con contatore = 1950 rinumeri tutte le altre?
-- 
Paolo opg
BE AWARE that this post uses a fake reply-to address
to contact me write to:
janickg ( at ) hotmail ( dot ) com
--

 imho devi rivedere un po' di cose nella struttura del db.
Se ho capito bene è ben peggio.
Mi sa che ha tabelle correlate a quell'id del cliente, es. 
FATTURE (IDCliente_FK, Data ecc.)

"Andrea [Work]"  ha scritto

e' proprio per evitare questo;
se assegno ad un Cliente un ID univoco, questo me lo porto dietro, in ogni
operazione che coinvolga quel cliente, e non mi pare sia una gran cosa,
per questo ho chiesto se ci sono vie migliori.
In pratica
- acquisisco i Clienti e ciascuno ha un suo ID univoco generato dal DB
- uso un Cliente
- ma ad un certo punto viene fatta una nuova importazione, nessuno 
garantisce
  che l'ID usato la prima volta resti valido
Importazione 1 - da file testo csv - diciamo ci siano 500 Clienti
ID Ragione Sociale
---------------------
1
2
...
200 Pinco Pallino
...
500
uso il Cliente 200 nelle varie operazioni, ma poi per qualche ragione
serve fare una nuova Importazione, che magari ha sempre 500 Clienti
ma nessuno puo' dire se Pinco Pallino potra' avere ancora ID 200.
Neppure generare un ID Cliente a mano puo' andare bene, se ci sono 2
accessi contemporanei, possono succedere casino nel calcolo del ID Cliente.
Maurizio 

 
e adesso la multiutenza.
vediamo se ho capito.
devi fare importazioni bulk, ripetute nel tempo, potenzialmente 
importando piu' volte la stessa anagrafica, da piu' postazioni 
contemporaneamente, per popolare una tabella da usare per uno scopo non 
precisato (fatturazione?), prendendo i dati da una fonte ignota (sempre 
la stessa? fonti diverse?).
imho ti conviene spiegare cosa vuoi ottenere.
finora hai descritto quali sono i problemi che hai incontrato 
nell'applicare la soluzione che hai pensato tu per risolvere un problema 
di cui non ci hai detto niente.
(no, il problema non e' 'importare mille volte la stessa anagrafica')
perche' ti serve importare e reimportare piu' volte le stesse anagrafiche 
da piu' postazioni contemporaneamente?


 accessi contemporanei, possono succedere casino nel calcolo del ID Cliente.
Il problema è che non DEVI usare l'ID che ti danno internamente per le tue
relazioni.
Fossi io farei così, avrei un mio ID che sarebbe ovunque.
Poi eventualmente aggiungi un campo ID_IMPORTATO che usi in importazione.
Ti arriva il file csv, c'è id=200, cerchi un record con ID_IMPORTATO=200 se
non c'è lo inserisci nuovo (col tuo ID che sarà es. il 3000, e con
ID_IMPORTATO=200), se lo trovi fai un UPDATE dei Campi.
La fattura o altra tabella sarà correlata con ID=3000.
Se quel campo che ti passano è univoco puoi renderlo tale anche nel tuo DB,
così puoi fare l'update WHERE ID_IMPORTATO=200, altrimenti per essere
sicuro dovresti vedere a quale tuo ID interno corrisponde e fare WHERE
ID=3000 o WHERE ID=(Select First 1 ID From TAB Where ID_IMPORTATO=200) che
comunque sarebbe un porcaio se non univoco.
Direi che ti basta creare una colonna nuova ID_IMPORTATO la setti
inizialmente = ID e poi in importazione lo gestisci.

>
non da piu' postazioni , quello e' il motivo per cui non e' logico creare un 
ID a
mano, ma lascarlo fare al DB.
per non creare gli ID ad ogni importazione,
potrei scorrere il file csv e verificare se un certo nominativo esiste,
e trattandosi di anagrafica persone, puo' variare solo l'indirizzo o il 
comune di
nascita, a quel punto se il nominativo esiste (ovvero ID assegnato), potrei 
passare
al successivo, e se questo non risulta presente generare un nuovo ID 
univoco.
in generale al di la' del problema specifico, dove mi e' venuto il dubbio 
sugli
ID univoci, mi pare di capire che questi vengono usati come identificatore
unico per il Cliente (caso Contabilita' / Fatturazioni).
Maurizio 

 
l'id univoco viene usato come identificatore dell'entita' che stai
trattando. 
se hai una lista di autovetture, identifica una vettura; se hai
l'anagrafica di una stalla, identifica la mucca, la capra, la pecora, se
hai una lista di cd, distingue le opere di lady gaga da quelle di
mozart. 
hai presente i numerini sotto i codici a barre dei libri? sono
l'identificatore univoco usato per catalogare i libri. 
e id univoco *NON IMPLICA* id numerico.


>
dovro' per forza ricorrere alla verifica "seconda soluzione"
Maurizio