FORUM PER UTENTI MILLEWIN
Attenzione !
Per intervenire sul forum è necessario essere registrati e connessi.

L'Amministratore

****************************************************
“Se tu hai una mela ed io ho una mela, e ce la scambiamo, alla fine tu ed io avremo sempre una mela ciascuno.
Ma se tu hai un’idea ed io ho un’idea, e ce la scambiamo, allora avremo entrambi due idee”.

George Bernard Shaw
****************************************************

Considerazioni SQL

Andare in basso

Considerazioni SQL

Messaggio  GiampiMaz il Dom 9 Feb 2014 - 10:23

PREMESSA
L'SQL è un linguaggio, o meglio un dialetto poiché database con motori diversi possono presentare comandi e sintassi leggermente differenti, che serve per interrogare un database ed estrarne dei dati.
L'SQL è semplice e i comandi e la sintassi riflettono lo scopo da ottenere, solo che sono in inglese e quindi assolutamente incomprensibili per alcuni di noi (io in primis). In realtà l'SQL può essere anche molto potente e creare, gestire, o modificare i database, ma questo è naturalmente lasciato a veri esperti, per cui l'unico comando a cui facciamo riferimento è SELECT (seleziona...) nelle sue immense sfaccettature. TUTTI GLI ALTRI COMANDI CHE NON SIANO INTERNI A SELECT MEGLIO LASCIARLI STARE o almeno fare una o più copie di backup del nostro prezioso database prima di usarli, dopo potrebbe essere troppo tardi.

La Millennium si sta spostando verso un nuovo motore di database (postgresql) per cui molte query che prima funzionavano dovranno essere modificate, magari solo di poco o di molto.
[PARENTESI qualcuno che usa millewin con postgresql potrebbe indicarmi le principali differenze, il modo di poter passare dal vecchio sistema al nuovo? Alcuni colleghi che usano già Postgresql mi chiedono query, ma non conoscendo le sue specificità non posso aiutarli.]

DIFFERENZA TRA VISTE E TABELLE
Le Tabelle sono la 'vera' struttura del database, come è realmente scritto sul HD del computer.
Le Viste sono una rielaborazione delle tabelle fatta dal programma Milleutilità per facilitare le ricerche e sono quindi virtuali (sono solo in memoria volatile, non scritte).
L'uso delle Tabelle è più potente, non tutto ciò che è nelle tabelle è accessibile dalle Viste. Ma sono più difficili da gestire, in particolare per i numeri decimali, (non di molto, è questione di abitudine).
Se si danno dei comandi pericolosi, che cambiano il database (quindi non per interrogare ma per scrivere o cancellare) con le tabelle si possono fare disastri irrimediabili.

Per quanto ci riguarda la principale differenza è che le Viste sono gestite dalla Centrale Statistiche. Cioè centrale statistiche pre-elabora il database in base a ciò che scegliamo (pazienti attivi, libera professione, deceduti ecc.) e cerca solo in quelli. Inoltre, se si è in medicina di gruppo con un database unico, cerca solo i pazienti del medico che ha aperto il programma (Se si entra come Amministratore cerca contemporaneamente nel database di tutti i medici). Poi va scelto l'intervallo di tempo in cui cercare (a meno di indicare l'intero database). Infine vi è la finestra che mostra i vari campi delle viste per facilitare la creazione della query.
Le Tabelle invece bypassano completamente Centrale Statistiche, quindi se vogliamo selezionare un dato tipo di paziente (es. convenzionati, deceduti ecc.), o solo pazienti di un dato medico del gruppo, o un dato intervallo di tempo, dobbiamo indicare tutto ciò all'interno della query.
L'uso delle Tabelle ha un altro inconveniente: può rendere obsolete le nostre query nel caso la struttura del database cambi. Può succedere anche con le Viste ma, se i programmatori di Mille sono attenti, è più difficile. Non è frequente ma è successo: ad esempio per i principi attivi si utilizzava la tabella ATTIV, poi, dopo un aggiornamento del programma, Mille ha iniziato ad usare MN_V_TBL_GENERICA, le query che cercavano in ATTIV hanno quindi iniziato a malfunzionare (e naturalmente non è che gli utenti smanettoni siano stati avvisati, probabilmente chi usava le Viste non ha avuto problemi). Come accorgersi che qualcosa è cambiato? Se dopo un aggiornamento occorre fare 'Rigenerazione degli archivi' è probabile che qualche tabella sia stata mutata, occorrerà verificare.

E ORA LA NOTIZIA FATALE, i comandi SQL agiscono allo stesso modo sia su Viste che su Tabelle tanto che mescolare Viste e Tabelle non è proibito, ma certamente non è elegante e potrebbero esserci dei problemi. Non vi sono comandi o sintassi particolari per usare le Tabelle rispetto alle Viste, se uno conosce i comandi e la sintassi per le Viste conosce quella per le Tabelle (attenzione ai numeri, ricordo che ne abbiamo discusso).

Quale problema c'è dunque? Come dicevamo le Viste sono fatte per semplificare le cose, se vogliamo estrarre i pazienti con l'ultima glicemia ci basta una sola vista V_ACCERTAMENTI e avremo nome, cognome, valore della glicemia ecc., mentre con le Tabelle dovremo collegarne due o tre diverse. Ma anche con le Viste per query complesse occorre collegarne più di una e la cosa non è differente dal farlo con le Tabelle.

Quello che occorre sapere in più usando le Tabelle rispetto alle Viste sono le specifiche Tabelle di millewin e la loro struttura. Che io sappia la Millennium non ha mai rilasciato queste informazioni.
Tuttavia con un poco di pazienza si possono ricavare (chiunque usi le Tabelle in modo non superficiale lo ha fatto):
Con Select * from tables hai l'elenco delle tabelle (il vero database) (grazie Draghini). Con select * from cart_accert (il nome di una tabella come esempio, o nos_002 ecc.) puoi poi esplorare il loro significato (così si estrarranno migliaia e migliaia di righe, premere x in alto a destra per interrompere, suggerisco di scrivere una breve query che estragga solo la tabella voluta di un dato paziente, magari fittizio, o solo un dato giorno per limitare il numero di righe estratte). 
Il nostro è un database relazionale, cioè le tabelle sono collegate tra loro tramite un campo chiave (campo presente in quasi tutte le varie tabelle). Quelle principali sono collegate tramite il campo chiave che è codice (il numero univoco che identifica il paziente), alcune hanno campi chiave diversi. Chi utilizza le Tabelle deve conoscerle.
E' interessante come, analizzando la struttura delle tabelle, si faccia quasi uno scavo archeologico, notando ripensamenti, campi creati e poi non usati o usati per scopi diversi da quelli originari. Si può vedere l'affannarsi negli anni a tenere dietro alla follia burocratica che ci schiaccia.

Quindi ribadisco che non vi sono comandi speciali o sintassi speciale per le Tabelle, se alle volte usiamo con esse comandi insoliti è magari perché occorre formattare un numero mentre è raramente necessario con le Viste, ma non è che quei comandi non agiscano con le Viste o che, per determinati scopi, non possano essere usati. Il piccolo manuale del Gran Maestro Draghini è una buona partenza, quello che spiega è perfettamente valido per le Tabelle (come detto sopra occorrerà collegarne solo di più tra loro, ma soprattutto sapere quali), non sono presenti tutti i comandi possibili, in particolare mi sembra manchino la gestione delle stringhe e il comodo comando LIST() ma questi valgono sia per Tabelle che Viste, qualsiasi manuale SQL li ha.

giampiero
avatar
GiampiMaz
Membro Junior
Membro Junior

Messaggi : 122
Punti : 2841
Voti per importanza dei messaggi : 33
Data d'iscrizione : 20.02.11

Visualizza il profilo dell'utente

Torna in alto Andare in basso

Re: Considerazioni SQL

Messaggio  Admin il Dom 9 Feb 2014 - 13:34

Bravo Giampiero, aggiungo solo che è estremamente istruttivo l'analisi delle estrazioni fatte dai colleghi che si "dilettano" in questo esercizio (pur svolgendo altra professione), come Giampiero e Draghini. Il linguaggio SQL è come quello matematico, non basta conoscere le operazioni, ma è indispensabile il ragionamento per risolvere qualunque problema. Naturalmente la partenza è nei dati a disposizione per raggiungere il risultato finale (cioè cosa estrarre). Spesso le richieste di query vengono fatte senza spiegare bene cosa si vuole estrarre con precisione. Ciò causa una notevole perdita di tempo perché chiarendo gli obiettivi non sempre è possibile cambiare il risultato della query con delle piccole modifiche, ma occorre ricominciare completamente daccapo. Le idee devono essere estremamente chiare altrimenti un punto o una virgola in più o in meno portano a risultati completamente diversi.
Per finire allego un file Excel che mi sono creato per avere sottocchio le principali tabelle di Millewin ed i relativi campi.
File allegati
Tabelle e Campi Millewin.xlsx Tabelle e Capi MillewinNon hai il permesso di scaricare i file.(35 kB) Scaricato 24 volte

_________________
L'Amministratore
Giuseppe Blasio
avatar
Admin
Admin
Admin

Messaggi : 521
Punti : 3326
Voti per importanza dei messaggi : 85
Data d'iscrizione : 20.02.11
Località : CASERTA

Visualizza il profilo dell'utente http://utentimillewin.forumattivo.it

Torna in alto Andare in basso

Re: Considerazioni SQL

Messaggio  GiampiMaz il Gio 13 Feb 2014 - 22:19

Per completezza ripropongo un vecchio post che spiegava il diverso uso dei numeri decimali con Viste e Tabelle

I NUMERI
L'SQL è anglo-americano e riconosce come numeri solo le cifre col punto, se c'è la virgola le considera come una stringa alfabetica. Di conseguenza tutte le operazioni matematiche da + - a > < a comandi come AVG (media) ecc si possono fare solo se si è scritto i dati col punto per i decimali. La visualizzazione non pone naturalmente problemi, è indifferente se sia numero o stringa.
Ciò è vero se si usano le Tabelle. Le Viste, che sono una rielaborazione delle tabelle fatta dal programma, funzionano in modo leggermente diverso. Nella vista V_ACCERTAMENTI vi sono due campi che mostrano il risultato: Risults che è ciò che hai scritto (col punto o con la virgola), se è col punto lo potrai utilizzare come numero se è con la virgola no, poi vi è il campo Risultn, questo è una rielaborazione del programma che mostra il numero di risultn con la virgola sia che tu l'abbia scritto col punto che con la virgola, (tuttavia internamente lo deve memorizzare col punto) e lo considera numero e su di esso si possono fare tutte le operazioni matematiche normalmente anche se apparentemente ha la virgola.
Millewin ha evidentemente scelto di essere userfrendly privilegiando l'uso italiano della virgola e ha messo a disposizione una vista adatta.
Quindi a seconda di quello che vuoi ottenere dovrai usare le viste con risultn o risults che permette di scrivere i numeri come ci pare.

Se vuoi usare le tabelle o utilizzi sempre il punto per i decimali (MA NOI SIAMO ITALIANI!) o per superare l'ostacolo si può riformattare il numero sostituendo la virgola col punto prima di eseguire l'operazione matematica. Esempio riformattiamo ac_val prima di usare il comando AVG:

AVG (If charindex(',',ac_val)>0 then cast(substring( ac_val,1,(charindex(',',ac_val) - 1 )) + '.' + substring(ac_val, (charindex(',',ac_val) +1 )) AS dec (7,2)) else cast(ac_val AS dec (7,2)) endif)

naturalmente ci sono anche altri modi di formattare i valori:

Cast( Max( If Locate(a.ac_val,',') > 0 Then Left(a.ac_val, Locate(a.ac_val,',')-1)+'.'+ Right(a.ac_val, Length(a.ac_val) - Locate(a.ac_val, ',')) Else a.ac_val Endif ) As Dec(5,1))    
formatta a.ac_val

Cast( Max ( Case Locate(a.ac_val,',') > 0 When Left(a.ac_val, Locate(a.ac_val,',')-1)+'.'+ Right(a.ac_val, Length(a.ac_val) - Locate(a.ac_val, ',')) Else a.ac_val End ) As Dec(5,1))   
formatta a.ac_val

Non importa capire subito come funziona, la si utilizza col copia/incolla tutta la parte in corsivo, al posto di ac_val potrà essere necessario mettere un diverso campo numerico a seconda della tabella estratta.


Per quanto riguarda le considerazioni viste/tabelle posso fermarmi qui.
Se a qualcuno interessa si potrebbe analizzare i campi di alcune tabelle per vedere come si intrecciano tra loro. Se uno guarda la tabella postata dall'Admin può rendersi conto della complessità del nostro database.
Saluti
giampiero
avatar
GiampiMaz
Membro Junior
Membro Junior

Messaggi : 122
Punti : 2841
Voti per importanza dei messaggi : 33
Data d'iscrizione : 20.02.11

Visualizza il profilo dell'utente

Torna in alto Andare in basso

Re: Considerazioni SQL

Messaggio  Lucio Mignone il Ven 14 Feb 2014 - 22:56

GiampiMaz ha scritto:Per completezza ripropongo un vecchio post che spiegava il diverso uso dei numeri decimali con Viste e Tabelle

I NUMERI
L'SQL è anglo-americano e riconosce come numeri solo le cifre col punto, se c'è la virgola le considera come una stringa alfabetica. Di conseguenza tutte le operazioni matematiche da + - a > < a comandi come AVG (media) ecc si possono fare solo se si è scritto i dati col punto per i decimali. La visualizzazione non pone naturalmente problemi, è indifferente se sia numero o stringa.
Ciò è vero se si usano le Tabelle. Le Viste, che sono una rielaborazione delle tabelle fatta dal programma, funzionano in modo leggermente diverso. Nella vista V_ACCERTAMENTI vi sono due campi che mostrano il risultato: Risults che è ciò che hai scritto (col punto o con la virgola), se è col punto lo potrai utilizzare come numero se è con la virgola no, poi vi è il campo Risultn, questo è una rielaborazione del programma che mostra il numero di risultn con la virgola sia che tu l'abbia scritto col punto che con la virgola, (tuttavia internamente lo deve memorizzare col punto) e lo considera numero e su di esso si possono fare tutte le operazioni matematiche normalmente anche se apparentemente ha la virgola.
Millewin ha evidentemente scelto di essere userfrendly privilegiando l'uso italiano della virgola e ha messo a disposizione una vista adatta.
Quindi a seconda di quello che vuoi ottenere dovrai usare le viste con risultn o risults che permette di scrivere i numeri come ci pare.

Se vuoi usare le tabelle o utilizzi sempre il punto per i decimali (MA NOI SIAMO ITALIANI!) o per superare l'ostacolo si può riformattare il numero sostituendo la virgola col punto prima di eseguire l'operazione matematica. Esempio riformattiamo ac_val prima di usare il comando AVG:

AVG (If charindex(',',ac_val)>0 then cast(substring( ac_val,1,(charindex(',',ac_val) - 1 )) + '.' + substring(ac_val, (charindex(',',ac_val) +1 )) AS dec (7,2)) else cast(ac_val AS dec (7,2)) endif)

naturalmente ci sono anche altri modi di formattare i valori:

Cast( Max( If Locate(a.ac_val,',') > 0 Then Left(a.ac_val, Locate(a.ac_val,',')-1)+'.'+ Right(a.ac_val, Length(a.ac_val) - Locate(a.ac_val, ',')) Else a.ac_val Endif ) As Dec(5,1))    
formatta a.ac_val

Cast( Max ( Case Locate(a.ac_val,',') > 0 When Left(a.ac_val, Locate(a.ac_val,',')-1)+'.'+ Right(a.ac_val, Length(a.ac_val) - Locate(a.ac_val, ',')) Else a.ac_val End ) As Dec(5,1))   
formatta a.ac_val

Non importa capire subito come funziona, la si utilizza col copia/incolla tutta la parte in corsivo, al posto di ac_val potrà essere necessario mettere un diverso campo numerico a seconda della tabella estratta.


Per quanto riguarda le considerazioni viste/tabelle posso fermarmi qui.
Se a qualcuno interessa si potrebbe analizzare i campi di alcune tabelle per vedere come si intrecciano tra loro. Se uno guarda la tabella postata dall'Admin può rendersi conto della complessità del nostro database.
Saluti
giampiero


Questa dei numeri e delle virgole e dei numeri trattati come stringhe di testo è una vecchia ed importante storia. 
Ringrazio Giampiero per avermi istruito a suo tempo.

Tempo fai provai a spiegare queste difficoltà che si incontrano nelle estrazioni dei decimali ai colleghi durante un corso di formazione, ma fui attaccato pubblicamente sostenendo che creavo problemi inesistenti chiedendo di inserire bene i numeri con i decimali, che 'punto e virgola per me pari son' e che mai nessuno aveva riscontrato tali problemi nelle estrazioni dei decimali.
Insomma ero guardato come si guarda uno psicotico che racconta di essere in contatto con gli UFO…
Mi farebbe piacere se un giorno, avendo necessità di estrarre i loro decimali, i punti e le virgole popolassero i loro sogni inquieti… 
Io, naturalmente, in quel frangente sarò molto impegnato a parlare con gli extraterrestri Very Happy .
avatar
Lucio Mignone
Membro Senior
Membro Senior

Messaggi : 626
Punti : 3466
Voti per importanza dei messaggi : 34
Data d'iscrizione : 20.02.11
Età : 54
Località : CAVRIGLIA (AR)

Visualizza il profilo dell'utente http://comeva.altervista.org/

Torna in alto Andare in basso

Re: Considerazioni SQL

Messaggio  Contenuto sponsorizzato


Contenuto sponsorizzato


Torna in alto Andare in basso

Torna in alto

- Argomenti simili

 
Permessi di questa sezione del forum:
Non puoi rispondere agli argomenti in questo forum