PK Increment Vs Chiavi composte Vs Calcolate

[Andrea (Work)]

Buongiorno a tutti,
negli anni spesso ho usato campi auto increment sulle tabelle, ma mi sto
rendendo conto che nell'ottica di trasferimento file da sorgenti diversi
(es. una presa ordini da parte di un agente), e sincronizzazioni varie sono
abbastanza complesse da gestire.

Nell'esempio dell'ordine la mia chiave anzichč l'increment potrebbe essere
Anno+Numero.
Il problema di questo approccio č che su un paio di livelli testa/righe i
campi chiave diventano sempre di piů, es. le righe dell'ordine diventerebbe
Anno+Numero+NumRiga, e di conseguenza le join ingestibile.

Pensavo quindi ad un approccio un po' diverso. Nella testata ho i miei
campi Anno e Numero, ma creo un campo Cod (char) che compongo 16000001
(2016/1). A questo punto le righe fanno riferimento ad un solo campo, e qui
la chiave potrebbe diventare 160000010001 (2016/1 riga 1).
Lo svantaggio č che bisogna dimensionare il campo char con sicurezza, e che
la grandezza del campo chiave č maggiore.

Quali sono le vostre espereizne o consigli?
Grazie

[enoquick]

Il 28/07/2016 09:49, Andrea (Work) ha scritto:
> Buongiorno a tutti,
> negli anni spesso ho usato campi auto increment sulle tabelle, ma mi sto
> rendendo conto che nell'ottica di trasferimento file da sorgenti diversi
> (es. una presa ordini da parte di un agente), e sincronizzazioni varie sono
> abbastanza complesse da gestire.
>

> Nell'esempio dell'ordine la mia chiave anzichè l'increment potrebbe essere
> Anno+Numero.
> Il problema di questo approccio è che su un paio di livelli testa/righe i
> campi chiave diventano sempre di più, es. le righe dell'ordine diventerebbe

> Anno+Numero+NumRiga, e di conseguenza le join ingestibile.
>
> Pensavo quindi ad un approccio un po' diverso. Nella testata ho i miei
> campi Anno e Numero, ma creo un campo Cod (char) che compongo 16000001
> (2016/1). A questo punto le righe fanno riferimento ad un solo campo, e qui
> la chiave potrebbe diventare 160000010001 (2016/1 riga 1).

> Lo svantaggio è che bisogna dimensionare il campo char con sicurezza, e che
> la grandezza del campo chiave è maggiore.

>
> Quali sono le vostre espereizne o consigli?
> Grazie
>

Sono anni che progetto db relazionali.
Il consiglio,che è poi quello faccio io,è di usare le sequence (o
autoincrement a dir si voglia) solo per le relazioni
Per questo il numero inserito nella sequence non ha significati
particolari (al massimo come sequenza temporale ma non e' detto che sia
contigua)
La sequence nella tabella che dovrebbe avere la pk deve diventare una pk
a sua volta (altrimenti le relazioni non si possono fare) e quella che
dovrebbe essere la chiave primaria diventa una semplice chiave univoca
con eventuale null sulle colonne (non si possono avere piu pk per tabella).

[Andrea (Work)]

Il Thu, 28 Jul 2016 21:04:16 -0500, enoquick ha scritto:

> Sono anni che progetto db relazionali.
> Il consiglio,che è poi quello faccio io,è di usare le sequence (o
> autoincrement a dir si voglia) solo per le relazioni
> Per questo il numero inserito nella sequence non ha significati
> particolari (al massimo come sequenza temporale ma non e' detto che sia
> contigua)
> La sequence nella tabella che dovrebbe avere la pk deve diventare una pk
> a sua volta (altrimenti le relazioni non si possono fare) e quella che
> dovrebbe essere la chiave primaria diventa una semplice chiave univoca
> con eventuale null sulle colonne (non si possono avere piu pk per tabella).

Quindi dici che nelle tabelle "anagrafiche", es. articoli, cod.pagamento
ecc. di non usare sequence, ma solo nelle tabelle testa/righe?

Usando le sequence però ci si complica non poco il lavoro quando c'è da
estrarre e reinserire valore. Pensa solo a importare un testa/righe,
inserisci testa, prendi il valore del sequence, usalo nelle righe.

Con una chiave testuale, se ben generata, non te ne accorgi nemmeno.

[enoquick]

le join si fanno con le sequence non con le ex chiave primarie
Le sequence servono proprio per disaccoppiare i valori tra un tabella e
l'altra nelle relazioni.

[Andrea (Work)]

Il Fri, 29 Jul 2016 20:48:30 -0500, enoquick ha scritto:

>> Quindi dici che nelle tabelle "anagrafiche", es. articoli, cod.pagamento
>> ecc. di non usare sequence, ma solo nelle tabelle testa/righe?
>>
>> Usando le sequence però ci si complica non poco il lavoro quando c'è da
>> estrarre e reinserire valore. Pensa solo a importare un testa/righe,
>> inserisci testa, prendi il valore del sequence, usalo nelle righe.
>>
>> Con una chiave testuale, se ben generata, non te ne accorgi nemmeno.
>>
>
> le join si fanno con le sequence non con le ex chiave primarie
> Le sequence servono proprio per disaccoppiare i valori tra un tabella e
> l'altra nelle relazioni.

Questo però non mi obbliga ad usare un campo di tipo sequence, quanto un
campo generato da me con una mia logica, che ha il vantaggio di poter
essere trasferito fra DB diversi senza sostituzioni di valore.

[enoquick]

Nessuno e' obbligato a fare qualcosa,e tanto meno posso farlo io.
Premesso questo il vantaggio delle sequence sta nel fatto che non serve
la ex pk per legare le tabelle e se sono chiavi multiple e' una seccature.
Senza parlare dell'agg. di una ex pk come valore o come modifica.
Se non vedi il vantaggio in questo non so che dirti
Ma sta sempre a te scegliere i vari metodi,tu volevi un confronto ed io
te l'ho dato.