Newsgroup: it.comp.software.database
Titolo: dbms NoSQL

Ciao a tutti
Recentemente anche su questo NG si e` parlato delle recenti
novita` di NoSQL, cloud computing, db chiave/valore etc;
segnalo qualche articolo interessante:
Partendo da un connazionale che sta sviluppando un nuovo dbms:
http://www.programmazione.it/index.php?entity=eitem&idItem=44313
l'articolo ripete la solita profezia di sventura, ossia che i
dbms relazionali saranno sostituiti a causa delle
"discordanze" tra linguaggio di programmazione e modello
relazionale. Vorrei ricordare a grandi linee alcuni fatti:
1 - all'inizio i dbms erano gerarchici o reticolari (gerarchie,
puntatori, difficolta` di query etc): manutenzione complessa
2 - Codd introdusse il modello relazionale per risolvere quei
problemi
3 - gigantesco successo commerciale tramite l'SQL (benche'
spesso criticato)
[OOP]
4 - introduzione del paradigma Object Oriented in programmazione
5 - gigantesco successo commerciale tramite il C++ (benche'
spesso criticato)
6 - siccome "everything is an object", c'e` bisogno di
sostituire i "vecchi" dbms relazionali
7 - introduzione del "modello ad oggetti"; i sostenitori del
modello relazionale fanno notare che si reintroducono gli
stessi problemi iniziali
8 - creazione dei primi Object dbms: prestazioni stellari in
determinate query, recensioni entusiastiche, iniziale euforia
9 - l'adozione in produzione rivela problemi tra cui
manutenzione complessa, difficolta` di query
10- sostanziale insuccesso degli Odbms; siccome la popolarita`
dell'OO in programmazione e` ancora grande, si ripiega su una
soluzione ibrida, uno strato software aggiuntivo denominato
Object-Relational Mapping (ORM), deputato a far dialogare
linguaggi e rdbms: soluzione che causa una maggiore complessita`
[XML]
11- introduzione dell'XML come formato di dati; gigantesco
successo commerciale
12- siccome "everything is a document", c'e` bisogno di
sostituire i "vecchi" dbms relazionali
13- introduzione del "modello XML"; i sostenitori del
modello relazionale fanno notare che si reintroducono gli
stessi problemi iniziali
14- creazione dei primi XML-dbms: prestazioni stellari in
determinate query, recensioni entusiastiche, iniziale euforia
15- i primi prototipi rivelano problemi tra cui manutenzione
complessa, difficolta` di query
16- sostanziale insuccesso degli XML-dbms; siccome la popolarita`
dell'XML come formato di dati e` ancora grande, si ripiega su
una soluzione ibrida (conversione in import-export)
[Cloud]
17- gigantesco successo commerciale del "Web 2.0": c'e`
bisogno di sostituire i "vecchi" dbms relazionali
18- introduzione del "modello" key/value, NoSQL, ACID-less; i
sostenitori del modello relazionale fanno notare che si
reintroducono alcuni degli stessi problemi gia' visti
19- creazione dei primi Cloud dbms: prestazioni stellari in
determinate query, recensioni entusiastiche, iniziale euforia
20- (oggigiorno) adozione in produzione: $megaVenditorediLibri,
dopo un annetto di cloud puro, propone una soluzione
Cloud/Relazionale basata su MySQL; $motoronediRicerca
dopo un po' di ACID-less, aggiunge in opzione le transazioni;
sull'interpretazione di questi fatti, e` ancora presto per
trarre conclusioni...
Volevo soprattutto far notare che la storia ha un alto tasso
di ripetizione, e che il settore informatico talvolta sembra
piu` trascinato dalle mode commerciali che dal raziocinio.
Altri post interessanti:
Un articolo che fa notare che i problemi in realta' risiedono
nell'SQL e in specifici dbms, non nel modello relazionale
di per se':
"Scalability and the Relational Model"
http://thoughts.j-davis.com/2010/03/07/scalability-and-the-relational-model/#more-242
Se avete altre cose interessanti postate i link thanks.... 

 di per se':
Condivisibile e realistico in parte. C'e` pero` da dire che non tutti i 
problemi si possono risolvere seguendo un modello relazionale, vuoi per 
questioni di complessita` (e qui rientra il discorso delle limitazioni del 
linguaggio SQL), sia per questioni di efficienza (e.g. un modello 
gerarchico, disegnato su di un database che supporta un modello relazionale, 
risulta meno efficiente rispetto allo stesso modello gerarchico disegnato su 
di un database che supporti tale modello). Da questo punto, ben vengano le 
varie alternative presentate, a patto che vengano utilizzate nei rispettivi 
ambiti di appartenenza
Enrico
P.S. in tutto questo, ancora non ho trovato un motivo per usare un database 
noSQL in un progetto

 database che supporti tale modello).
Certo, infatti il modello relazionale ha un suo "campo ottimale"
dentro al quale funziona bene, sopra al quale risulta sforzato,
e sotto al quale sembra un cannone che ammazza una zanzara.
Parlando di campi di applicazione, l'argomento si puo'
generalizzare dicendo che "dato un certo modello di dati non
relazionale, si puo' sempre scrivere un dbms ad hoc che andra`
piu` veloce"; ok giusto, ma semplicemente non c'e` partita.
La sfida storica infatti era usare entrambi i motori
per tutti i modelli (il che e` una situazione pratica
maggiormente comune); e` in questo che il modello relazionale
si e` dimostrato vincente.
Motori di database specializzati per determinati settori
ci sono sempre stati (inclusi i Very Large Data Base non
relazionali), solo che ora l'internet e` cresciuto
in maniera esplosiva tale da rendere esasperato il bisogno
di prestazioni; questo ha reso vantaggioso riscrivere da
zero i dbms (anche dal punto di vista economico).

 [OOP]
mettiamoci sopra le scelte di come fare la/le tabelle
quello che ci vorrebbe e' prestazioni e semplicita'
se una cosa e' semplice va piu veloce di un accrocchio
io sento la mancanza di un _database per filmati_
cioe indicizzare le schene o singoli fotogrami in un db
prendiamo avatar (visto che lo ha visto mezzo mondo)
scene iniziali:
vorrei metterci un indice con giove, o quando appare
l'attore la possibilita di indicizzare il contenuto
gli ogetti e altre cose
la stessa cosa con l'audio....
non c'e' un database "video" vale anche con le immagini
prendiamo la pubblicita della coca indicizzare la bottiglia di coca
della pepsi i 2 camion e la stazione di servizio
qualora cerco la stazione di servizio mi deve trovare i frame
dove si vede la cosa sia essa la pubblicita o un video
divertitevi :)
non mettere le informazini ma l'immagine come informazione

 divertitevi :)
E` il concetto di tag tanto caro al web 2.0 . Implementarlo su di un video 
non mi sembra per nulla complesso. Ad esempio:
Tabella Film:
| Nome   | Durata | Regia         | Hash   |
| Avatar |    162 | James Cameron | {SHA1} |
Tabella Tag_film:
| Nome_film | Minuto | Tag                 | Campo |
| Avatar    |      1 | Risveglio           |   256 |
| Avatar    |      1 | Attore protagonista |   256 |
| Avatar    |      2 | Astronave           |   123 |
E cosi` via. Il problemi, pero`, sono altri:
 - Ci vuole una mole di data entry che risulta ostico anche al cinefilo piu`
   incallito (anche con un applicativo apposito ci vorrebbero una o piu` 
   visioni solo per vedere cosa e` presente in ogni singola scena).
 - L'estrazione dei dati rimane la parte piu` onerosa del processo. Per
   riprendere l'esempio, una query SQL che estrae tutti i tag del primo
   minuto richiede una JOIN tra due tabelle, con conseguenti problemi
   relativi ad indicizzazioni varie.
I database document-oriented (di cui Redis fa parte) sono indirizzati 
proprio a risolvere il secondo problema, senza pero` doversi scontrare con 
il modello relazionale e garantendo una velocita` di esecuzione maggiore. 
L'unica accortezza, come dicevo anche nell'altro messaggio, e` di non 
pensare a tali tecnologie come la panacea di tutti i mali
Enrico

 per tutti i modelli
Personalmente non sono d'accordo, in quanto faccio parte della filosofia 
"uno strumento va utilizzato nell'ambito applicativo di appartenenza" :)
Enrico

"Enrico 'Henryx' Bianchi"

Si anch'io per quel che vale, solo che in azienda si tende ad
usare meno prodotti possibile per semplificasi la vita.
Inoltre c'e` da dire che siccome il modello relazionale non
incorpora alcuna specificazione di engine, nulla ti vieta di
semplicemente inglobare quell'altro :-)
Si e` fatto cosi' per il datawarehouse o i GIS, ad esempio.

 cioe indicizzare le schene o singoli fotogrami in un db
Non preoccuparti, e` solo questione di tempo... gia` ora
per 1.200 euro ti puoi comperare un server di videosorveglianza
che fa:
- riconoscimento facciale (con annesso database popolato in
automatico) e delle targhe auto
- data/ora/direzione/velocita` di transito
- impostare allarmi se la persona X si avvicina alla persona Y
- impostare allarmi se la persona sta in posto determinato oltre
una certa ora o esce dall'ufficio in anticipo
- quante volte la persona X appare assieme alla persona Y
Per il riconoscimento di singoli oggetti (trovare dove l'attore
X tiene in mano una lattina di birra) ci vorra` ancora un po';
gia` adesso Google ha un servizio sperimentale che data una foto
fatta col cellulare, ti fa una ricerca web per somiglianze.

 usare meno prodotti possibile per semplificasi la vita.
Vorrei darti ragione, se non fosse che nella mia rete aziendale mi ritrovo a 
dover gestire x Oracle, y SQL Server (da notare che per quest'ultimo sono 
divenuto il riferimento aziendale), un paio di MySQL, PostgreSQL...
Tutto questo senza contare LDAP ed il nuovo arrivato, SADAS :/
Enrico