[progettazione DB] memorizzazione telegrammi

[sottovento]

Carissimi
ho un altro quesito da sottoporre ai piu' esperti di database.
Ho un sistema di produzione, il quale spedisce periodicamente via socket dei TELEGRAMMI (i.e. un pacchetto di dati - una struttura C, per semplificare - con un'intestazione che la identifica).

Questi telegrammi devono essere memorizzati in un database per verifica della produzione.
Il problema e' che questi telegrammi possono essere modificati, anche frequentemente, e vorrei trovare la maniera di NON modificare il database a seguito della modifica del telegramma.

- potrei, per esempio, inserire il telegramma in un record, il quale contiene gli identificativi ed un BLOB per contenere tutti i dati. Ovviamente il db non cambierebbe se il telegramma cambia. Purtroppo i dati che ottengo dal db non sono immediatamente leggibili;

- potrei creare una tabella dove memorizzo le single parti del telegramma. Per esempio, gli interi in una tabella, i float in un'altra e cosi' via. Naturalmente memorizzerei il dato con l'id del telegramma, l'id del campo corrispondente ed un progressivo. Anche in questo caso non modificherei il database e potrei vedere il telegramma per mezzo di una view che rimetta i dati al loro posto.
Pero' questo sistema potrebbe funzionare nel caso avessi pochi dati, visto l'enorme overhead che i costringe ad avere.

Altro? Qualcuno ha un'idea migliore?

[dojolab]

Questi telegrammi devono essere memorizzati in un database per verifica della produzione.
Il problema e' che questi telegrammi possono essere modificati, anche frequentemente, e vorrei trovare la maniera di NON modificare il database a seguito della modifica del telegramma.

Basta modificare le autorizzazioni di lettura, scrittura sul db, disabilitando quelle di aggiornamento e cancellazione ma abilitando solo quelle di inserimento.


- potrei, per esempio, inserire il telegramma in un record, il quale contiene gli identificativi ed un BLOB per contenere tutti i dati. Ovviamente il db non cambierebbe se il telegramma cambia. Purtroppo i dati che ottengo dal db non sono immediatamente leggibili;

Penso che questa sia una ottima strada.
Un diagramma E-R ti aiuterebbe parecchio nella progettazione concettuale del tuo DB; unica domanda, perché non sono IMMEDIATAMENTE leggibili? (è un parametro che mi sfugge :)).

[sottovento]

Grazie per la risposta

Basta modificare le autorizzazioni di lettura, scrittura sul db, disabilitando quelle di aggiornamento e cancellazione ma abilitando solo quelle di inserimento.



Penso che questa sia una ottima strada.
Un diagramma E-R ti aiuterebbe parecchio nella progettazione concettuale del tuo DB; unica domanda, perché non sono IMMEDIATAMENTE leggibili? (è un parametro che mi sfugge :)).

Per immediatamente leggibile intendo che, se il telegramma fosse memorizzato nel database in modo che ogni campo abbia la sua colonna (e magari la colonna avesse lo stesso nome del campo), potrei vedere i dati comodamente con una SELECT. In piu' potrei fare delle SELECT sulla base dei valori dei campi.
Questo ovviamente non e' possibile se memorizzo in un blob: devo estrarre i dati, decodificarli,.... ed ovviamente non posso fare query sui valori di questi campi.

[dojolab]

Grazie per la risposta
Per immediatamente leggibile intendo che, se il telegramma fosse memorizzato nel database in modo che ogni campo abbia la sua colonna (e magari la colonna avesse lo stesso nome del campo), potrei vedere i dati comodamente con una SELECT. In piu' potrei fare delle SELECT sulla base dei valori dei campi.
Questo ovviamente non e' possibile se memorizzo in un blob: devo estrarre i dati, decodificarli,.... ed ovviamente non posso fare query sui valori di questi campi.

Ahhh LOL, spesso non ci si comprende sul Forum.
Quindi è un tuo problema 'immediatamente leggibile'.

BLOB indica un campo binario, non so che DBMS usi ma penso che con una Stored qualsiasi puoi tornarti fuori i dati testuali da visualizzare; in alternativa potresti crearti una base di dati sotto che contiene tutti i dati del telegramma e una vista per stampare SOLo quelli che ti interessano.

I privilegi di autorizzazione è la forma più sicura per evitare l update/delete della tabella :) basta un GRANT all'utente fruitore dell'istanza della base di dati.

[cdimauro]

Carissimi
ho un altro quesito da sottoporre ai piu' esperti di database.
Ho un sistema di produzione, il quale spedisce periodicamente via socket dei TELEGRAMMI (i.e. un pacchetto di dati - una struttura C, per semplificare - con un'intestazione che la identifica).

Questi telegrammi devono essere memorizzati in un database per verifica della produzione.
Il problema e' che questi telegrammi possono essere modificati, anche frequentemente, e vorrei trovare la maniera di NON modificare il database a seguito della modifica del telegramma.

- potrei, per esempio, inserire il telegramma in un record, il quale contiene gli identificativi ed un BLOB per contenere tutti i dati. Ovviamente il db non cambierebbe se il telegramma cambia. Purtroppo i dati che ottengo dal db non sono immediatamente leggibili;

- potrei creare una tabella dove memorizzo le single parti del telegramma. Per esempio, gli interi in una tabella, i float in un'altra e cosi' via. Naturalmente memorizzerei il dato con l'id del telegramma, l'id del campo corrispondente ed un progressivo. Anche in questo caso non modificherei il database e potrei vedere il telegramma per mezzo di una view che rimetta i dati al loro posto.
Pero' questo sistema potrebbe funzionare nel caso avessi pochi dati, visto l'enorme overhead che i costringe ad avere.

Altro? Qualcuno ha un'idea migliore?
Quali dati devi memorizzare per ogni telegramma?

Inoltre, più o meno qual è l'ordine di grandezza trattato.

Oltre a quello che ha detto dojolab, considera che tanti engine SQL permettono di trattare un BLOB in maniera similare a un campo di testo, quindi puoi visualizzarne i dati contenuti e magari farci qualche operazione di ricerca.

[sottovento]

Quali dati devi memorizzare per ogni telegramma?

Inoltre, più o meno qual è l'ordine di grandezza trattato.

Oltre a quello che ha detto dojolab, considera che tanti engine SQL permettono di trattare un BLOB in maniera similare a un campo di testo, quindi puoi visualizzarne i dati contenuti e magari farci qualche operazione di ricerca.

Per semplificare: ricevo dei telegrammi da ogni "stazione" di lavorazione di un impianto. Diciamo che ogni telegramma mi porta un centinaio di campi (forze, coppie, temperature, ...). A seconda della stazione, i telegrammi arrivano lentamente (per esempio, uno per ogni prodotto) oppure velocemente (per esempio, uno ogni 20 centimetri della lunghezza del prodotto).

Per migliorare la produzione, ogni stazione periodicamente acquista nuovi sensori o migliora quelli che ha. Pertanto, periodicamente decide di cambiare i telegrammi aggiungendo/togliendo campi.

La quantita' di dati che mi arrivano non e' tale da impensierire alcun computer. Volevo pero' pensare (RIpensare) ad una architettura che fosse la piu' flessibile e meno sensibile ai cambiamenti.

[dojolab]

Per semplificare: ricevo dei telegrammi da ogni "stazione" di lavorazione di un impianto. Diciamo che ogni telegramma mi porta un centinaio di campi (forze, coppie, temperature, ...). A seconda della stazione, i telegrammi arrivano lentamente (per esempio, uno per ogni prodotto) oppure velocemente (per esempio, uno ogni 20 centimetri della lunghezza del prodotto).

Per migliorare la produzione, ogni stazione periodicamente acquista nuovi sensori o migliora quelli che ha. Pertanto, periodicamente decide di cambiare i telegrammi aggiungendo/togliendo campi.

La quantita' di dati che mi arrivano non e' tale da impensierire alcun computer. Volevo pero' pensare (RIpensare) ad una architettura che fosse la piu' flessibile e meno sensibile ai cambiamenti.

Perché i campi possono variare con il variare dei sensori giusto?

[sottovento]

Perché i campi possono variare con il variare dei sensori giusto?

Yes, sir. Piu' informazioni = piu' campi.
Ora nel sistema vengono scambiati circa 500 diversi tipi di telegrammi. Alcuni sono in uscita: li invio io alle stazioni dell'impianto per i vari set-point, schedule, ... Questi in generale sono inviati prima che la stazione operi su un prodotto (sto semplificando molto, a dire il vero, ma non penso che i dettagli siano importanti).

Durante la lavorazione (o a lavorazione ultimata, a seconda dei casi) ottengo le misurazioni ed i vari responsi. Ogni prodotto ha un nome (i.e. un id), quindi posso capire se il prodotto e' stato conforme alle specifiche che ho spedito, preparare report e cosi' via.

Ovviamente posso mettere tutti questi telegrammi nei blob e preservarmi da modifiche in caso che i telegrammi cambino. Pero' e' chiaro che ho svantaggi quali, ad esempio, l'impossibilita' di estrazione dei telegrammi che appartengono ad un singolo prodotto o processo di lavorazione, ....
Insomma, non posso fare tutte le query che potrei immaginare nel caso decidessi, per esempio, di creare le 500 tabelle (una per ogni telegramma) e associassi ad ogni colonna il corrispondente field del telegramma.

Mi piacerebbe avere i vantaggi dell'uno e dell'altro sistema, ma non ho nemmeno capito se e' davvero possibile

[dojolab]

Yes, sir. Piu' informazioni = piu' campi.
Ora nel sistema vengono scambiati circa 500 diversi tipi di telegrammi. Alcuni sono in uscita: li invio io alle stazioni dell'impianto per i vari set-point, schedule, ... Questi in generale sono inviati prima che la stazione operi su un prodotto (sto semplificando molto, a dire il vero, ma non penso che i dettagli siano importanti).

Durante la lavorazione (o a lavorazione ultimata, a seconda dei casi) ottengo le misurazioni ed i vari responsi. Ogni prodotto ha un nome (i.e. un id), quindi posso capire se il prodotto e' stato conforme alle specifiche che ho spedito, preparare report e cosi' via.

Ovviamente posso mettere tutti questi telegrammi nei blob e preservarmi da modifiche in caso che i telegrammi cambino. Pero' e' chiaro che ho svantaggi quali, ad esempio, l'impossibilita' di estrazione dei telegrammi che appartengono ad un singolo prodotto o processo di lavorazione, ....
Insomma, non posso fare tutte le query che potrei immaginare nel caso decidessi, per esempio, di creare le 500 tabelle (una per ogni telegramma) e associassi ad ogni colonna il corrispondente field del telegramma.

Mi piacerebbe avere i vantaggi dell'uno e dell'altro sistema, ma non ho nemmeno capito se e' davvero possibile

Beh, ti basterebbe fare una tabella sensori nel quale memorizzi la tipologia degli apparecchi (con id univoco e relativi campi); basta fare una tabella delle specifiche a parte e associarla in relazione alla tabella sensori.

I telegrammi li salvi in una tabella telegrammi associando ad ogni telegramma il relativo sensore che legge il dato cosi sai esattamente quali campi aspettarti in fase di 'stampa' del telegramma.

Ricapitolando avresti 3 tabelle

- sensori (id, nome, e quel che vuoi)
- specifiche_sensori (id, sensore, specifica, valore di default se previsto)
- telegramma (id, codice, nome, sensore associato)

:D possiamo fare un UML se vuoi :P

[cdimauro]

Per semplificare: ricevo dei telegrammi da ogni "stazione" di lavorazione di un impianto. Diciamo che ogni telegramma mi porta un centinaio di campi (forze, coppie, temperature, ...). A seconda della stazione, i telegrammi arrivano lentamente (per esempio, uno per ogni prodotto) oppure velocemente (per esempio, uno ogni 20 centimetri della lunghezza del prodotto).

Per migliorare la produzione, ogni stazione periodicamente acquista nuovi sensori o migliora quelli che ha. Pertanto, periodicamente decide di cambiare i telegrammi aggiungendo/togliendo campi.

La quantita' di dati che mi arrivano non e' tale da impensierire alcun computer. Volevo pero' pensare (RIpensare) ad una architettura che fosse la piu' flessibile e meno sensibile ai cambiamenti.
Ho capito. Data la notevole dinamicità dei dati, potresti valutare a questo punto un db non relazionale (filosofia NoSQL).

A lavoro in questi casi utilizziamo MongoDB: http://www.mongodb.org/

[dojolab]

Ho capito. Data la notevole dinamicità dei dati, potresti valutare a questo punto un db non relazionale (filosofia NoSQL).

A lavoro in questi casi utilizziamo MongoDB: http://www.mongodb.org/

LOL che nome cesare, fortuna non hanno aggiunto la LO. :)
Me lo guardo pure io ;)

[sottovento]

Ho capito. Data la notevole dinamicità dei dati, potresti valutare a questo punto un db non relazionale (filosofia NoSQL).

A lavoro in questi casi utilizziamo MongoDB: http://www.mongodb.org/

Speravo che mi dicessi questo :D
In effetti ero arrivato a fare una valutazione simile e stavo cominciando a valutare Cassandra. Ma immagino che tu abbia un'idea piu' precisa della mia riguardo NoSQL, per cui seguiro' il tuo consiglio e guardero' prima MongoDB.
E poi il nome mi piace... ho avuto una fidanzata mongola (prima di sposare una cinese) ;)

[sottovento]

Ho capito. Data la notevole dinamicità dei dati, potresti valutare a questo punto un db non relazionale (filosofia NoSQL).

A lavoro in questi casi utilizziamo MongoDB: http://www.mongodb.org/

Wow! Sembrerebbe proprio quello giusto! Grazie

Ultima domanda: sai qualcosa delle prestazioni? E' *ragionevolmente* veloce? Puo' gestire un *discreto* numero di record?
(ragionevolmente e discreto, diciamo in comparazione con un db tradizionale quale Oracle o MySql)

[cdimauro]

Scusami se ti rispondo adesso, ma sono reduce dal christmas party aziendale. :stordita:

Per loro natura i database non relazionali sono generalmente molto più veloci di quelli relazionali.

E' chiaro che la velocità si paga: non ci sono stored procedure e integrità referenziale, ad esempio. Inoltre, per quelli che implementano transazioni ACID (non tutti lo permettono) in genere la "transazione" riguarda un preciso dato/record e non un loro insieme.

Personalmente tendo a preferire i db relazionali quando posso, perché tendo a utilizzare tutto ciò che di buono offrono (ecco perché farei volentieri a meno di MySQL, ma purtroppo a lavoro abbiamo questo e me lo debbo sorbire :muro:), ma non escludo a priori quelli non relazionali.
Preferenze a parte, quando per un dato problema gli svantaggi nell'uso di un db relazionale sono troppi, passo a valutare quelli non relazionali.

Ti ho indicato MongoDB, perché lo usiamo a lavoro e quindi lo conosco, ma fra quelli non relazionali di cui ho valutato le caratteristiche lo trovo fra i più comodi perché:
- offre un'ottima scalabilità;
- ha una console javascript (OK, mi fa schifo come linguaggio, ma meglio che niente);
- supporta ACID per le operazioni atomiche (su singoli dati/record);
- supporta la replicazione (e a breve anche in clustering; anzi, non so se l'abbiano già implementato, visto che è da un pezzo che non controllo il sito);
- memorizza i dati in formato JSON binario (BSON), per cui utilizza JSON come formato di import/export, che è decisamente leggibile.

Poiché avevi intenzione di eseguire delle query e, quindi, avere a che fare con dati leggibili, penso calzi a pennello per i tuoi problemi.

Tra l'altro ha binding per diversi linguaggi, fra cui ovviamente Python (anche se ho realizzato un wrapper per realizzare qualcosa di più carino :fagiano: ).

x dojolab: occhio che per l'e-commerce non lo userei. Come non userei MySQL con MyISAM. :fagiano:

[sottovento]

Scusa il ritardo, sono reduce da un viaggio in Italia

Grazie mille per le informazioni, sono state preziosissime. Ho visto che c'e' qualche problema a trovare il driver C++ per Windows, ci devo lavorare un po'. Sembra davvero quello che cercavo

[dojolab]

x dojolab: occhio che per l'e-commerce non lo userei. Come non userei MySQL con MyISAM. :fagiano:

LOL ma quello è scontato :D