PK in tabella e indice multicampo

di il
24 risposte

PK in tabella e indice multicampo

Buongiorno,
sono a chiedere un consiglio su come strutturare una serie di tabelle di un database BE-FE. Ho quattro tabelle: TblOfferte, TblOrdini, TblDDT e TblFatture ognuna con ID... come PK. Vorrei aggiungere un indice multicampo in ognuna per impedire l'inserimento di record doppi (costituito da IDFornitore (FK), Data e numero documento), ma chiedo se non e' piu' corretto effettuare invece un controllo sul FE in fase di inserimento dalle forms. So che di solito gli indici appesantiscono il funzionamento dei database per cui chiedo a voi un parere. Grazie

24 Risposte

  • Re: PK in tabella e indice multicampo

    Mailman ha scritto:


    Vorrei aggiungere un indice multicampo in ognuna per impedire l'inserimento di record doppi (costituito da IDFornitore (FK), Data e numero documento), ma chiedo se non e' piu' corretto effettuare invece un controllo sul FE in fase di inserimento dalle forms. So che di solito gli indici appesantiscono il funzionamento dei database per cui chiedo a voi un parere. Grazie
    Non c'è il metodo più corretto : è un bilanciamento di prestazioni.
    Controllo su FE : risparmi spazio perché non hai l'indice, in caso di crash dell'applicativo rischi di avere incongruenza nei dati. In caso di accesso diretto al DB (per attività di manutenzione/correzione di errori) puoi tranquillamente creare incongruenza nei dati.
    Controllo da BE : aumenti lo spazio su disco (ma di quanto stiamo parlando? penso ben poca cosa) ma hai la certezza che i dati sono congruenti con regole previste.

    Aggiungi pure l'indice univoco multicampo e lascia che sia il motore del DB a gestire (per te) l'integrità dei dati.
  • Re: PK in tabella e indice multicampo

    (vedo che il max.occhialiscuri.riservo ha postato, nel frattempo, dicendo in poche righe quello che io ho diluito in un fiume di caratteri; lascio il post per la presenza dei link ai video di approfondimento)

    Mailman ha scritto:


    ...Vorrei aggiungere un indice multicampo in ognuna per impedire l'inserimento di record doppi (costituito da IDFornitore (FK), Data e numero documento).. So che di solito gli indici appesantiscono il funzionamento dei database ...
    Gli indici rallentano le fasi di inserimento/aggiornamento. Se usati nel modo giusto (perché le cose si possono usare anche in modo non giusto? meglio non usarle allora) sono fondamentali nelle ricerche perché riducono in modo incredibile i tempi di ricerca (nella generalità dei casi). Se oltre all'uso di trucco "duplicati non ammessi" quell'indice sarà anche cruciale nelle query allora vai tranquillo, anzi devi crearlo.
    Sull'uso degli indici ho trovato utili due video di Philipp Stiefel di codekabinett.com


    Nel secondo tra le altre cose viene trattata una particolarità dell'indice multicampo: quando funziona e quando no.
    Lo showplan è uno degli strumenti di Access che ha un rapporto tra importanza e consapevolezza della sua esistenza elevatissimo. Lo dico perché si fatica a trovarne le caratteristiche di funzionamento ma è veramente utilissimo per rendere le query funzionali. Parlo per esperienza personale: ho visto riduzione dei tempi di esecuzione delle query anche del 90% (quello che prima necessitava di 10 secondi poi ne impiegava 1)
  • Re: PK in tabella e indice multicampo

    Philcattivocarattere ha scritto:


    vedo che il max.occhialiscuri.riservo ...
    Ciao Phil,
    proprio non ti gustano i miei (sovra)occhiali da saldatore
    Magari la prossima volta che ho voglia di aggiornare l'avatar mi metto la maschera (da sub)
  • Re: PK in tabella e indice multicampo

    Per me sono molto "fashion", e poi direi che visto il periodo, sono di gran moda...
  • Re: PK in tabella e indice multicampo

    Ringrazio per i consigli preziosi, procedo con l'indice multicampo.
  • Re: PK in tabella e indice multicampo

    Scusa ma io ho alcune perplessità sulla cosa...!

    Stiamo parlando di: TblOfferte, TblOrdini, TblDDT e TblFatture

    TblDDT e TblFatture, direi che basta usare il N° DDT e n°Fattura, sono documenti già emessi, che hanno un NUMERO UNIVOCO identificativo già di suo... perchè invece di usare una PK Counter non hai usato una PK dedicata...?

    E' come mettere una PK Counter nell'anagrafica Clienti... e poi dover controllare se già esiste sfruttando la PIVA o il CF... non ti sembra una cosa assurda...?
    Si mette a PK la PIVA o il CF...!

    Sulle Offerte e gli Ordini... potrebbe valere la mesesima logica, ma dipende OPERATIVAMENTE da come inserisci le Offerte e gli Ordini..., e quì potrebbe anche essere che il controllo Multicampo non sia sufficiente... quando l'Ordine diventa operativo... c'è solo 1 operatore che formalizza gli Ordini...?

    In linea di principio i suggerimenti dati da MAX, sono coerenti anche per me, tuttavia io realizzerei una VALIDAZIONE CLIENT-SIDE, diventa estremamente più gestibile un controllo preventivo rispetto ad un controllo su Errore.

    Evidenzio però che gli INDICI assolvono a questo ruolo SOLO SE, identificati come "NON CONSENTONO DUPLICATI", tutt'altra cosa è la questione delle performance, ovviamente correttamente evidenziata da Phil... che però non mi pare sia attinente nello specifico con la questione di DUPLICAZIONE.
  • Re: PK in tabella e indice multicampo

    Ciao Alex,
    i documenti non si riferiscono a quelli emessi ma a quelli che riceviamo dai vari fornitori, per cui potrebbero avere numerazioni uguali.
  • Re: PK in tabella e indice multicampo

    È OT ma per rispondere a questa

    @Alex ha scritto:


    ...
    E' come mettere una PK Counter nell'anagrafica Clienti... e poi dover controllare se già esiste sfruttando la PIVA o il CF... non ti sembra una cosa assurda...?
    Si mette a PK la PIVA o il CF...!
    ...
    fino ad un pò di tempo fa la pensavo come te Alex su questo specifico argomento ma poi un paio d'anni fa ho dovuto rimettere mano al mio gestionale di fatturazione in uso presso un paio di centri medici nella mia zona perchè esistono clienti (delle Aziende) che non hanno PIVA (es: casse edili, istituti, ...) ma anche altre che non hanno CF (sembra strano ma esistono casistiche) senza considerare che avendo una tabella anagrafica unica per clienti Aziende e clienti Persone Fisiche che per definizione la P.IVA non ce l'hanno. Ok, mi dirai "allora metti il CF come PK mettendo codici fittizi per le aziende senza CF" ... certo si può fare ma esistono clienti che sono persone fisiche ma che sono anche Aziende Unipersonali (es: i "padroncini", camionisti proprietari) che quindi avrebbero 2 anagrafiche, una come persona fisica con CF e senza PIVA e l'altra come azienda unipersonale con PIVA e CF corrispondenti al CF della persona fisica... insomma esistono casistiche particolari per cui non è così lineare la cosa.
    Io ho preferito avere un ID_CLIENTE, e gestendo da codice i controlli aggiungendo però anche indici univoci per CF e Tipo_anag (A=Azienda, P=Persona) condizionate (su SQL-Server si può fare) per avere ancora + certezza.
  • Re: PK in tabella e indice multicampo

    muttley005 ha scritto:


    ... ma anche altre che non hanno CF (sembra strano ma esistono casistiche) ...
    Questa per me è nuova ed aggiungerei "impossibile", siccome però so che non sei uno che scrive a caso chiedo lumi perché sarebbe veramente una situazione a me totalmente sconosciuta.
    Un'entità, un soggetto, chiamiamolo come vogliamo, per avere rilevanza io l'ho sempre considerato come [soggetto in possesso di codice fiscale], altrimenti è un "nulla", se non tipo un gruppetto di amici che... si mettono insieme per suonare i campanelli e scappare, senza costituire l' "Associazione disturbatori a tempo perso" con attribuzione allora di codice fiscale.
  • Re: PK in tabella e indice multicampo

    Capito, in questo caso pensavi di controllare PIVA+DATA+NDOC...
    Io non realizzerei l'INDICE MultiCampo, definirei come INDICI i singoli campi, ma farei un controllo su BeforeInsert sfruttando la tranzazione ad esso correlata, forzi il CANCEL=TRUE se il DCOUNT(.....,"3 CRITERI")>0
  • Re: PK in tabella e indice multicampo

    Grazie Alex,
    la parte FE e' ancora tutta da progettare per cui ho tempo per implementare. Sarebbe interessante pero' sapere la tua posizione riguardo a quanto indicato nello specifico da Max sul rischio di crash dell'applicativo o eventuale accesso al DB BE con possibile corruzione dei dati:

    max.riservo ha scritto:


    Controllo su FE : risparmi spazio perché non hai l'indice, in caso di crash dell'applicativo rischi di avere incongruenza nei dati. In caso di accesso diretto al DB (per attività di manutenzione/correzione di errori) puoi tranquillamente creare incongruenza nei dati.
    Controllo da BE : aumenti lo spazio su disco (ma di quanto stiamo parlando? penso ben poca cosa) ma hai la certezza che i dati sono congruenti con regole previste.
    Mi piacerebbe avere entrambi i metodi, ma sarebbe troppo ridondante secondo voi?
  • Re: PK in tabella e indice multicampo

    Sono 2 esigenze da non confondere, oltretutto io eviterei la ridondanza... è sempre un pericolo nella gestione.

    Le considerazioni di MAX, sono giuste in particolare se si usa un RDBMS su cui spesso si sviluppano delle SP per velocizzare inserimenti o elaborazioni più complesse.
    Se come BE usi Access(JET)... sinceramente farei ragionamenti differenti.

    In ogni caso la questione "MANUTENZIONE" è da capire di cosa si parla in modo più completo, ma soprattutto come ognuno nell'organizzazione del lavoro ha deciso di strutturarla.

    Se il tuo prodotto lo hai VENDUTO ad un cliente... immagino non sia normale che il cliente acceda al SERVER da interfaccia del RDBMS... se invece tu sei chi sviluppa e chi fa manutenzione... la cosa cambia.

    Come ti ha detto Max non c'è una soluzione giusta ed una sbagliata, ma una serie di considerazioni che ti consentono di scegliere la cosa migliore per te.
  • Re: PK in tabella e indice multicampo

    muttley005 ha scritto:


    ...

    fino ad un pò di tempo fa la pensavo come te Alex su questo specifico argomento ma poi un paio d'anni fa ho dovuto rimettere mano al mio gestionale di fatturazione in uso presso un paio di centri medici nella mia zona perchè esistono clienti (delle Aziende) che non hanno PIVA (es: casse edili, istituti, ...) ma anche altre che non hanno CF (sembra strano ma esistono casistiche) senza considerare che avendo una tabella anagrafica unica per clienti Aziende e clienti Persone Fisiche che per definizione la P.IVA non ce l'hanno. Ok, mi dirai "allora metti il CF come PK mettendo codici fittizi per le aziende senza CF" ... certo si può fare ma esistono clienti che sono persone fisiche ma che sono anche Aziende Unipersonali (es: i "padroncini", camionisti proprietari) che quindi avrebbero 2 anagrafiche, una come persona fisica con CF e senza PIVA e l'altra come azienda unipersonale con PIVA e CF corrispondenti al CF della persona fisica... insomma esistono casistiche particolari per cui non è così lineare la cosa.
    Io ho preferito avere un ID_CLIENTE, e gestendo da codice i controlli aggiungendo però anche indici univoci per CF e Tipo_anag (A=Azienda, P=Persona) condizionate (su SQL-Server si può fare) per avere ancora + certezza.
    Qualsiasi figura FISICA(il singolo) o GIURIDICA(Azienda, padroncino o altro) hanno perforza un elemento identificativo che è o CF o PIVA... io fatico a pensare altrimenti, mi piacerebbe capire l'ADE come fa ad identificarli altrimenti.
    Persino le associazioni di volontariato, che in specifici regimi non sono obbligate ad avere PIVA, hanno l'obbligo del CF.

    Ovviamente il 3D nasce da soggetti che emettono Fattura...!
    Se ci sono casistiche aggiuntive, mi sono sconosciute, e forse lo sono anche al fisco...

    Che poi un Padroncino possa avere sia PIVA che CF ovviamente è vero... ma li dipende da te che sviluppi e fai il Censimento Anagrafico a gestire la cosa.
    Spesso trovo il campo PIVA/CF perchè io sfido a trovare un duplicato tra un CF ed una PIVA... ma se mi dici che anche in questo ci sono possibilità...

    Se poi parli di gestione documentale INTERNA tra uffici pubblici o enti appartenenti alla PA... beh... non stiamo parlando della stessa cosa.
  • Re: PK in tabella e indice multicampo

    @alex @phil

    sul "esistono Aziende che non hanno PIVA" c'è ad esempio una "Fondazione Casa di ..." (non specifico per privacy anche se in realtà non credo sarebbe un'infrazione) che ha un CF simil partita iva ma non ha la Piva (verificato).

    sul "ma anche altre che non hanno CF" ad esempio ci sono svariate aziende estere in questo stato ed anche provando a "stalkerarne" un paio online non trovo alcun riferimento ad un qualcosa di simile ad un CF.

    premesse queste 2 cose ... Sì esiste sempre uno dei 2 (CF / PIVA) per cui riconoscere una "entità" univocamente, questo è chiaro ed infatti io avevo scritto "esistono clienti (delle Aziende) che non hanno PIVA (es: casse edili, istituti, ...) ma anche altre che non hanno CF" , non ho scritto CONTEMPORANEAMENTE.
    Tornando quindi a quanto suggerito da Alex, ci sta di voler impostare una PK su uno dei due campi e non su un ID progressivo ma avendo casi in cui o non ho il CF o non ho la PIVA ho preso la + comoda strada di avere un ID_CLIENTE.
    Sicuramente avrei potuto impostare una PK che fosse ad esempio =nz(PIVA,CF) e non viceversa =NZ(CF,PIVA) perchè altrimenti avrei avuto il problema delle aziende unipersonali che si sarebbero sovrapposte alle stesse persone fisiche ma ho preferito appunto avere un ID_CLIENTE.
Devi accedere o registrarti per scrivere nel forum
24 risposte