Newsgroup: it.comp.java
Titolo: che ne pensate di questa struttura dati ?

Salve a tutti,
sto scrivendo un programma (elaborazione risultati calcistici):
immagazino i dati in una struttura di questo tipo
http://forum.html.it/forum/showthread/t-1200955.html
ovvero una IndexedTreeMap <String, Squadra> map = IndexedTreeMap
<String, Squadra>();
A Voi come sembra questa struttura dati?
Di solito, nelle vostre applicazioni, usate sempre la solita struttura
dati con la quale vi trovate già bene.. magari è una struttura che
facilita la visione di tutti gli elementi che in essa avete inserito?
Mi piacerebbe vedere qualcuno dei vostri esempi.
Sul blog di sviluppo della mia applicazione posterò un esempio della
mia struttura..
http://dnaofwinners.wordpress.com/2008/05/23/esempio-di-prova-per-una-indextreemap/
Ciao

 AVoi come sembra questa struttura dati?
Personalmente non mi sembra nulla. Impossibile dire se una struttura dati 
sia adeguata senza sapere poi quali algoritmi  dovranno utilizzarla.
Scorpio.

> AVoi come sembra questa struttura dati?
Dovresti dire quando è utile.
Dovresti dire caratterizzare la velocità delle operazioni e 
dell'occupamento in termini di O(1), O(n), O(n^2) e così via.
Allora si potrebbe dire qualcosa.
Hai messo solo il codice dell'implementazione.
-- 
Andrea Francia
http://code.google.com/p/remoted-list/
 - Lazy loading lists through RMI.

Scorpio ha scritto:

Esatto...e direi che una vecchia citazione ci sta bene:
"... Programs, after all, are concrete formulations of abstract 
algorithms based on particular representations and structures of data. 
An outstanding contribution to bring order into the bewildering variety 
of terminology and concepts on data structures was made by Hoare through 
his Notes on Data Structuring [3]. It made clear that decisions about 
structuring data cannot be made without knowledge of the algorithms 
applied to the data and that, vice versa, the structure and choice of 
algorithms often depend strongly on the structure of the underlying 
data. In short, the subjects of program composition and data structures 
are inseparably interwined. ..." (N. Width, "Algorithms and Data 
Structures", 1985)
Cercando di portare la discussione su qualcosa di serio...io trovo che 
questo sia anche il motivo per cui spesso è assurdo progettare una base 
di dati, senza considerare come essa verrà usata.
E' ovvio che una base di dati dovrebbe essere qualcosa di più di un 
semplice contenitore di dati...ma troppo spesso invece è così. Quindi, 
di solito ci si fa solo del male a progettarla slegata dalla (spesso 
unica) applicazione che la userà.
Ciao
   Lucio
-- 
Lucio Benfante
JUG Padova           
http://www.parancoe.org
 ...have a look at it!
www.jugpadova.it
 
http://www.jugevents.org

Beh... :)
più che utile questa struttura è, in realtà, comoda; come si vede da
questo ciclo for che la scandisce:
for (int i = 0; i < map.size(); i++)
System.out.println ( map.get( i ) );
Posso accedere direttamente ad un elemento specifico in esso contenuta
tramite un indice numerico (che va da 0 a map.size()-1) oppure
indicando una chiave letteraria
map.get ("atalanta"); [    previo aver precedentemente inserito tale
voce: map.put("atalanta", new Squadra() );    ]
Comunque è molto giusto il consiglio che mi invita a "caratterizzare
la velocità delle operazioni e
dell'occupamento in termini di O(1), O(n), O(n^2)" purtroppo non idea
di come ciò si possa realizzare.
E' giustissima anche la nota che rileva come ogni struttura dati debba
essere ottimizzata per le operazioni richieste dal particolare
algoritmo di elaborazione (ogni applicazione ne ha uno fine a se
stessa).
Tuttavia io Vi chiedevo se solitamente usavate una struttura dati
affidabile e con 'affidabile' intendo che, nelle vostre esperienze,
avete osservato buoni tempi di risposta e parsimonia di risorse quando
viene adoperata nei più comuni utilizzi quali l'inserimento di un
nuono elemento, la ricerca, l'eliminazione, la ricerca di un
sottoinsieme... tutti metodi/caratteristiche che generalmente
ricompaiono in ogni nostro programma (ogni nostra apllicazione non è
mai identica a nessun'altra, se osservata dal punto di vista del
particolare dato che ella tratta, ma se la osserviamo interessandoci
solo alle operazioni più comuni -inserimento, ricerca, eliminazione,
ecc.. ecc.- allora Penso che potrebbe esistere una linea di pensiero
in grado di affermare quale struttura dati sia più conveniente, più
conveniente per queste operazioni più comuni).
E' un discorso molto generico e per questo Credo che si possa trovare
un significato comune solo se Vi va di postare qualcuno dei vostri
esempi, le strutture dati -se ce ne sono- che nella vostra esperienza
riconoscete di ri-utilizzare il più delle volte, quelle insomma che Vi
danno maggiori garanzie e maggior sicurezza in termini di gestione del
Vostro nuovo programma.
Grazie a tutti per i consigli, aspetto i vostri esempi..
..so che a volte è noioso postare parte dei propri codici, ma cosa c'è
di meglio nell'unire tutta la nostra Esperienza?? Di meglio esiste
appunto Creare una Nostra esperienza comune
:)

 Tuttavia io Vi chiedevo se solitamente usavate una struttura dati
[cut]
...a questo punto si può solo affermare che sei un po' duro di 
comprendonio. :)  (occhio alle faccine, niente flame, please)
Provo a ripetere il concetto che già altri hanno provato a farti capire: 
non esiste LA struttura dati ideale, ognuna dipende dalle operazioni che 
devi farci.
Classico è l'esempio di una lista (in Java, interfaccia List, per 
capirci). E' meglio usare un lista implementata con un array (ad esempio 
ArrayList) o un lista implementata con elementi collegati fra di loro 
(LinkedList)?
Dipende...da quali operazioni fai. Ad esempio se fai molti inserimenti 
una LinkedList va benissimo, mentre un'ArrayList fa schifo. Viceversa, 
se accedi spesso per indice, un'ArrayList avrà prestazioni fantastiche, 
mentre sarà la LinkedList a fare schifo. Intiendi? :)
Ogni struttura dati ha le proprie peculiarità e va usata dove serve, a 
seconda dell'algoritmo che si sta implementando.
Ciao
   Lucio
PS: non è un problema di postare codice. Mio codice in giro ne puoi 
trovare a iosa...e anche non mio...opensource, intiendi? :)


di dati, senza considerare come essa verrà usata.
Tremendamente vero. 
Una base dati può essere costruita in mille modi diversi per la stessa
applicazione e se ci si lascia andare ad un ragionamento troppo
astratto, l'architettura finale finirà per ingessare l'applicazione
che userà quei dati e toccherà, prima o poi, rivedere tutto in una
luce più "pratica". Quando si progetta una struttura dati (o una base
dati) non ci si può non chiedere come l'utente userà quei dati.

 facilita la visione di tutti gli elementi che in essa avete inserito?
"di solito" io sono abituato a lavorare con liste di bean o liste di 
map, perchè questo è il modo con cui i framework di persistenza e i 
framework mvc gestiscono i dati.
toglimi una curiosità: a parte giocare con i cicli for(), che te ne fai 
di quella classe?
-- 
 Fino all'anno scorso avevo un solo difetto. Ero presuntuoso.
http://softvalley.blogspot.com
http://www.flickr.com/photos/marko_po/

 di quella classe?
Non è che gioco :-) e mi diverto a guardare un ciclo for, ma nel mio
caso
in una di queste classi inserisco le coppie ( "data_della_partita",
Partita() )
e faccio questo per ogni squadra..
..poi scorro -con il ciclo for- queste mappe e...
1) vedo la somma dei goal fatti, subiti, l'andamento delle vittorie,
ecc.. ecc...
2) creo la classifica (con l'aiuto anche di una classe comparatore che
rispecchia i criteri di classifica per le diverse competizioni quali
la serie A, la serie B, la coppa dei campioni, ...)
3) vedo il susseguirsi dei risultati (prima di uno scontro diretto,
dopo un impegno nelle coppe europee, ...)
Come vedi il ciclo for mi permette di scorrere tutte le Partite,
acquisire i dati che mi interessano (goal, ammonizioni, falli, ...) ed
elaborarli a mio vantaggio
Conosci un modo migliore per ricercare un insieme di dati se non
quello di scorrere i dati stessi??
:)
Ciao

 quello di scorrere i dati stessi??
ti ho spiegato che i valori delle Map possono essere iterati senza 
bisogno di decorare ulteriormente. quindi la tua implementazione è 
*perfettamente* inutile.
questo è il succo del problema leggendo il tuo codice.
sulla rappresentazione dei dati non la descrivi quindi non c'è molto da 
dire. prova a dire come pensi di gestire la persistenza e la user 
interface, per vedere se ci si capisce.


Rootkit
dici "questo è il succo del problema", ma io non postato nessun
problema, ho chiesto solo se di solito usavate sempre una stessa
struttura dati nei vostri programmi
:)
per quanto riguarda persistenza ed user interface, siccome non so cosa
siano, non posso risponderTi nulla, mi spiace
:)
Ciao

siano, 
Stai scherzando, vero?

Quando leggo "persistenza" ed "user interface" penso alla 'persistenza
dei dati' (che non so bene cosa sia) e alle interfacce (tipo
comparable)... di più non Mi sovviene null'altro.
Ogni risposta che mi avete dato mi ha convinto sul fatto che non
esista una s.d. buona per tutte le esigenze, ma va calibrata sul
maggiore uso che ne faremo (inserimenti, letture, ...)
La notazione O(n) è una utile informazione per valutare quanto la
nostra s.d. sia calibrata sulle nostre esigenze, ma non ho idea di
come si calcoli O(n).
Creo programmi per imparare ad apprendere anche questi nuovi -per me-
concetti che Voi mi nominate.
Al momento creo programmi che funzionano, per migliorarmi di un
gradino in più devo solo acquisire la padronanza di comprendere con
quanta efficacia essi funzionino..
..il risultato esatto, infatti ho visto, è sempre l'ultima
preoccupazione del programmatore.

 Tremendamente vero.
Se ti riferisci a una base dati, "tremendamente opinabile".
Una base dati ha le sua famose regole di normalizzazione e dovrebbe 
soddisfare passato, presente e futuro per tutte le possibili 
applicazioni che ci si vogliano basare.
Un contenitore dati invece puo' essere specchiato sull'uso che se ne 
vuole fare e non a caso il linguaggio in NG si e' inventato una serie di 
strutture per la "rimanipolazione" dei dati.
Faccio un esempio banale. Poiche' la mia applicazione richiede che 
vengano esposti gli stipendi di un anno su una sola riga (foglio excel 
per intenderci) dovrei fare una tabella con tredici colonne importo 
(ammettendo che si arrivi solo alla tredicesima)?
Che siano "interwined" come afferma Hoare e' sicuramente calzante ma 
personalmente non mi sognerei mai di disegnare una base dati secondo 
l'esempio che ho fatto. E potrei fare di peggio infilando in un solo 
attributo stringhe delimitate o dati non omogenei a motivo del fatto che 
la mia applicazione lo richiede?
Mi scuso per l'intromissione.
Se  poi non ho afferrato il nucleo del contendere mi scuso doppiamente.
-- 
ac
y-1=x

 siano, non posso risponderTi nulla, mi spiace
pazienza, sarà per un'altra volta.


 zozzerie del genere non le scrivo.
Non c'e' bisogno di offendere.


 vuole fare
Mi sembra il minimo che  chi progetta la base di dati (che ricordo 
essere un dettaglio implementativo) tenga in considerazione le query SQL 
che andranno fatte sulla stessa.
Altrimenti finirai, ad esempio, per eseguire join inutili, e tu sai 
quanto possono essere problematiche.
Essendo un dettaglio implementativo va ottimizzato, se possibile.
Questo per quanto riguarda le performance...

Dopo una serata spesa (sono le ore 1:37) a vedere in sequenza
Highlander 3 ed Highlander 4 mi sovviene l'aver acquisito con
chiarezza che vi è una CERTA :) differenza tra una base di dati ed un
contenitore di dati (cosa che fino ad oggi Io ignoravo)
Grazie ad Alessandro Cara per questa utile puntualizzazione, mi
consentirà in futuro di riservare maggiore attenzione agli aspetti
pratici delle mie programmazioni tralasciando ricerche per ideali
strutture "buone per tutte le stagioni": alla fine conta sapere come
ottenere il risultato, prima viene l'algoritmo e poi la s.d. (in caso
contrario, se la s.d. fosse stata più importante dell'elaborazione
allora ci saremmo trovati Tutti a discuterne su it.comp.C o C++)
Ringrazio ancora Lucio Benfante per avermi aperto uno spiraglio sulle
diffrenze tra ArrayList & LinkedList nelle operazioni di inseriemento/
recupero..
..se qualcuno di Voi sa dove reperire queste ed altre annotazioni
sulla praticità di queste strutture Lo prego di postare qui il link di
tale risorsa.
Saluti
e
Buona Domenica
e
un
caloroso augurio di Buona Guarigione
ad
Agave
che certo domani passerà a leggere queste Mie parole
:)

l'esempio che ho fatto. 
Mi sa che non hai capito bene che cosa intendeva Hoare. Il suo
discorso non pregiudica affatto la creazione di una base dati
normalizzata (se poi i record di dettaglio saranno solo tredici č una
"constraint" applicativa). Se il modello dei dati risponde in modo
agevole al flusso dell'applicazione, non ci sono problemi. D'altronde
non sta scritto da nessuna parte (né un genio come Hoare si sognerebbe
mai di dirlo) che la memorizzazione dei dati deve rispecchiare la
rappresentazione degli stessi. Al tempo stesso (vedi sopra) non č
possibile tirare giů un'architettura dati se non si sa bene come
verranno utilizzati. 

essere un dettaglio implementativo)
Che intendi dire con "dettaglio implementativo"?
Per me la base dati è il punto di partenza, altro che dettaglio!

allora ci saremmo trovati Tutti a discuterne su it.comp.C o C++)
?????????????????????????????????????

come si calcoli O(n).
Ti consiglio un buon libro sugli algoritmi.
"Introductions to Algorithms" di Cormen, Leiserson, Rivest, Stein,
ancorché farcito di matematica, è un buon punto di partenza.

 Questo per quanto riguarda le performance...
Le performance decadono quando la base dati non e' normalizzata o 
indicizzata secondo "ragione" o quando, come ho visto fare, si 
preferisce fare mille(*) select che restituiscono una sola riga a fronte 
di una sola select che restituisce mille righe.
(*) ho scritto mille ma ho visto di molto peggio
-- 
ac
y-1=x

Non c'e' bisogno di offendere.
"Offendere"?
Non vedo nessuna offesa e rootkit ha ragione: il subject richiede una
risposta e se la risposta č "una zozzeria", non c'č nulla per cui
sentirsi offesi.

 verranno utilizzati. 
non ti prendero' mai in considerazione come "disegnatore" di basi dati.
Ogni attributo ha dominio e relazioni. Se nel disegno vengono 
correttamente metabolizzate qualsiasi applicazione ne potra' fare uso
E mi sbilancio, uso "ottimizzato", perche' i dbms riescono ad essere 
"very clever". E.....ogni volta che mi e' successo di "trasgredire" le 
regole la ho pagata caramente (non si accettano boutades) alla succesiva 
richiesta del "ma sarebbe necessario fare anche..."
-- 
ac
y-1=x

 sappia dare un significato. Mai sentito parlare di GUI? 
ed io che avevo scambiato il tutto per ironia.
Ma pensa te!
comunque GUI e' stato ministro della repubblica italiana mi sembra negli 
anni sessanta.
Giordano mi sembra una persona molto equilibrata ed educata al contrario 
di "someone else",  ovviamente, come si suol dire, esclusi i presenti.
-- 
ac
y-1=x

<< Alla fine ne resterà soltanto uno >>

 << Alla fine ne resterà soltanto uno >>
Io sto alle prese, invece, con stargate (la serie TV)
Attento a tutti i Go'auld che ci sono in giro.
;<)
-- 
ac
y-1=x

:)
http://it.wikipedia.org/wiki/Luigi_Gui
con
un'occhiata anche su
http://it.wikipedia.org/wiki/Scandalo_Lockheed
Grazie a tutti i partecipanti,
grazie ad Alessandro Cara,
"grassie" as Agave
io ora mi <<vaddormo>> (che sta per: vado a dormire)

Andrea Laforgia ha scritto:

Beh diciamo che e' un importantissimo dettaglio anche se implementativo ;)
Punto di partenza? Io ho letto che sarebbe un errore partire dalla base 
di dati nella progettazione. Vediamo se lo trovo...Per ora no!
Comunque se non erro si parlava del impedance mismatch tra il paradigma 
relazione e quello orientato agli oggetti. Partendo dal database si 
tenderebbe a rovinare il secondo. Mentre se progetti il datamodel e poi 
in un secondo momemento, solo quando devi occuparti di persistenza, 
implementi il database allora non rischi di trovarti con oggetti se 
sembrano tabelle.
Quindi il database e' un dettaglio implementativo perche' mentre il 
dominio ad oggetti e' fissato su carta (progettato) il database deve 
riflettere questo ultimo per quanto riguarda la persistenza...e puo' 
farlo in diversi modi.
A dire il vero non credo che sia un errore fare l'inverso, a meno che lo 
sviluppatore non sia alle prima armi (e sappiano che non e' il tuo caso!).

 di una sola select che restituisce mille righe.
Si vede che le basi di dati sono le uniche cose al mondo che seguono 
questa legge marziana, perche' qualsiasi altra cosa a questo mondo 
(difficile) richiede analisi e soluzioni contestualizzate (vedi 
strutture dati).
Noi che abbiamo i piedi ben saldi per terra siappiamo che 3,4 join 
possono portare a tempi inacettabili di esecuzione. Questo si traduce in 
  una totale inutilita' del tuo perfetto schema perche' l'utente del 
sistema non usera' mai una simile applicazione.
Denormalizzando spesso si rientra dentro tempi accettabili. Fine del 
discorso. L'utente potra' ora utilizzare l'applicazione. Hai sporcato lo 
schema? A non lui interessa.
Negare cio' significa vivere su marte.
Per tenere sotto controllo l'applicazione si posssono utilizzare 
tecniche di testing e una buona programmazione per ridurre al minimo la 
possibilita' di finire ko causa ridondanza dei dati.

 sentirsi offesi.
Probabilmente abbiamo due opinioni diverse sul concetto di buona educazione.


 possibilita' di finire ko causa ridondanza dei dati.
Hai detto un paio di cose che sarebbe veramente difficile confutare.
Tali cose sono comunque valide, ridondanza di dati o meno.
Se pero' i dati non sono ridondanti, nel rispetto di tutto cio'  che hai 
detto,  e' meglio. ;<)
-- 
ac
y-1=x

 educazione.
probabilmente se davi un'occhiata al thread vedevi che ho argomentato 
dal punto di vista tecnico, almeno finchè l'interlocutore non ha 
ciurlato nel manico (o forse finchè non me ne sono accorto).
e con un po' di attenzione vedevi anche che non ho offeso nessuno. 
qualsiasi commento era sul codice, come d'altronde aveva chiesto. per 
quanto mi riguarda potrebbe essere gavin king sotto mentite (parecchio) 
spoglie.


 spoglie.
Mi sono pentito di aver scritto questo messaggio appena dopo averlo 
mandato.
Non voglio parlare di etichetta e buona educazione e vorrei tornare a 
parlare di Java.
Alla prossima....


 
La base dati è certamente importante ma è un prodotto dell'analisi, non 
è quasi mai un punto di partenza se si realizza un sistema ex-novo e se 
si sviluppa utilizzando processi moderni.
Di norma si parte con un domain model, ovvero una modello che 
rappresenti il dominio del problema, e da quello si realizza da un lato, 
con la progettazione E-R, il database, dall'altro, con la modellazione 
O-O, il modello di analisi, di design, e l'implementazione, normalmente 
iterando molto all'interno di questo ciclo (non sono fasi separate, 
frequente è il caso in cui si modifichi il domain-model e di conseguenza 
si vada a modificare gli altri modelli, E-R e O-O).
Un processo che ultimamente sto apprezzando e che punta molto sul domain 
model è DDD. Per chi non lo conosce:
http://www.infoq.com/minibooks/domain-driven-design-quickly
(il libro è meglio, ma questa è un intro veloce)
In alcuni casi estremi (ehm... il mio) il DB viene considerato 
semplicemente un bidone (e non è la prima volta che lo dico :D) cui si 
accede semplicemente per ripristinare degli oggetti temporaneamente 
eliminati dalla memoria.
Ciao,
     Bruno
P.S.
Occhio ai meeting del JUG Torino!
http://www.jugtorino.it/meeting
-- 
| Bruno Bossola
| A Java Software Engineer :-)
| 
http://www.jugtorino.it/bbossola
| Coordinatore del JUG Torino - 
http://www.jugtorino.it

 correttamente metabolizzate qualsiasi applicazione ne potra' fare uso
Non capisco proprio che cosa vuoi dire e in che modo questi (banali)
concetti contrastino l'innegabile verità che il disegno di una base dati
non può essere fatto ignorando l'uso che di quei dati si farà. Questo può
confermartelo chiunque abbia un minimo di esperienza nella progettazione
di basi dati. Ovviamente tutta gente che tu ti guarderai bene dal prendere
in considerazione. Adios.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 Probabilmente abbiamo due opinioni diverse sul concetto di buona educazione.
Non mi sembra proprio che rootkit sia stato maleducato. Probabilmente sei
un po' troppo sensibilotto.


 Giordano mi sembra una persona molto equilibrata ed educata 
Mi fa piacere per lui. Se sapesse anche fare le domande in modo corretto,
in modo da sembrare meno troll, sarebbe perfetto.


 semplicemente un bidone
Questi casi, a mio avviso, devono essere estremamente estremi. Tanto
estremi che dubito li raggiungerò mai ;-)


 Non mi sembra proprio che rootkit sia stato maleducato. 
Come ho detto: abbiamo due opinioni diverse a riguardo.
-- 
Andrea Francia
http://www.andreafrancia.it/

 sviluppatore non sia alle prima armi (e sappiano che non e' il tuo caso!).
Cioè fammi capire: non credi sia un errore perché io faccio così? :-P
Quello che posso garantirti è che io ho progettato decine di sistemi
software assumendo la progettazione dei dati come un punto di partenza e
mi sono sempre trovato benissimo. Anche i clienti pensano che quei sistemi
non siano poi così malaccio ;-)


 
E' possibile :) ma non te lo auguro.


 
Ma infatti. Pero' una cosa e' partire dalla base di dati con una buona 
idea di quello che e' il dominio applicativo, un'altra e' partire alla 
cieca.
Se si mette su carta il dominio e poi si fa il resto, magari *alcuni* 
non avrebbero fatto certe schifezze.

 (non che questo certifichi la bonta' di un'affermazione).
Se uno deve partire da qualcosa quella cosa sono i requisiti.
La base dati si progetta sulla base dei dati che deve rappresentare, 
delle operazioni che deve supportare e sulle prestazioni richieste per 
le operazioni.
Un conto č la progettazione della base dati un conto e la modellazione 
dei dati.
Nella progettazione strutturata il modello dei dati riveste una grande 
importanza ed č sicuramente fatto prima di altre cose come fa Andrea 
Laforgia.
La progettazione della base dati puo' essere fatta un po' piu' tardi 
come sembra suggerire Bruno.
Anche nelle metodologie OOP si pensa prima a rappresentare il dominio e 
poi a progettare come deve essere memorizzato.
Forse Andrea Laforgia usa come modello del dominio il modello della base 
dei dati.


 "Cara" sennň si spiega tutto :-P
Le nullita', in genere, non si prendono in considerazione ne si citano, 
"smailino" o meno.
Eccezione "Carneade".
-- 
ac
y-1=x

 se non sei d'accordo) un punto di partenza. 
non sarei proprio d'accordo. ma devo ammettere che nei fatti è così: io 
pagherei per progettare le entità java e da quelle generare il database, 
peccato che mi trovi sempre davanti quello che apre e.r/power designer e 
si mette propedeuticamente a disegnare le tabelle, altrimenti lo 
licenziano per palese inutilità... :)
che poi alla fine l'unica differenza fra i due metodi sono i nomi delle 
colonne: l'architect di solito ci pensa una settimana prima di sfornare 
una serie di acronimi che lui definisce "mnemonici" ma che fai prima a 
impararti tre o quattro canti della divina commedia.


 licenziano per palese inutilità... :)
Ma gli ORM non li usa nessuno da queste parti?
-- 
Andrea Francia
http://andreafrancia.blogspot.com/

 Ma gli ORM non li usa nessuno da queste parti?
sicuramente si, ma non (nel mio caso) per generare il database.
semplicemente si mappano tabelle e relazioni già esistenti.


 eliminati dalla memoria.
E le relazioni tra gli oggetti non le memorizzi nel database?


 semplicemente si mappano tabelle e relazioni già esistenti.
Nel senso che nelle applicazioni su cui lavori il database esiste già?
Non usi un ORM perché non ne hai sentito la necessità o perché ci hai 
pensato ma alla fine hai deciso di non farlo?


 pensato ma alla fine hai deciso di non farlo?
non mi sono spiegato.
uso un orm (hibernate, per la precisione) ma di norma le entità
mappano tabelle già esistenti. ovvero le tabelle fisiche vengono
progettate prima a parte e io creo le entità di conseguenza. si tratta
in genere di una questione di responsabilità: dai clienti la norma è
che ci sia un referente responsabile del database con il quale occorre
concordare la struttura. sono conscio che per l'economia del programma
sarebbe meglio fare a rovescio, ma vaglielo a spiegare.


Quindi c'e' uno che fa il lavoro inutile di disegnare le tabelle a mano 
e poi tu usi l'ORM per mappare le tabelle sulle classi che rappresentano 
il domain model?


 
Le collaborazioni che avvengono fra gli oggetti a runtime, che di fatto 
implementano la business logic, sono inesprimibili su un database
Se intendi invece le relazioni fra le classi queste possono risultare 
mappate oppure no. Nella mia esperienza il modello ad oggetti è 
normalmente diverso dal modello entità-relazioni, l'unica cosa che hanno 
in comune è l'astrazione definita dal modello di dominio. Certo, ci 
saranno alcune relazioni statiche (aggregazioni o composizioni) che è 
possibile ritrovare sul database, ma solo perché evidentemente 
rappresentano relazioni cosi forti da risultare in entrambi i modelli.


 
http://digilander.libero.it/pnavato/articoli/OOADP.html
Lo guardo, grazie del link.


 
My fault, il thread mi appare un po' confuso e il tempo a disposizione 
sempre troppo poco (devo decisamente dire due parole a fastweb, non è la 
prima volta che mi capita qui su ili dove c'e' un po' di traffico)
Anyway, next time, puoi dirmelo mettendo almeno una faccina? 
Risulterebbe meno offensivo :)


 Risulterebbe meno offensivo :)
Scusa hai ragione.
