Newsgroup: it.comp.lang.vo-clipper
Titolo: Ancora su SQL vs "la cosa"

Buondì a tutti,
ho letto in ritardo la lunga discussione sulla vetustità del SQL e volevo
aggiungere alcune mie considerazioni personali che spero qualcuno abbia
voglia di leggere, particolarmente Enrico Maria.
Faccio una premessa: ditemi cosa è possibile usare al giorno d'oggi al posto
di SQL, perché magari mi sono talmente avvilippato a tale modo di affrontare
l'accesso ai dati che stò perdendo i migliori giorni della mia vita dietro a
query di 2000 o 3000 caratteri quando esistono sistemi che in uno schiocco
di dita ti risolvono la vita.
Detto questo, ricordo che SQL è un linguaggio per la manipolazione dei dati,
non di programmazione, particolarmente adatto per gestire tuple in database
relazionali tramite operazioni di aggiunta, eliminazione e modifica righe,
oppure ad estrarre un insieme di dati per costruire un cursore, ovvero un
subset di dati dell'insieme iniziale su cui far ragionare il programma.
I limiti del sistema non sono in SQL, ma nei linguaggi di programmazione che
usano SQL il ragiona per insiemi di dati, mentre i linquaggi, almeno quelli
che conosco io, possono gestire un solo elemento per volta e sono obbligati
ad usare un cursore. Tutti i vari sistemi per manipolare dati che conosco,
da prima di ADO ad oltre, non sono altro che interfacce per presentare i
cursori al programma e gestire le operazioni sul database.
Non vorrei essere scortese, ma devo chiedere: avete chiaro cos'è un database
relazionale? Io ho dei dubbi! In un database relazionale, tanto per fare un
esempio, io devo avere una testata DDT che possiede tante righe di
dettaglio, a loro volta relazionate con il magazzino, mentre la testata è
relazionata al cliente, al destinatario, alle condizioni di trasporto che a
loro volta sono relazionate con il vettore e le sue tariffe, mentre il
cliente è relazionato con le nazioni che a loro volta sono legate alle
informazioni fiscali sugli ambiti internazionali, mentre il destinatario è
legato ad istruzioni standard di consegna, ma gli articoli di magazzino
hanno anche specifiche informazioni doganali e ci sono pure i dati della
convenzione di Washington, e per ogni nazione ci sono le varie dogane e le
persone da contattare per i problemi di sdoganamento... vi basta?
Se io devo isolare un singolo DDT tra 20.000 testate e 300.000 righe e tutti
i dati inerenti via rete - magari WAN - senza occupare per minuti qualche
manciata di MB di banda passante, francamente non conosco altre vie; con SQL
ed una query complessa quanto volete (ma che disegno con Access in 10
minuti!) ottengo 30, 50, 70 colonne con tutti i dati che voglio, ovvero una
tabella "più larga che lunga", mentre con gli altri approcci che conosco
dovrei aprire decine di tabelle e gestire la sincronia, per non parlare
degli errori relazionali.
Ho visto più volte programmi personalizzati "che usano database" dove in
realta i vari server SQL (o anche MS-JET, che per fare tante cose va
benissimo) sono usati solo come l'equivalente di una cartella dove salvare
un file, pardon una tabella, giusto con qualche costrinzione qua e la. In
questi casi mi rendo conto che la "fatica" di scrivere una query è inutile.
Non voglio difendere SQL perché tanto non l'ho sposato e non me ne viene
nulla, ma in quel delirio di complessità che è 
VB.NET
, che peraltro è
comunque un vero linguaggio ad oggetti, i bravi componenti 
ADO.NET
 non fanno
altro che gestire l'interfaccia tra i set di dati locali e il server tramite
istruzioni SQL.
E del resto lo vedo chiaramente portando i programmi Clipper/xBase da DBF a
SQL: le tabelle raddoppiano o triplicano rispetto ai files, gli "USE" si
riducono di un ordine di grandezza, le righe di programma si dimezzano.
In quanto ai database object-oriented, ne sento parlare da almeno quattro
anni ma non ne ho visto uno. Lavorando con Clipper e DBF c'era "il dramma"
che la logica di database e l'elaborazione dei dati erano implementati nel
software; con l'approccio tramite SQL finalmente ho potuto contare su una
netta divisione dei poteri - io gestisco i dati e faccio qualche semplice
manipolazione, tu gli elabori - mentre un database ad oggetti dovrebbero per
definizione contenere anche tutti i metodi per l'elaborazione,
indifferentemente dalla loro complessita. Per me, sarebbe un grosso passo
all'indietro sulla strada dell'affidabilità e delle robustezza.
Ed infine dico io, cos'è un database relazionale se non una rappresentazione
ad oggetti del mondo reale? Se io dico "veicolo", poi posso stabilire una
subclasse "automobili", e poi ancora un'altra subclasse "monovolumi"; però
posso anche definire una tabella "veicoli" dove c'è il marchio; alcune righe
sono relazionate con un rapporto 1-1 alla tabella "automobili" che contiene
informazioni sul numero di passeggeri, la potenza e la velocità massima,
mentre le righe che rappresentano i monovolume sono a loro volta relazionate
con un'altra tabella sempre relazionata 1-1 che contiene dati tipo le
possibilità di configurazione interna, il volume di carico, ecc. ecc...
L'ultima battuta, sempre ricollegandomi ai discorsi precedenti: il caro
vecchio assembler non lo usa (quasi) più nessuno, eppure alla fine tutti i
linguaggi che esistono sulla faccia della terra non fanno altro che eseguire
istruzioni in linguaggio-macchina perdendo nella conversione decine,
centinaia o migliaia di volte in efficienza, e tale codice-macchina non è
altro che una serie di direttive per il firmvare interno della CPU. SQL è lo
stesso: puoi non usarlo, ma alla fine (quasi) sempre gli strumenti che
utilizzi non fanno altro che utilizzare SQL per gestire una fonte dati,
magari non necessariamente tramite chiamate standard (vedi driver nativi per
particolari database), la quale a sua volta elabora le tuple con i propri
meccanismi interni.
Grazie per la pazienza..
francesco renieri

 Grazie per la pazienza..
E' stato un piacere.
Anche a me non viene in tasca nulla a parlare bene o male di SQL, purchè si
sappia di cosa si parla.
Lo uso, non sono contento di non avere alternative, cerco di fargli fare
SOLO il suo dovere (interrogare), ma mi rendo conto che gli strumenti che
abbiamo oggi per lavorare con i migliori motori database sono scarsi,
inefficienti (perchè non sono linguaggi di programmazione), e come dici tu,
tutti figli del solo SQL.
Ciao
Massimo
ARCA Sistemi S.r.l.

 utilizzi non fanno altro che utilizzare SQL per gestire una fonte dati,
Certo, è così. Ma dov'è scritto che sia la situazione migliore
possibile?
EMG
--
EMAG Software Homepage:     
http://www.emagsoftware.it
The EMG's ZX-Spectrum Page: 
http://www.emagsoftware.it/spectrum
The Best of Spectrum Games: 
http://www.emagsoftware.it/tbosg

 codice.
Infatti. Tra l'altro ritengo che modificare una query molto complessa
non sia affatto più semplice che modificare un programma procedurale o
object oriented ben fatto.


 ha scritto nel
messaggio news:4096B607...@emagsoftware.it...


 Anche tu hai una certa età, eh? :-)
Purtroppo. :-)))


 meccanismi interni.
Scrivere in Asembler sarebbe senza dubbio efficiente da un punto di vista
delle prestazione, ma assai poco pratico dal punto di vista di gestione del
progetto.
Per quanto "obsoleto" si possa ritenere il linguaggio SQL nessuno ci
impedisce, con i moderni strumenti di sviluppo, di realizzare layer astratti
su cui implementare applicazioni molto complesse e se si vuole anche
indipendenti dal database utilizzato.

 indipendenti dal database utilizzato.
Vero. Ma io continuo a chiedermi perché mai i progettisti di motori di
database si ostinino ancora a supportare l'SQL. O meglio, lo so:
standard e compatibilità. Risultato: scalabilità. E non è poco! Spero
solo che con il tempo evolva un linguaggio più moderno che sostituisca
l'SQL, tutto qui. Posso almeno augurare questo ai nostri figli? :-)


 l'SQL, tutto qui. Posso almeno augurare questo ai nostri figli? :-)
Cosa ti devo dire..... sinceramente al momento non ho motivo di ricercare
soluzioni più avanzate. Tutto cio' che devo fare riesco a farlo
tranquillamente .... inoltre sono dell'idea che il sistema più semplice è
anche quello più stabile e facile da capire....
Ciao

 anche quello più stabile e facile da capire....
Questo è il punto: l'SQL non è un linguaggio semplice! Forse non ti sei
mai trovato a scrivere query complesse ma ti assicuro che in quei casi,
a volte, si rischia di perdere la sanità mentale. :-) Quando con un
linguaggio moderno potresti utilizzare tutte quelle cosette come
funzioni, variabili, etc. che purtroppo l'SQL non ti offre.


 funzioni, variabili, etc. che purtroppo l'SQL non ti offre.
No, SQL è un linguaggio semplicissimo e consiste in pochissime regole che
apprendi in un minuto.
Le query, se sei un bravo programmatore, non le scrivi ma le generi
automaticamente attraverso oggetti creati nel tuo linguaggio di
programmazione preferito.
Ciao

 
Ho letto tutti i punti che hai elencato e che tu consideri vantaggi del
sistema client/server. Io non li condivido ma evidentemente la pensiamo
troppo diversamente e abbiamo esperienze troppo diverse per cui meglio
terminare qui la discussione.
