Realizzare database centralizzato con dati diverse installazioni

di il
13 risposte

Realizzare database centralizzato con dati diverse installazioni

Ciao,

l'azienda dove lavoro produce e vende macchinari industriali. Questi vengono da noi affiancati da sistemi SCADA che vengono eseguiti da un computer che si trova a bordo della macchina e dialoga direttamente con i suoi componenti. Il sistema SCADA prevede un database e un'applicazione web ASP.NET Core e può essere acceduto da remoto tramite VPN.

Ora abbiamo intenzione di mettere in piedi presso la nostra sede un sistema che prelevi periodicamente i dati dai database dei vari clienti e li inserisca in un database che si trova presso la nostra sede, in modo tale da avere una copia di tutti i dati e poterci fare analisi etc. Per fare questo, la cosa più semplice mi sembra sia fare un database con la stessa identica struttura di quelli che si trovano presso i clienti.

Il mio problema è il seguente: l'applicazione web utilizza il sistema di autenticazione IdentityCore, che prevede l'oggetto IdentityUser che viene poi mappato sulla tabella AspNetUsers e così via. Nel momento in cui prelevo i dati degli utenti, dal momento che due o più utenti creati in installazioni separate potrebbero avere lo stesso Id (chiave primaria), occorre poterli distinguere per evitare errori quando vado ad inserirli nel database presso la nostra sede. Per fare questo avevo pensato di modificare o estendere l'oggetto IdentityUser aggiungendo l'attributo CompanyId, in modo tale che la chiave divenisse <Id, CompanyId>.

Tuttavia mi sembra che non sia possibile fare questa cosa: se estendo la classe IdentityUser nel seguente modo

[PrimaryKey(nameof(Id), nameof(CompanyId))]
public class User : IdentityUser
{
    public int CompanyId { get; set; }

    [ForeignKey(nameof(CompanyId))]
    public Company Company { get; set; }

    public User() : base() {
    }
}

quando vado a generare la migrazione ottengo il seguente errore

The derived type 'User' cannot have the [Key] attribute on property 'CompanyId' since primary keys may only be declared on the root type. Move the property 'CompanyId' to 'IdentityUser' or remove 'IdentityUser' from the model by using [NotMapped] attribute or calling 'EntityTypeBuilder.Ignore' on the base type in 'OnModelCreating'.

Quindi sembra non sia possibile procedere in questo modo. 

Avete idee su come potrei fare?

Grazie

13 Risposte

  • Re: Realizzare database centralizzato con dati diverse installazioni

    Fata la legge, trovato l'inganno. 

    così non va, ovviamente. 

    soluzione: Id lo lasci cosi' come e'

    MA a questo punto diventa un id univoco NON per un user soltanto MA per company/user.

    MA  non basta mi sa:

    ti serve una tabella di servizio che mappa gli id degli utenti delle varie company in id univoci sul TUO database. 

    Questo perché nella stessa company non ci possono essere gli stessi user_id MA tra company diverse assolutamente si

    Ma e' plausibile che questa idea debba essere replicata anche per altri oggetti che sono univoci all'interno della stessa company ma non necessariamente tra comoany diverse. 

    Boh! 

  • Re: Realizzare database centralizzato con dati diverse installazioni

    Ma e' plausibile che questa idea debba essere replicata anche per altri oggetti che sono univoci all'interno della stessa company ma non necessariamente tra comoany diverse. 

    Concordo, questo l'avevo già preventivato e si risolve in modo semplice: basta che esista una tabella “Company” e che io mi assicuri manualmente che l'id della company sia univoco fra tutti i database di tutti i clienti, e a quel punto non devo far altro che modificare alcune tabelle mettendo come chiave non più (ad esempio) <ProductionOrderId> ma <ProductionOrderId, CompanyId>. 

    ti serve una tabella di servizio che mappa gli id degli utenti delle varie company in id univoci sul TUO database. 

    Non so se è quello che intendi tu, ma pensavo che potrei fare una cosa del genere:
    Definisco una tabella User avente campi Id, CompanyId, AspNetUsersId . <Id, CompanyId> costituirebbe la chiave, e tramite essa viene riferita dalle altre tabelle.
    Il campo AspNetUsersId è chiave esterna verso la tabella AspNetUsers. Per evitare conflitti, quando vado a prelevare gli utenti dalla tabella AspNetUsers della compagnia avente CompanyId = 123 potrei aggiungere il prefisso 123 agli Id di tutti gli utenti, e similmente per il campo AspNetUsersId della tabella User.
    Il vantaggio è che in tal modo questa modifica dovrei farla solo per i record provenienti dalle tabelle AspNetUsers (+ AspNetUsersRoles etc) e User, mentre i record provenienti da tutte le altre tabelle in cui si fa riferimento ad un utente non andranno modificati.

    Grazie per l'aiuto :)

  • Re: Realizzare database centralizzato con dati diverse installazioni

    Ciao,

    hai provato a fare una soluzione basata sul costrutto TSQL merge?
    Merge queries overview - Power Query | Microsoft Learn

    Simo

  • Re: Realizzare database centralizzato con dati diverse installazioni

    Ciao, ti ringrazio per la risposta ma mi sembra un semplice JOIN, quindi non dovrebbe essermi utile per il problema che ho.

  • Re: Realizzare database centralizzato con dati diverse installazioni

    24/02/2023 - Alkasel ha scritto:


    Ciao, ti ringrazio per la risposta ma mi sembra un semplice JOIN, quindi non dovrebbe essermi utile per il problema che ho.

    MERGE Statement in SQL Explained - GeeksforGeeks

    Scusa avevo sbagliato il link.

    S:

  • Re: Realizzare database centralizzato con dati diverse installazioni

    Mhhh… ti ringrazio ma continuo a non capire come potrei applicare questo per risolvere il mio problema.

    Se hai letto, il mio problema è che avrò (non ho ancora) sparsi per il mondo diversi database, con relative tabelle ed identificatori. Finché questi database rimangono isolati va tutto bene: se all'interno della tabella X del database Y è usata la stessa chiave che nella tabella W del database Z non è un problema. Il problema sorge nel momento in cui ho bisogno di avere, in più, un database centralzzato con i dati provenienti da tutti questi database. Credo che in questo caso l'unica cosa che posso fare è modificare la struttura stessa del database in modo che i dati siano unvoci “across different databases”. 

    L'alternativa è modificare i dati quando vado a prelevarli per renderli univoci e far sì che possano coesistere in un database unico, ma mi sembra un lavorone, quindi cerco di evitarlo. L'unica eccezione è la tabella IdentityUsers, dove sono costretto a farlo per le motivazioni espresse nei post precedenti, ma è una tabella sola ed è accettabile.

  • Re: Realizzare database centralizzato con dati diverse installazioni

    Ma perche' vuoi incasinarti la vita?

    La soluzione ‘canonica’ prevede che quando peschi i dati dal cliente A e li metti nelle TUE tabelle, ci DEVE essere la colonna che dice a quale cliente appartengono, o ci deve essere il modo di identificarla univocamente (le suddette tabelle di servizio). Stop.

    Fai le modifiche del caso sui vostri sistemi, e chi si e' visto si e' visto.

    Ogni altro ‘accrocchio’ puo' portare piu' rogne che soluzioni. Nel tentativi di risparmiare lavoro, rischi di fare peggio.

  • Re: Realizzare database centralizzato con dati diverse installazioni

    25/02/2023 - migliorabile ha scritto:


    Ma perche' vuoi incasinarti la vita?

    La soluzione ‘canonica’ prevede che quando peschi i dati dal cliente A e li metti nelle TUE tabelle, ci DEVE essere la colonna che dice a quale cliente appartengono, o ci deve essere il modo di identificarla univocamente (le suddette tabelle di servizio). Stop.

    Fai le modifiche del caso sui vostri sistemi, e chi si e' visto si e' visto.

    Ogni altro ‘accrocchio’ puo' portare piu' rogne che soluzioni. Nel tentativi di risparmiare lavoro, rischi di fare peggio.

    Ma infatti ho intenzione di aggiungere una colonna in più e fare eventuali modifiche ai dati qualora necessario.

    Sopra stavo rispondendo a sspagnamn76 che stava proponendo un'altra tecnica.

  • Re: Realizzare database centralizzato con dati diverse installazioni

    Oltre CompanyId nella tabella User aggiungi anche CompanyUserId, in questo campo mappi l'user originale dell'utente, che abbinato a CompanyId diventa univoco per te, ma a livello db la PK della tabella ti rimane User.Id e non devi fare salti mortali, al massimo puoi aggiungere un indice univoco formato da { CompanyId, CompanyUserId }  per prevenire duplicati

  • Re: Realizzare database centralizzato con dati diverse installazioni

    Uhm… se questa cosa la facesse il costruttore del telefonino si scatenerebbe un popolo di sostenitori della privacy…. 

    Non conosco la natura dei dati del macchinario, ma potrebbe trattarsi, per esempio, di un miscelatore di ingredienti della ditta creatrice della famosa crema di nocciole. In questo caso potreste analizzare le pesature delle quantità degli ingredienti e vendere la formula…

    Potrebbe trattarsi di settaggi per la creazione dell'automobile sportiva, magari elettrica e carpirne i segreti dei processi produttivi…

    Scartate queste ipotesi, considerando che sia per creare una statistica nel monitoraggio dell'usura delle parti meccaniche della macchina e niente più, (anche se il frigorifero con l'app o la lavabiancheria con l'app richiede la chiusura delle porte e degli indirizzi ip)….

    Beh, credi che all'interno del software del macchinario si potrebbe creare la procedura che estrapola le statistiche e le associa al numero di matricola del macchinario (non al nominativo del cliente)…

    Un file xml? Mi sembra meno laborioso che ricevere n database ed estrarre una decina di campi con codici di funzionamento o errori (ripeto non ne conosco la natura dei dati ne dell'uso che ne vorreste fare).

    Il macchinario, previo aggiornamento software, elabora la statistica (supposto che si tratti di questo) e la inserisce nel db del produttore che avrà matricola, statistica1 statistica2 … statistican

    Credo che legalmente dovreste rilasciare l'informativa e chiedere esplicitamente l'uso dei dati per fini statistici 

    Occhio al gdpr…

  • Re: Realizzare database centralizzato con dati diverse installazioni

    27/05/2023 - sihsandrea ha scritto:


    Non conosco la natura dei dati del macchinario, ma potrebbe trattarsi, per esempio, di un miscelatore di ingredienti della ditta creatrice della famosa crema di nocciole. In questo caso potreste analizzare le pesature delle quantità degli ingredienti e vendere la formula… […]

    Scartate queste ipotesi, considerando che sia per creare una statistica nel monitoraggio dell'usura delle parti meccaniche della macchina e niente più, (anche se il frigorifero con l'app o la lavabiancheria con l'app richiede la chiusura delle porte e degli indirizzi ip)….

    Beh, credi che all'interno del software del macchinario si potrebbe creare la procedura che estrapola le statistiche e le associa al numero di matricola del macchinario (non al nominativo del cliente)…

    Un file xml? Mi sembra meno laborioso che ricevere n database ed estrarre una decina di campi con codici di funzionamento o errori (ripeto non ne conosco la natura dei dati ne dell'uso che ne vorreste fare).

    Il macchinario, previo aggiornamento software, elabora la statistica (supposto che si tratti di questo) e la inserisce nel db del produttore che avrà matricola, statistica1 statistica2 … statistican

    Credo che legalmente dovreste rilasciare l'informativa e chiedere esplicitamente l'uso dei dati per fini statistici 

    Occhio al gdpr…

    Grazie per la risposta.

    Nell'applicazione in esame la macchina viene fornita dal costruttore (noi), e pure la messa a punto viene fatta da noi. La raccolta dati idealmente dovrebbe avere scopi quali fare analisi e statistiche su come i clienti utilizzano di più le macchine, quali sono i problemi più comuni, quali causano maggiori fermi produzione etc.

    Il progetto della raccolta globale di dati è ancora in studio e non è ancora partito, e quando partirà sicuramente sarà accompagnato da un'analisi delle problematiche legali associate. Grazie per averle sollevate!

    Anche il file xml (o json) potrebbe in effetti essere una buona soluzione. Stiamo ancora studiando per capire quali dati siano più interessanti per noi, da quello dipenderà come organizzeremo lo scambio dati.

    Grazie per aver stimolato queste riflessioni!

  • Re: Realizzare database centralizzato con dati diverse installazioni

    Ok, in questo caso prendi spunto dalle case automobilistiche.

    Una centralina che registra tempi di funzionamento, codici di errore dei sensori delle  parti meccaniche, eventuali tempi e frequenze di carica batteria. Magari per la manutenzione torna utile una diagnosi di guasti.

    Se statisticamente dopo n ore di lavoro il pezzo è soggetto a rottura si può pianificare la sostituzione.

    Se poi in tutto questo vi seve un dipendente, fatemi uno squillo ;)

    Buon lavoro.

  • Re: Realizzare database centralizzato con dati diverse installazioni

    “Se hai letto, il mio problema è che avrò (non ho ancora) sparsi per il mondo diversi database, con relative tabelle ed identificatori”.

    Quando vendi un macchinario avrai in fattura la matricola del mezzo.

    Avrai una tabella matricole con i codici statistici (stat1 stat2 ecc… e il tipo di macchinario.

    Avrai una tabella macchinari legata a matricole.

    Avrai anche una tabella clienti (penso che siano dati obbligatori per emettere ddt e fattura).

    Quello che serve nel macchinario è solo un file che contiene matricola e macchinario con i codici statistici.

    Banalmente può essere un file txt.

    Il file lo importi come vuoi.

    Hai:

    clienti con codice cliente

    Matricole associato ai clienti

    Devi solo associare a matricole una tabella statistiche che avrà come campi

    Matricola e statistiche. 1 a molti.

    Avrai anche una tabella codicierrori dove avrai codiceerrore e descrizioneerrore per sapere cosa non va e come intervenire 

    La macchina non si appesantisce di dati perché registra solo gli errori, ed invia solo quando si presenta un errore, le altre trasmissioni dati le programmi a tre mesi per il corretto funzionamento e calcolare le ore di utilizzo.

Devi accedere o registrarti per scrivere nel forum
13 risposte