Database per manutenzioni

di il
36 risposte

36 Risposte - Pagina 2

  • Re: Database per manutenzioni

    cridema ha scritto:


    Non ho capito la tabella contatti
    Ho abbondato di mano mia. Se hai una tabella Clienti, vorrai come minimo tenere una specie di Rubrica per contattarli (telefono, cellulare, e-mail). Qui sorge un piccolo problema generazionale per il quale io sostengo la relazione Persone (o Clienti) uno-a-molti Contatti. Quando non esisteva tanta tecnologia come oggi, per contattare una persona bastava conoscere l'Indirizzo, il telefono e basta. Poi è arrivato il cellulare, poi c'è chi ha 2 cellulari, poi e-mail, poi Skype....ce chi ha solo un paio di questi TipoContatto, chi ne ha veramente molti. Di fronte a questo scenario di valori, io non me la sento di avere troppi campi direttamente dentro la tabella Clienti, ma preferisco relazionare il quel modo. In TipoContatto ci scrivi parole come telefono, cellulare, e-mail, www, Skype..., dentro Contatto ci scrivi il numero vero e proprio o l'e-mail vera e propria...

    cridema ha scritto:


    Mi pare di capire che la tabella impianti sia unica: se faccio un report complessivo riesco a filtrare gli eventuali campi vuoti?
    Per gestire questa cosa, mi viene un'idea mentre scrivo: se mantengo una tabella unica da far lavorare con le altre tabelle principali e creo N sottobelle collegate per la sola registrazione dei componenti di cui abbiamo parlato?
    Non ti capisco. Impara (per quanto possibile) a non far dipanare troppe linee di join (relazione) da uno stesso campo chiave primaria. Io quando ne vedo più di 2 comincio a preoccuparmi.
    Se hai intenzione di includere i Componenti, dobbiamo ragionare ulteriormente.
    Un primo approccio lascia intuire che un Impianto ---> molti Componenti: OK.
    Però, proprio perchè tu mi hai citato nei tuoi esempi QGBT, QEP1, QEP2, questo mi fa pensare che, dentro ognuno di essi, togliendo le caratteristiche proprie che li differenziano, ma niente niente ci trovi anche Componenti comuni. Correggimi se sbaglio. Io intanto vado avanti a ruota libera.
    Di conseguenza, secondo me, anche un Componente può stare in molti Impianti. Questo lascia intendere che la relazione fra Impianti e Componenti è molti-a-molti e va esplicitata con una tabella di congiunzione ComponentiImpianti con i seguenti campi:
    IDComponenteImpianto (contatore, chiave primaria)
    IDImpianto (numerico)
    IDComponente (numerico)
    con conseguenti relazioni da aggiustare così:
    Impianti.IDImpianto uno-a-molti con ComponentiImpianti.IDImpianto
    Componenti.IDComponente uno-a-molti con ComponentiImpianti.IDComponente.
  • Re: Database per manutenzioni

    Ho abbondato di mano mia. Se hai una tabella Clienti, vorrai come minimo tenere una specie di Rubrica per contattarli (telefono, cellulare, e-mail). Qui sorge un piccolo problema generazionale per il quale io sostengo la relazione Persone (o Clienti) uno-a-molti Contatti. Quando non esisteva tanta tecnologia come oggi, per contattare una persona bastava conoscere l'Indirizzo, il telefono e basta. Poi è arrivato il cellulare, poi c'è chi ha 2 cellulari, poi e-mail, poi Skype....ce chi ha solo un paio di questi TipoContatto, chi ne ha veramente molti. Di fronte a questo scenario di valori, io non me la sento di avere troppi campi direttamente dentro la tabella Clienti, ma preferisco relazionare il quel modo. In TipoContatto ci scrivi parole come telefono, cellulare, e-mail, www, Skype..., dentro Contatto ci scrivi il numero vero e proprio o l'e-mail vera e propria...
    Non lo avevo pensato, ma è utilissimo!!!

    Per quanto riguarda i componenti, tra quello che ho pensato e quello che mi hai suggerito:

    host immagini

    Può funzionare??
  • Re: Database per manutenzioni

    No.
    Io ho capito che QBT è un IMPIANTO. Tanti QBT di varie Marche-Modelli devono andare dentro Impianti. Il fatto è che, non conoscendo i campi professionalmente utili, ho sintetizzato malamente con quei pochi. Sta a te rendere la tabella Impianti con i campi professionalmente giusti.
    Forse io confondo gravemente il concetto di Componente. Penso all'Impianto come un insieme di Componenti: Il telaio, il relè, l'interruttore, il monitor a led, il termostato, il circuito integratoX, il circuito integratoY...sto sparando termini tecnici che non mi competono...devi darmi tu una dritta al riguardo.
  • Re: Database per manutenzioni

    Allora QBT è l'abbrevazione di Quadro di Bassa Tensione (generico).
    Gli esempi che ti ho fatto nei post precedenti sono sottocategorie di QBT: QGBT è il Quadro Generale di Bassa Tensione, QEP1 è il quadro elettrico del piano primo, e così via.
    Nella tabella [Impianti] mi sono dimenticato di indicare il campo 'NomeImpianto' ma comunque la filosofia a capo di tutto sarebbbe questa:
    la tabella impianti mi contiene 3/4 campi che mi identificano l'impianto;
    le sottotabelle 'componenti' vengono personalizzate con i componenti tipici di ogni impianto. Ti assicuro che sarebbe controproducente avere una tabella unica per la raccolta dei componenti, soprattutto quando poi entri in tipologie diverse (Caldaie, Gruppi Firgoriferi, Gruppi elettrogeni, etc..); la costruzione delle maschere e dei report sarebbe un massacro!
    Mi aiuti a capire perché una struttura di questo tipo è sconsigliata?

    image share
  • Re: Database per manutenzioni

    Tu sottovaluti il potenziale di ogni record di ogni tabella. La tabella Impianti ha un campo Tipologia. Qui dentro DISCRIMINI (già a monte) che stai parlando di Caldaia, ImpiantoElettrico, GruppoElettrogeno...Immaginiamo che tu hai 10 record in Impianti:
    3 sono Caldaie
    2 QGBT
    4 QEP1
    1 GruppoElettrogeno
    Per distinguere le 3 Caldaie lo farai attraverso Marca e Modello. Idem per gli altri che hanno stessa Tipologia.
    Dopo di che, prendi il record1 (es. Caldaia Argo A-110) e (grazie a una sottotabella Componenti), descrivi i MOLTI Componenti associati a questo specifico modello di Caldaia.
    Idem per tutti gli OGNI altri record di Impianti.
    Ora io dicevo che, secondo me, il QGBT della marca Sharp, modello SH-1000 avrà (dentro di sè) 4 Componenti che potresti tranquillamente ritrovare nel QGBT della marca Sharp, modello SH-1200.
    Era qui che io vorrei mettere in relazione Impianti molti-a-molti con Componenti.

    È ovvio che non devi mettere tutti i campi Componenti in Impianti, proprio per non avere una visione ORIZZONTALE e distorta che la relazione uno-a-molti facilita e esplicita in direzione VERTICALE.
  • Re: Database per manutenzioni

    Osvaldo io ti chiedo scusa, ma o non capisco io (e ci sta.. ) ovvero stiamo dicendo la stessa cosa.
    La tabella 'impianti' avrà i campi che mi servono per definire le caratteristiche principali dell'impianto. Saranno comuni a tutte le tipologie. Fin qui siamo d'accordo.

    Quello che non riesco a capire è se prevedi un'unica tabella 'componenti' comune a tutte le tipologie quindi qui dentro ci andranno i componenti di tutto (caldaie, quadri elettrici, gruppi elettrogeni..) oppure se prevedi una tabella 'componenti' per ogni tipologia:
    ComponentiQuadriElettrici
    ComponentiCaldaie
    ComponentiGruppiElettrogeni
  • Re: Database per manutenzioni

    cridema ha scritto:


    un'unica tabella 'componenti' comune a tutte le tipologie quindi qui dentro ci andranno i componenti di tutto (caldaie, quadri elettrici, gruppi elettrogeni..)
    Esatto.
    Opportune query possono agevolarti futuri input per scegliere i Componenti "congrui" (grazie al campo Tipologia) alla Tipologia del Impianto.
    In pratica prevedi un campo Tipologia anche in tabella Componenti.
  • Re: Database per manutenzioni

    Ok, ora ho capito.
    Quindi ho capito anche la tabella di 'transito' per la relazione molti a molti.
    Con le query (devo provare) dovrei riuscire a gestire tutto, in effetti.
    Un unico dubbio.
    Supponi che oggi comincio ad utilizzare il mio DB con tutti gli impianti elettrici (Quadri, illuminazione, etc).
    La tabella 'Componenti' avrà N campi.
    Fra un mese comincio a far lavorare gli impianti termici (Caldaie, termosifoni, etc) e, di conseguenza, i campi della tabella 'componenti' aumentano: la cosa mi crea problemi?
    Esiste un limite al numero di campi di una tabella?

    Grazie e perdona se sono un po' duro di comprendonio!
  • Re: Database per manutenzioni

    cridema ha scritto:


    Esiste un limite al numero di campi di una tabella?
    Praticamente no. Non lo so, ma immaginiamo pure che Access preveda di porre un limite a 100 (sicuramente molto di più). Ma chi è disposto a gestire una tabella con così tanti campi?

    cridema ha scritto:


    Fra un mese comincio a far lavorare gli impianti termici (Caldaie, termosifoni, etc) e, di conseguenza, i campi della tabella 'componenti' aumentano: la cosa mi crea problemi?
    Mmhhh...questa frase mi preoccupa un po'. Non devi pensare di mettere i tuoi 10 campi più "caldaioli" da una parte, poi altri 25 campi più "elettrogeni" da un'altra, poi 8 campi più "frigoriferistici". Non devi avere una tabella sì fatta con quei 43 campi. Devi sempre coglierne le omogeneità dove sussistono. Altrimenti non c'è nessun problema a creare una nuova tabella DettagliComponenti dove verticalizzi tali valori.
    Purtroppo stiamo pure parlando in termini teorici. Io non conoscendo un po' di valori di componenti (es. portata), non riesco a spiegartelo praticamente.

    cridema ha scritto:


    Grazie e perdona se sono un po' duro di comprendonio
    Apprezzo almeno il tasso collaborativo che ci stai mettendo. Vai tranquillo...devi vedere io...
  • Re: Database per manutenzioni

    cridema ha scritto:


    Esiste un limite al numero di campi di una tabella?
    Ovviamente Sì, per Access sono 255.

    Vecchie versioni (200/2002/2003) Microsoft Access Specifications and Limits
    http://www.databasedev.co.uk/access_specifications.htm

    Specifiche di Access 2010
    https://support.office.microsoft.com/it-it/article/Specifiche-di-Access-2010-1e521481-7f9a-46f7-8ed9-ea9dff1fa854?CorrelationId=c91cec6c-c16f-4faa-9a79-df182c14dd17&ui=it-IT&rs=it-IT&ad=IT

    cridema ha scritto:


    Fra un mese comincio a far lavorare gli impianti termici (Caldaie, termosifoni, etc) e, di conseguenza, i campi della tabella 'componenti' aumentano: la cosa mi crea problemi?
    Se ti bastano i 255 campi non mi pare proprio il caso di suddividere i dati specifici in più tabelle.
    Ti complichi solo la vita, dato che comunque avrai sempre una relazione logica uno:uno.

    Tanto per fare un esempio, è diverso dalla relazione logica che c'è tra un Cliente ed i relativi impianti, che è ovviamente uno:molti

    Sarebbe come se dovendo gestire i Documenti (fatture, ddt, proforma, preventivi, ecc) si vada a creare una tabella per ogni TIPO di documento.
    Oltre che sbagliato è impensabile perché che fai se l'utente vuole crearsi un nuovo tipo di documento?
    Crei una nuova tabella? Capisci da te stesso che è assurdo.
  • Re: Database per manutenzioni

    cridema ha scritto:


    Fra un mese comincio a far lavorare gli impianti termici (Caldaie, termosifoni, etc) e, di conseguenza, i campi della tabella 'componenti' aumentano: la cosa mi crea problemi?

    gibra ha scritto:


    Se ti bastano i 255 campi non mi pare proprio il caso di suddividere i dati specifici in più tabelle.
    Ti complichi solo la vita, dato che comunque avrai sempre una relazione logica uno:uno.

    OsvaldoLaviosa ha scritto:


    Non devi pensare di mettere i tuoi 10 campi più "caldaioli" da una parte, poi altri 25 campi più "elettrogeni" da un'altra, poi 8 campi più "frigoriferistici". Non devi avere una tabella sì fatta con quei 43 campi.
    gibra, ma hai capito lui cosa vuole fare? Io ho capito che se deve inserire 100 Caldaie lui compilerà 10 campi. Deve inserire 70 GruppiElettrogeni e decide di aumentare la tabella di altri 25 per poter compilare (lasciando vuoti i primi 10). Deve inserire 30 Frigoriferi e decide di aumentare la tabelle di altri 8 campi e compila 30 record su questi ultimi campi lasciando i restanti 35 vuoti.
    Non trovi tutto ciò altamente assurdo?
    Se ho sbagliato l'interpretazione, cridema ce lo deve spiegare per bene.
  • Re: Database per manutenzioni

    gibra ha scritto:


    Se ti bastano i 255 campi non mi pare proprio il caso di suddividere i dati specifici in più tabelle.
    Ti complichi solo la vita, dato che comunque avrai sempre una relazione logica uno:uno.

    Tanto per fare un esempio, è diverso dalla relazione logica che c'è tra un Cliente ed i relativi impianti, che è ovviamente uno:molti

    Sarebbe come se dovendo gestire i Documenti (fatture, ddt, proforma, preventivi, ecc) si vada a creare una tabella per ogni TIPO di documento.
    Oltre che sbagliato è impensabile perché che fai se l'utente vuole crearsi un nuovo tipo di documento?
    Crei una nuova tabella? Capisci da te stesso che è assurdo.
    Grazie Gibra ho capito perfettamente.

    OsvaldoLaviosa ha scritto:


    gibra, ma hai capito lui cosa vuole fare? Io ho capito che se deve inserire 100 Caldaie lui compilerà 10 campi. Deve inserire 70 GruppiElettrogeni e decide di aumentare la tabella di altri 25 per poter compilare (lasciando vuoti i primi 10). Deve inserire 30 Frigoriferi e decide di aumentare la tabelle di altri 8 campi e compila 30 record su questi ultimi campi lasciando i restanti 35 vuoti.
    Non trovi tutto ciò altamente assurdo?
    Se ho sbagliato l'interpretazione, cridema ce lo deve spiegare per bene.
    Osvaldo hai capito perfettamente, ma mi avete convinto che è una c....ata pazzesca ( x 45 min).
    Quando integrerò i campi della tabella estarrò i dati in excel e poi li reinserirò per sicurezza.

    Per il momento vi ringrazio tantissimo, ora non mi resta che mettermi a rifare il DB...
  • Re: Database per manutenzioni

    OsvaldoLaviosa ha scritto:


    gibra, ma hai capito lui cosa vuole fare?
    Ho capito, vai tranquillo.
    10 anni fa iniziai lo sviluppo di un gestionale per le manutenzioni tecniche di impianti (caldaie, climatizzatori, termopompe, addolcitori, ecc.) con gestione e pianificazione degli interventi , scadenze, ricambi, sostituzioni, contratti di manutenzione, che include anche la gestione chiamiamola così fiscale cioè preventivi, ddt, fatture, sconti, magazzino, ordini fornitore, acquisti, ecc. con stampa dei Rapporti Tecnici di intervento obbligatori per legge ed ora (da ottobre 2014) regolamentati pure da una catasto.

    Quindi so molto bene di cosa parla, e ribadisco quello che ho affermato:
    meglio una sola tabella per tutti gli impianti, se può.
    I vantaggi si capiscono dopo, ovvero quando sarà necessario realizzare tutto il resto (interrogazioni, statistiche, reportistica, ecc.) e sarà molto più agevole.

    Inizialmente il cliente gestiva solo caldaie (quindi avevo solo una tabella), poi anno dopo anno ha aggiunto Clima, Acqua, e così via ed è stato a quel punto che mi sono trovato a dover scegliere l'unificazione degli impianti perché mi accorsi che man mano che diventava un bagno di sangue.

    Comunque... fate vobis.

    Ognuno dice la sua, io ho portato la mia esperienza pratica in questi 10 anni di sviluppo del gestionale.

    Sarà poi cridema a scegliere la strada che preferisce, però attenzione:
    bisogna rifletterci bene perché una volta intrapresa la strada, se ci si accorge di aver 'toppato' poi bisogna rifare tutto.
    Per cui suggerisco a cridema di documentarsi bene, prima di partire.

  • Re: Database per manutenzioni

    Rispondo a gibra.
    Ma non pensi che, piuttosto che AGGIUNGERE SOLTANTO quei campi di cui si sta dibattendo, ha più senso parlare di trovare una ridenominazione più generalizzante (almeno di alcuni) che possa accontentare più Tipologie? Mi sento menomato nel discorso perchè non conosco alcune parole specifiche del campo professionale in questione. Non vorrei andare fuori tema, ma faccio un esempio più vicino a me.
    Ho un database dove colleziono tutto insieme Libri, CD, LP, MC, VHS, DVD... Se per un Libro voglio indicare il NumeroPagine, per CD, LP, MC potrei indicare la Durata. Ma per entrambi potrei chiamare quel campo Grandezza o Dimensione. Così ho fatto e mi ci trovo bene.
    Sarà il campo Tipologia che ne darà l'esatta interpretazione più specifica/intrinseca al CampoX o CampoY...
  • Re: Database per manutenzioni

    gibra ha scritto:


    Ho capito, vai tranquillo.
    10 anni fa iniziai lo sviluppo di un gestionale per le manutenzioni tecniche di impianti (caldaie, climatizzatori, termopompe, addolcitori, ecc.) con gestione e pianificazione degli interventi , scadenze, ricambi, sostituzioni, contratti di manutenzione, che include anche la gestione chiamiamola così fiscale cioè preventivi, ddt, fatture, sconti, magazzino, ordini fornitore, acquisti, ecc. con stampa dei Rapporti Tecnici di intervento obbligatori per legge ed ora (da ottobre 2014) regolamentati pure da una catasto.
    Uh, somiglia parecchio a quello che voglio fare... c'hai messo pure il nuovo e infinito libretto d'impianto?

    gibra ha scritto:


    Sarà poi cridema a scegliere la strada che preferisce, però attenzione:
    bisogna rifletterci bene perché una volta intrapresa la strada, se ci si accorge di aver 'toppato' poi bisogna rifare tutto.
    Per cui suggerisco a cridema di documentarsi bene, prima di partire.
    Ho già scelto: tabella unica!

    OsvaldoLaviosa ha scritto:


    Rispondo a gibra.
    Ma non pensi che, piuttosto che AGGIUNGERE SOLTANTO quei campi di cui si sta dibattendo, ha più senso parlare di trovare una ridenominazione più generalizzante (almeno di alcuni) che possa accontentare più Tipologie? Mi sento menomato nel discorso perchè non conosco alcune parole specifiche del campo professionale in questione. Non vorrei andare fuori tema, ma faccio un esempio più vicino a me.
    Ho un database dove colleziono tutto insieme Libri, CD, LP, MC, VHS, DVD... Se per un Libro voglio indicare il NumeroPagine, per CD, LP, MC potrei indicare la Durata. Ma per entrambi potrei chiamare quel campo Grandezza o Dimensione. Così ho fatto e mi ci trovo bene.
    Sarà il campo Tipologia che ne darà l'esatta interpretazione più specifica/intrinseca al CampoX o CampoY...
    Sicuramente farò dei campi generici, suddivisi per tipologia (testo, numero, allegato...) poi vedrò man mano che costruisco il DB. Comunque l'idea è, almeno in parte, percorribile, tutto dipende molto da cosa voglio "censire" (ancora non ho trovato un sinonimo che mi aggrada..).

    Invece vi pongo un nuovo quesito: se volessi associare le operazioni (prima erano le attività manutentive) ad un Cliente come posso fare? Provo a spiegarmi meglio. Esiste la possibilità che un cliente, piuttosto che un immobile, mi richieda delle operazioni diverse da un altro sulla stessa tipologia di impianto. Per intenderci è un contratto tra fornitore e cliente quindi un cliente mi paga certe attività un altro no. Come potrei "personalizzare" le operazioni?
Devi accedere o registrarti per scrivere nel forum
36 risposte