Newsgroup: it.comp.software.database
Titolo: Database ad oggetti

Per quale motivo non sono diffusi ?
Perchè si sente parlare sempre di RDB e non ODB ?
Non dovrebbe essere più facile e produttivo usarli ?
scusate la domanda , forse stupida
ma non sono proprio del campo DB .
A.

...

Ci sono vari tipi di problemi:
- performance;
- difficolta' di implementazione;
Oracle e' sia ad oggetti che relazionale, questo implica qualche
problema concettuale nell'incapsulamento dei dati, d'altra parte
facilita molto le cose perche' si costruisce il database relazionale,
e sopra di questo si possono mappare degli oggetti con delle Object
Views, con dei metodi che richiamano procedure e package gia'
esistenti. Cosi' ognuno ci accede come gli pare e la base dati rimane
sempre la stessa.
Greetings,
Alessandro Trebbi
Pesaro, Italy
http://www.b3soft.com

scusate la domanda , forse stupida ma non sono proprio del campo DB .
Anche tu hai il diritto di capire.
Ciao!
jk

 ha scritto nel messaggio
news:3df7ac9a...@news.tin.it...
[CUT]
Ottima esposizione semplice e chiara.
Inoltre concordo con tutto.
    danilo

 
Penso, per esperienza personale, che il problema non sia nei 
programmatori, ma nella mentalità delle aziende di come implementano la 
struttura dati, per come sono organizzate e strutturate.
Piuttosto che pagare un buon programma, preferiscono pagare delle persone 
che inseriscono dati dalla mattina alla sera.
Un esempio, una grossa azienda di cucine, aveva nel database una distinta 
base con 1.500.000 records,e non riuscivano più a gestire la cosa.
Noi abbiamo proposto la gestione delle stesse informazioni con qualche 
migliaio di record su più tabelle utilizzando concetti di programazione 
ad oggetti.
Massimo
 

Non dovrebbe essere piů facile e produttivo usarli ?
Per quale motivo dovrebbe essere piu' facile usarli?
C'e' una vasta conoscenza teorica sui database relazionali.
Lasciare la strada vecchia per la nuova costa.
Per quale (presunto) vantaggio bisognerebbe pagare quel prezzo?
La programmazione ad oggetti puo' essere mappata "tranquillamente" su
un database relazionale, il viceversa e' piu' discutibile. Che poi
molti (troppi) pensino che per programmare ad oggetti serva che tutto
il mondo sia ad oggetti, e' un altra cosa.
Per programmare ad oggetti non e' nemmeno necessario avere un
linguaggio ad oggetti. Ma chi e' disposto ad ammetterlo.
(E poi che oggetti?, object oriented, o objeect based ??)
Anche se esiste la programmazione ad oggetti, "nessun" programmatore
(di solito n.d.p.) si preoccupa di fare programmi transazionali
(almeno se puo' evitarli). Il concetto di transazione e' "ovvio" nel
mondo dei DB relazionali, anche se <oggetti> come mySQL tendono a
passare oltre all'altare delle prestazioni.
Ti espongo due problemi banali, la cui risposta non ovvia ti fa capire
perche' non sarebbe cosi' semplice <pensare> ad oggetti nel mondo dei
dati.
La tabella X eredita la sua struttura da Y, e la amplia con i campi Z.
L'amministratore decide di estendere Y. Che succede a X?
L'eredita' deve essere statica (stile PostGress), o dinamica
(potenzialmente perniciosa se l'ampliamento e' pari a Z)?
Se io richiedo i dati di tipo Y, questi conterranno anche quelli di
tipo X partizionati secondo Y? Se la risposta e' no, perche' devo
usare un DBOO. Se e' si allora che cosa e' un dato <Y>?
Niente contro i DBOO, pero' non mi avventurerei ad affermare che sono
piu' semplici e piu' produttivi, se non dopo un paio di anno di uso
pratico. Non avendola io questa pratica, vedo quella degli altri. Non
ricordo articoli che mi abbiano colpito a favore della tesi della loro
<inevitabilita'>.
-- 
sito papero -> 
http://utenti.tripod.it/papero

lo strumento da utilizzare poi pensano all'applicazione.
Caspita! E come può essere il contrario? Per essere produttivo con un
linguaggio, lo devi conscere proprio bene e per conscerlo proprio bene ci
vogliono anni di studio e un mucchio di danaro. Essendo la programmazione ad
oggetti un modo di pensare e sviluppare il software, e non è esclusiva di un
linguaggio, allora non è necessario cambiare linguaggio ogni volta che si
presenta un problema. Lo posso accettare solo in casi eccezionali .Parlo in
generale di chi conosce per esempio solo uno o due linguaggi (generalmente un
linguaggio tradizonale come il Pascal, il C, il BASIC... e un linguaggio
"moderno" di scripting). Per esempio, si sa universalmente che il Prolog sia il
linguaggio d'eccellenza per lo sviluppo di applicazioni di intelligenza
artificiale ma la maggior parte delle applicazioni di A.I. è scritta in altri
linguaggi! E' importante capire il problema e come risolverlo; poi, *devi* usare
il linguaggio che conosci meglio e con il quale ti senti sicuro a portare il
progetto a termine nel rispetto del budget e dei tempi. Io sono *certo* che il
design del software sia la parte più importante nello sviluppo del software; per
il resto, normalmente, si usa il linguaggio che uno conosce meglio per non
rischiare brutte avventure.
Ciao!
jk

[cut]
ho tagliato praticamente tutto ;
io credo nella OOP ,
ho sviluppato software multimediali che senza la OOP sarebbero
assolutamente morti prima di nascere .
l'analisi serve proprio a farti prevedere cosa succedera' se ....
se non la fai , sei morto e la OOP è ovvio che produce danni ed
anche considerevoli .
quello che io mi chiedo , è :
1) ho un'esperienza di 4 mesi sull'analisi software
2) ho un'esperienza di 2 anni sulla OOP
ora voglio (visto che faccio anche analisi) considerare anche un
database ad oggetti :
perchè non devo farlo ?
a me rompe non poco le scatole fare analisi Object Oriented e poi
quando devo passare ad un RDB mi ritrovo che devo convertire
i miei oggetti in tabelle !
dovrei fare un lavoro di conversione molto maggiore ,
xo' vedo che nessun hosting mette a disposizione un ODB
tutti mettono Access , MySQL , SQL Server 7 .
e via dicendo ...
Arturo

 essi da altri oggetti devo creare dei meccanismi, spesso rocamboleschi.
Ma questo, onestamente, non lo vedo un limite del paradigma, ma
un'opportunità che questo offre al team di sviluppo, di istituire un set di
protocolli stabili, durevoli, replicabili di utilizzo di "mattonelle"
costitutive di un castello la cui complessità, per lo stesso intrinseco
significato di complessità, presto o tardi finisce per complicare
maledettamente un sistema al crescere delle sue dimensioni.
E poi, in ultimo ma non meno importante, nessun approccio procedurale, imho,
garantisce un costante e veloce controllo della tracciabilità delle
capabilities sui requisiti.
Ciao, Sandro.
--------------------------------
Inviato via 
http://usenet.libero.it

capabilities sui requisiti.
Queste nostre discussione simpatiche ed interessanti evidenziano due cose:
1. che il problema del software engineering non è stato sistematicamente risolto
ed è ancora pendente;
2. che noi cerchiamo di risolverlo con diversi metodi obiettivi/soggettivi, con
quello che abbiamo, con quello che sappiamo e che i nostri successi/insuccessi
nello sviluppo di software lo testimoniano. Sinceramente, io mi sono stancato di
pensare e cercare una soluzione definitiva perché sono certo che per ora non c'è
e non è nemmeno dietro l'angolo. Comunque, conoscere diversi linguaggi e diversi
paradigmi aiuto quando l'applicazione è complessa e necessita funzionalità in
campi diversi (accesso all'hardware, grafica, database...). Quindi, sviluppare
secondo un sistema ibrido con scatole grigge e scatole nere è una soluzione
valida (se non è l'unica). E' la soluzione adoperata anche dalla NASA nello
sviluppo delle sue applicazioni usando ADA insieme ad altri linguaggi e, che io
sappia, ha dato ottimi risultati (almeno così dicono). 
[OT]
Credo invece che uno dei grossi problemi dell'informatica, ancora non risolto,
sia quello dei formati dei dati (proprietari) portato fino all'esaperazione
dalla M$ ( e non solo); per es., se ti do un foglio Excel ti devo comunicare
anche la versione perché c'è il rischio, anche se possiede Excel (quindi lo
stesso programma), che il Excel non riesca ad aprire il file! Cioè, il noto
problema del versioning. Questo mi sembra un assurdo accettato e tollerato da
tutti. XML era una risposta, ma è stata molto simile alla risposta OOP nel campo
della programmazione; cioè, da una parte ha risolto, dall'altra ha complicato.
Molti vedono XML come il peggio del formato binario e quello testo. 
Scusate L'OT, ma io credo che questo è uno, almeno per me, dei problemi che
affliggono il mio software, e forse anche di tanti altri colleghi. Sarei proprio
contento di sapere come l'hanno risolto, o almeno, come l'hanno affrontato.
Ciao!
jk

 contento di sapere come l'hanno risolto, o almeno, come l'hanno
affrontato.
Mi associo. Perdonate l'OT. Ma il piatto era troppo ricco per rinunciare ad
entrarci ...


Ritengo il contributo di Jilani a questo ng sempre molto interessante.
Per riaccendere però il dibattito vorrei chiedere informazioni e pareri
sulle basi dati associative, mi sembra che ipotizzino una soluzione al
problema rigidezza della struttura, tipico della soluzione RDBMS, senza però
incorrere nelle scarse prestazzioni e complessità dei ODB o dei database
gerarchici.
M.Amati

 wrote in message 
news:SQ1N9.832$lj5....@tornado.fastwebnet.it...

Ciao Max,
cerca su 
http://www.dbdebunk.com
 per "Simon Williams", ci sono
un po' di articoli polemici tra Date, Pascal e Williams sul
modello associativo.
Oppure fai una ricerca per "associative model" con
http://groups.google.com
 nel newsgroup comp.databases.theory
se non ricordo male c'e' stata una discussione qualche tempo
fa.
Ciao,
-- 
Gianluca Hotz
Backoffice MVP (SQL Server) MCP SQL Server and MCP Windows
Vice-President of the Italian User Group for SQL Server
Founding Member of the Italian User Group for .NET
http://www.ghotz.com
http://www.ugiss.org