Sto facendo un programma per generare/filtrare/inserire tutta una serie di documenti che servono ad un certificatore.
Ogni report e ogni entità è diversa e in più dovrei fare un piccolo programma in android per l’immissione di due parametri nulla più.
Il problema è che ogni documento è diverso e ne ho tantissimi è possibile un aiuto coi database no sql tipo mongo db o altri che non sono abituato ad usare?
Quali sono i campi di utilizzo di questi tipi di database?
Leggendo su internet pensavo che potessero darmi una mano sulla gestione della documentazione.
È possibile con questi database creare dei documenti diversi anche tanti solo per qualcosa ed accederci / filtrare con il json?
E i tempi di risposta come sono?
Si possono usare in c#?
in win form coi dataset anche o in entity framework?.
come si gestiscono le relazioni in c# se fosse possibile sia in un dataset sia in entity framework?

Grazie.

Ciao Giuseppe,

ho diviso e creato delle tabelle relazionate alla anagrafica componenti del tipo : pompe, caldaie ecc... con le loro proprietà e in questo modo ho nortmalizzato il db, spero di non aver sbagliato.

Sì, è un modo valido che si chiama Table per type per evitare di creare un tabellone con tutte le possibili proprietà al suo interno.

Il problema è se dovessi creare un componente ex novo come si fa a creare delle proprietà per quel oomponente senza aggiungere delle tabelle al db?

Usando questo approccio non puoi. E' sempre necessario creare una nuova tabella.

Se non vuoi creare tabelle e vuoi continuare ad usare un database relazionale puoi usare altri approcci:

• Crei una tabella che contiene le colonne comuni a tutti i tipi. Crei una seconda tabella in cui inserire le informazioni particolari. Questa tabella conterrà solo 3 colonne: IdPadre, NomeProprietà, ValoreProprietà. Il difetto è che sei costretto ad avere valori dello stesso tipo (nvarchar) e dovrai fare pivot per riottenere tutti i nomi proprietà come se fossero stati creati come vere colonne.
• Oppure, crei una sola tabella in cui metti una colonna XML che conterrà tutti i valori specifici come fosse un documento XML.

Entrambe le soluzioni ti consentiranno di interrogare i valori specifici ma probabilmente dovrai rinunciare, almeno in parte, ad usare query LINQ (se avevi intenzione di usare EF, per esempio).

In alternativa, sì, puoi scegliere di usare un database documentale come MongoDB che ti permette di usare query LINQ.
https://mongodb-documentation.readthedocs.io/en/latest/ecosystem/tutorial/use-linq-queries-with-csharp-driver.html
L'unico modo per sapere se MongoDB è idoneo al tuo scenario è provarlo tu stesso. Considerala come attività di ricerca & sviluppo che potrebbe risolverti dei problemi poi.

Idealmente, dovresti inserire in MongoDB dei documenti autocontenuti, cioè che non hanno bisogno di alcuna JOIN.
Puoi anche scegliere di adottare una soluzione ibrida: tieni il database relazionale normalizzato e poi, ad intervalli periodici o in seguito al verificarsi di alcuni eventi, denormalizzi il contenuto creandoti dei documenti per MongoDB che diventerà il tuo "read model". In sostanza: scrivi da una parte e leggi dall'altra.

La complessità introdotta con lo scenario ibrido, secondo me, è giustificabile nel momento in cui alla tua applicazione accedono molti utenti contemporanei o quando hai una mole di dati tale che fare JOIN nel database relazionale inizia a rappresentare un vero problema per le prestazioni.

ciao,
Moreno

---

Modificato da BrightSoul il 11 marzo 2017 12.47 -

Ciao Giuseppe,

Resta per me da capire se si possono creare dei webservice per mongo in tecnologia microsoft su cui purtroppo non so nulla cosa devo studiare oltre a mongo?

Dovresti studiare ASP.NET Web API, che ti permetterà di creare webservice REST che faranno da backend alle applicazioni client.

Quello che voglio dire e che ogni azienda ha un codice e solo una parte dei dati del server gli interessa

Certo, dovrai pensare ad una strategia di partizionamento per evitare che i dati dei vari "tenant" (cioè aziende clienti) vengano mischiati tra loro. Ad esempio si possono usare database diversi oppure, come hai detto tu, inserire tutto in un unico calderone e differenziare per ID del tenant.

Se vai su Azure potresti dare un'occhiata a DocumentDB, come alternativa a Mongo. Qui c'è un documento che ti spiega come isolare i vari tenant e consentirti di scalare agevolmente quando le aziende e i documenti aumentano.
https://docs.microsoft.com/it-it/azure/documentdb/documentdb-partition-data

Comunque, dato che la decisione che stai per prendere influirà probabilmente sul successo o sul fallimento del tuo progetto, dovresti chiamare un consulente per fargli valutare attentamente il tuo scenario, in modo che possa consigliarti la soluzione più idonea nel tuo caso, tenendo conto del tuo budget di tempo e denaro e delle tue competenze.

Cerca di coinvolgere anche uno sviluppatore .NET esperto in modo che ti possa formare su ASP.NET Web API e sullo sviluppo con Azure, per accorciare il tuo time-to-market.

ciao,
Moreno

---

Modificato da BrightSoul il 12 marzo 2017 19.17 -