Chiave primaria non INT

di il
12 risposte

Chiave primaria non INT

Ho una curiosità. Il mio gestionale, Mago.Net di Zucchetti, usa un database SQL.
Andando a spulciare fra le varie tabelle ho notato che la chiave primaria non è mai un campo INT, ma VARCHAR.
Inoltre, sia i clienti che i fornitori sono raggruppati in un'unica tabella e questa tabella ha due chiavi primarie, una di tipo Int e una di tipo Varchar.

Ho due domande:

La prima: come riuscire a creare una tabella con due chiavi primarie. Ci ho provato, ma se attivo la seconda, SQL mi disattiva la prima e vicevera.
La seconda: come far funzionare le relazioni con una chiave primaria di tipo Varchar.
Allegati:
20104_aca30e12ab897ec215c27e7617fe2c00.png
20104_aca30e12ab897ec215c27e7617fe2c00.png

20104_84525af68331cca9d806a6de566f5ccc.png
20104_84525af68331cca9d806a6de566f5ccc.png

12 Risposte

  • Re: Chiave primaria non INT

    Fabriziog ha scritto:


    La prima: come riuscire a creare una tabella con due chiavi primarie.
    Ci ho provato, ma se attivo la seconda, SQL mi disattiva la prima e vicevera.
    La tabella NON può avere più di una chiave primaria.
    Semplicemente, la chiave primaria è unica, ma si basa sulla combinazione del valore di due campi invece di uno solo.

    Fabriziog ha scritto:


    La seconda: come far funzionare le relazioni con una chiave primaria di tipo Varchar.
    Funzionano come qualsiasi altra relazione tra chiavi: quando il valore è lo stesso, i record sono correlati.
    Se la chiave è formata da più campi, i record correlati sono quelli che presentano gli stessi valori per i campi configurati nella chiave.

    Sebbene l'uso di un valore intero sia in generale più performante, nulla vieta di creare chiavi con valori di tipo diverso, o combinazioni delle stesse.

    Ciao!
  • Re: Chiave primaria non INT

    Alka ha scritto:


    La tabella NON può avere più di una chiave primaria.
    Questo lo sapevo, ma non riuscivo a capire come in Zucchetti avessero fatto.

    Alka ha scritto:


    Semplicemente, la chiave primaria è unica, ma si basa sulla combinazione del valore di due campi invece di uno solo.
    Ho trovato come, tramite script.
    Ho guardato nelle proprietà, si può fare anche da lì?

    Alka ha scritto:


    Funzionano come qualsiasi altra relazione tra chiavi: quando il valore è lo stesso, i record sono correlati.
    Se la chiave è formata da più campi, i record correlati sono quelli che presentano gli stessi valori per i campi configurati nella chiave.

    Sebbene l'uso di un valore intero sia in generale più performante, nulla vieta di creare chiavi con valori di tipo diverso, o combinazioni delle stesse.

    Ciao!
    Quindi posso fare un database così:

    Customer
    CustomerCode(varchar 10) PK
    CustomerName
    ...

    E una tabella:

    Purchases
    PurchaseID
    Date
    CustomerCode(varchar 10) FK
    ...

    E funziona lo stesso? Lo chiedo perché ho sempre usato l'incremento automatico.
  • Re: Chiave primaria non INT

    Fabriziog ha scritto:


    Questo lo sapevo, ma non riuscivo a capire come in Zucchetti avessero fatto.
    E infatti, nemmeno loro lo hanno fatto.
    L'icona sta solo indicando i campi che fanno parte della chiave, che è sempre una.

    Fabriziog ha scritto:


    Ho trovato come, tramite script.
    Ho guardato nelle proprietà, si può fare anche da lì?
    Non so di che "proprietà" parli.
    In generale, le chiavi si definiscono tramite statement DDL, oppure se il programma di amministrazione DB in uso lo consente, usando una interfaccia utente.

    Fabriziog ha scritto:


    Quindi posso fare un database così:
    [...]
    E funziona lo stesso? Lo chiedo perché ho sempre usato l'incremento automatico.
    Certo che funziona. Solo le ricerche saranno più lente, perché il confronto tra valori numerici interi è più veloce di una stringa di 10 caratteri.
    Inoltre, se quel campo può essere modificato, il database dovrà gestire la propagazione dei valori aggiornati ai record correlati.

    Uso anche io l'incremento automatico, o addirittura dei GUID, perché dal mio punto di vista la chiave primaria non deve mai avere necessariamente un significato tangibile per il contenuto della tabella: è un ID univoco e come tale deve funzionare, senza che debba essere necessariamente progressivo (tipo un contatore), coprire dei "buchi" o avere un significato particolare, e meno ne ha meglio è.

    Il fatto poi che si possa assegnare a un record e non modificare, aggiunge ulteriori garanzie, ad esempio solleva il DB o lo sviluppatore dal fatto di dover propagare eventuali modifiche al valore del campo.

    Ciao!
  • Re: Chiave primaria non INT

    Salve,
    Ho guardato nelle proprietà, si può fare anche da lì?
    si, si puo' fare anche da SSMS... nel design della tabella "clicki" su tutte le colonne a te interessanti...
    personalmente, come @Alka, anche io preferisco scrivere il ddl di generazione sempre a mano e salvare gli script CREATE/ALTER nei repository che poi serviranno per la pubblicazione dei db...

    poi il grande @Alka getta un sasso in piccionaia, riaprendo il sempre aperto confronto circa le chiavi naturali e le chiavi surrogate, e non sempre sono d'accordo sulle chiavi surrogate
    https://www.mssqltips.com/sqlservertip/5431/surrogate-key-vs-natural-key-differences-and-when-to-use-in-sql-server/
    .

    anche io utilizzo spesso dei guid generati in autonomia dal dbms, ma al pari di altra chiave di "grossa dimensione", naturale o surrogata che sia, in questi casi sussiste una problematica appunto di dimensione, in questo caso l'occupazione in memoria e' di 16 bytes contro ad esempio i 4 bytes di un integer, dimensione che verra' riproposta in tutti gli oggetti referenzianti la chiave in argomento, quindi il "dispendio" potrebbe essere oneroso, ma ovviamente stiamo parlando di tabelle "importanti"

    interessante lettura puo' riscontrarsi in un vecchio articolo presso https://docs.microsoft.com/en-US/archive/blogs/sqlserverfaq/guid-vs-int-debate

    my € 0.02
    salutoni
    --
    Andrea
  • Re: Chiave primaria non INT

    Sul secondo punto: perché, quando non ci sono problemi di prestazione (cioè quasi sempre), non usare autoincrementi?
    Vari motivi. Il principale è fusione e divisione di tabelle, backup e ripristino.
    è comune ad esempio fondere gli archivi di due aziende, o dividerli.
    facile con chiavi 'parlanti', molto meno con incrementi o uuid.
    Dunque sconsiglio questi ultimi.

    lato prestazioni potrei fare lo spiegone per mysql, non per sql server, non lo uso praticamente mai
  • Re: Chiave primaria non INT

    +m2+ ha scritto:


    perché, quando non ci sono problemi di prestazione (cioè quasi sempre), non usare autoincrementi?
    La questione delle prestazioni è solo uno degli aspetti da tenere in considerazione. Tralasciando il fatto che il degrado delle prestazioni dipende non solo dalla chiave scelta ma anche delle interrogazioni che si fanno, dalla bontà degli indici e anche dalla quantità dei dati presenti in tabella, vi possono essere anche altre ripercussioni: come scritto in un altro messaggio, la necessità di mantenere aggiornati indici più complessi, il fatto di prevedere un possibile aggiornamento del valore chiave che si deve propagare sulle altre tabelle, la complessità maggiore che in genere assumono le query SQL (soprattutto se la chiave è suddivisa in più campi), l'impossibilità di prevedere che magari un domani quella "chiave parlante" possa aumentare di lunghezza e sforare quella massima consentita dall'indice, ecc.

    Con questo non dico che le "chiavi parlanti" non vadano utilizzate, anzi quoto per questo quello che è stato riportato da asql.

    Dico che - come nella maggior parte dei casi - non c'è un vincitore assoluto poiché la scelta va ponderata tenendo conto di diversi aspetti e di scenari che possono far pendere l'ago da una parte o dall'altra, a seconda di quello che si vuole privilegiare.

    +m2+ ha scritto:


    è comune ad esempio fondere gli archivi di due aziende, o dividerli.
    facile con chiavi 'parlanti', molto meno con incrementi o uuid.
    Con gli incrementi, è vero che ci sono alcuni accorgimenti da prendere, come disabilitare l'autoincremento e forzare l'inserimento del valore numerico; qualche mal di pancia tuttavia può esserci. In ogni caso, si può sempre fare uso di una chiave aggiuntiva "parlante" per identificare o meno la presenza di un record e per riferirsi a esso, ignorando il valore dell'ID all'occorrenza e usandolo solo per le correlazioni.

    Usando invece dei GUID, problemi non ce ne sono affatto, tant'è che vengono scelti appositamente per questo scopo, e per la possibilità di poterli generare anche lato client e trasferire grossomodo ovunque.

    Ciao!
  • Re: Chiave primaria non INT

    Alka ha scritto:


    La questione delle prestazioni è solo uno degli aspetti da tenere in considerazione...
    L'ho già scritto
    Tralasciando il fatto che il degrado delle prestazioni dipende non solo dalla chiave scelta ma anche (...)
    ... dall'esperienza di chi fa il progetto...
    [quot]
    Con gli incrementi, è vero che ci sono alcuni accorgimenti da prendere(...)[/quote]Diciamo che in certi casi (spesso la maggior parte addirittura) è proprio impossibile, altro che mal di pancia, se non scrivendo veri e propri programmi di importazione-esportazione.
    In ogni caso, si può sempre fare uso di una chiave aggiuntiva "parlante" per identificare o meno la presenza di un record e per riferirsi a esso, ignorando il valore dell'ID all'occorrenza e usandolo solo per le correlazioni.
    Complessità del tutto inutile
    Usando invece dei GUID, problemi non ce ne sono affatto, tant'è che vengono scelti appositamente per questo scopo, e per la possibilità di poterli generare anche lato client e trasferire grossomodo ovunque.
    Mah, in realtà no, non è che vengano scelti per questi motivi.
    Comunque nulla vieta, ed è generalmente la strategia che prediligo, di usare chiavi UUID "parlanti" semplicemente giustapposti, da mantenere i più semplici possibili, AZIE1qualcosa ad esempio, piuttosto che TD04qualcosa e così via
  • Re: Chiave primaria non INT

    +m2+ ha scritto:


    ... dall'esperienza di chi fa il progetto...
    No, l'esperienza di chi fa il progetto non c'entra nulla.
    Vi sono entità da rappresentare in determinati contesti dove non è possibile ricavare sempre una chiave parlante, altri dove invece la chiave può non essere ottimale o diventare troppo lunga, altri ancora dove - volendo proprio forzarne l'uso - allora è necessario prevedere un codice univoco, tipo un protocollo, che qualcuno deve prodigarsi a inserire, che sia lo sviluppatore o l'utente/amministratore, ed è comunque un "effort".
    Diciamo che in certi casi (spesso la maggior parte addirittura) è proprio impossibile, altro che mal di pancia, se non scrivendo veri e propri programmi di importazione-esportazione.
    Diciamo che facendo questa operatività quasi tutti i giorni, sicuramente non è impossibile.

    Essendo poi che, tranne un paio di volte in trent'anni non ho mai avuto bisogno di scrivere software di import/export particolari, escluderei anche che si tratti della maggior parte: è sufficiente usare ciò che mette a disposizione il database di riferimento, o in certi casi gli stessi tool di amministrazione dei DB e anche i linguaggi, e nell'Anno Domini 2020 tutti questi strumenti sono *perfettamente* in grado di svolgere tali compiti in totale autonomia e con poco sforzo, se si usano correttamente (e si sanno usare), con caratteristiche anche molto avanzate e disponibili "out of the box", come si suol dire.
    In ogni caso, si può sempre fare uso di una chiave aggiuntiva "parlante" per identificare o meno la presenza di un record e per riferirsi a esso, ignorando il valore dell'ID all'occorrenza e usandolo solo per le correlazioni.
    Complessità del tutto inutile
    "Complessità del tutto inutile" un paio di ciufoli, visto che si tratta banalmente di una chiave, niente di trascendentale.
    E tutto dipende come sempre dallo scenario e dai dati che si deve manipolare: assolutismi in campo informatico sono generalmente rari se non unici.

    Ben più di una volta può accadere che la correlazione tramite una chiave autogenerata e numerica al posto di una chiave "parlante" velocizzasse drasticamente le operazioni di interrogazione delle tabella correlate in presenza di molti dati, questo durante l'uso regolare del software da parte degli utenti, nonostante la presenza della chiave "parlante" tornasse comunque utile nelle fasi di manutenzione dove, eseguendo operazioni massive, ci si può attendere tempi leggermente più lunghi.

    La presenza dell'una non esclude l'altra, e l'uso dell'una può essere preferibile all'altra, e viceversa, a seconda dell'obiettivo da raggiungere, dei dati che vengono manipolati, dei requisiti in termini di tempistiche di esecuzione a seconda dello scenario, da cui non si può prescindere.
    Mah, in realtà no, non è che vengano scelti per questi motivi.
    Ok, allora se oltre alla loro universalità, trasferibilità e generabilità lato client, conosci altri motivi per cui usare un GUID, fammi sapere che magari imparo qualcosa di nuovo, perché io personalmente non ne conosco altri.
    Comunque nulla vieta, ed è generalmente la strategia che prediligo, di usare chiavi UUID "parlanti" semplicemente giustapposti, da mantenere i più semplici possibili, AZIE1qualcosa ad esempio, piuttosto che TD04qualcosa e così via
    Nulla lo vieta, così come nulla vita che questi identificativi vengano generati automaticamente lato DB, poiché a seconda della realtà che si va a modellare non sempre è possibile produrre un "codice/protocollo" per qualsiasi record si vada a inserire, che lo faccia lo sviluppatore o l'utente, e comunque produrlo è uno sforzo, e non vedo perché dovrei lambiccarmi per inserirlo quando il DB mi offre questa opportunità.
    Se serve ed è utile, lo faccio, altrimenti lascio perdere.

    In caso contrario, verrebbe da chiedere perché qualsiasi database, nessuno escluso, anche il più "scrauso" offre il supporto a contatori, identity, generatori di GUID (anche sequenziali) e tipi di dati analoghi se non esistesse alcun scenario in cui torna utile farne uso: questi ingegneri software devono essere impazziti a voler continuare a usare, supportare e ampliare questi strumenti quando una "chiave parlante" è più che sufficiente, ed è apparentemente ottima per tutte le stagioni senza distinzioni. Mmm...
  • Re: Chiave primaria non INT

    Gli spiegoni non sono ben visti su questo forum.
    Non sono minimamente d'accordo su praticamente tutto quanto scritto qui sopra ma,fortunatamente, non è mio compito (qui) insegnare.
    Chiaramente tutto va scalato sulla complessità dei progetti cui si lavora.
    Un conto è il db del salumiere sotto casa, un altro di una multinazionale di decine di miliardi di ricavi.

    Dunque tenga pure le sue opinioni,io terrò le mie
  • Re: Chiave primaria non INT

    Ps gli ingegneri del software li destino a lavarmi le auto, dopo aver ben spiegato la procedura ed opportuna supervisione.
    È l'impegno in cui possono dare il massimo delle competenze informariche
    E su, si faccia una risata
  • Re: Chiave primaria non INT

    +m2+ ha scritto:


    Gli spiegoni non sono ben visti su questo forum.
    Non mi pare di aver letto la clausola, quindi (senza volermene troppo) penso che in futuro continuerò come ho sempre fatto a scrivere messaggi della lunghezza che pare a me, thanks.

    +m2+ ha scritto:


    Chiaramente tutto va scalato sulla complessità dei progetti cui si lavora.
    Un conto è il db del salumiere sotto casa, un altro di una multinazionale di decine di miliardi di ricavi.
    Era quello che volevo sottolineare, proprio perché il discorso era molto "tranchant" e tra le due estremizzazioni dal salumiere alla multinazionale c'è una pletora di "vie di mezzo".

    +m2+ ha scritto:


    Dunque tenga pure le sue opinioni,io terrò le mie
    Nessuno è tenuto a cambiare opinione. Si stava solo parlando.

    +m2+ ha scritto:


    Ps gli ingegneri del software li destino a lavarmi le auto, dopo aver ben spiegato la procedura ed opportuna supervisione.
    È l'impegno in cui possono dare il massimo delle competenze informariche
    E su, si faccia una risata
    Non sono un ingegnere software però ne ho conosciuti diversi, bravi e meno bravi come qualsiasi altra categoria di professionisti che merita rispetto. Non vedo quindi cosa ci sarebbe da ridere in questa affermazione che, oltre a essere denigrante in modo generico verso una categoria, fa trasparire solo la poca umiltà di chi la dice. Ma è ovviamente solo una mia opinione.

    Fine dell'OT.
  • Re: Chiave primaria non INT

    Sugli spiegoni c'è l'apposito utente che provvederà ad illuminarla.
    Sugli ingegneri del software ne ho conosciuti tanti, ma nessuno cui farei far lavori più complessi dell'auto lavaggio.
    Anche perché non esiste l'ingegneria del software,ma l'arte di programmare i computer (cit)
Devi accedere o registrarti per scrivere nel forum
12 risposte