Uncovering better ways of developing software
Processo al database server relazionale
Risposte a questa discussione
-
Permalink Risposto da Marco su -
Se vi siete persi questa sessione o se semplicemente volete farvi nuovamente grasse risate ecco il video!
Grazie ad Andrea Turchi per averlo ripreso :-)
-
Permalink Risposto da Erica Barbato su -
Purtroppo nn ho potuto seguire il processo perchè impegnata al workshop sul refactoring, ho appena visto il video e vorrei davvero complimentarmi per chi ha ideato ed implementato la sessione.
Per quanto riguarda il database relazionale, personalmente ritengo debba essere sollevato da ogni accusa ^_^, principalmente per i seguenti motivi:
->non esiste una reale alternativa (almeno che io sappia) al database relazionale, se pensiamo a progetti in cui le basi di dati sono così grandi ed impegnative da richiedere necessariamente le caratteristiche di indicizzazione, transazione, etc tipiche di un dbms. Considerato che l'approccio ad oggetti, i cosiddetti OORDBMS, non si sono imposti, non vedo altri reali alternative, considerato che gli ORM si appoggiano cmq ad un database relazionale.
->personalmente ritengo che le grandi accusate, le stored procedure, non siano da demonizzare a tutti i costi: nel caso ci sia la necessità di automatizzare processi semplici, privi o quasi di logica, delegare queste operazioni esclusivamente al db aiuta moltissimo a mantenere le performance basse. Ovviamente, ripeto, sto parlando di operazioni semplici, il primo esempio che mi viene in mente è la replicazione di informazioni tra isole di dati.
->per quanto riguarda il problema del versioning, beh nella mia ex-azienda tutti gli script per la creazione e l'aggiornamento della base di dati erano versionati.
Saluti,
Erica
-
Permalink Risposto da Riccardo Lemmi su -
Colpevoli il figlio, il padre e la società che continua ad usare tecnologie superate. :)
Lo sviluppatore non pensa in termini di tabelle ma di oggetti eppure ancora oggi si usano i DB relazionali per memorizzare i dati. Alcuni tentano la strada dell'ORM ma pochi si avventurano nel mondo del ODBMS puro.
È arrivato il momento di guardare avanti e fare scelte coraggiose: a morte i RDBMS :)
-
Permalink Risposto da uberto su -
esistesse un ODBMS conpetitivo in termini di performance/reliability/costs con Oracle o PosgresQL, lo userei subito.
Per usarlo in grossi progetti pero' dovrebbe avere anche un qualche meccanismo di compatibilita' (seppur piu' lento) per poter accedere i dati via sql, dato che non e' pensabilile di cambiare tutte le applicazioni in una volta unica.
-
Permalink Risposto da Riccardo Lemmi su
-
Ti farò una domanda provocatoria: ad oggi quali ODBMS hai usato e con quali risultati?
-
Permalink Risposto da Marco su
-
Nel lontano 2001 testammo sia Objectivity/DB sia ObjectStore (con Java) e decidemmo per quest'ultimo per una miriade di motivi che (tutti) ora non ricordo. Uno era decisamente che stava sotto al sito del Tour de France che faceva decine di migliaia di hits contemporanee e serviva anche streaming real-time. Non abbiamo avuto problemi di sorta a parte che costava (e immagino costi) tanto quanto Oracle :-D
-
Permalink Risposto da uberto su
-
L'unico che ho usato (e amato) e' stato quello di Zope.
Gli altri non sono neppure arrivato ad usarli perche' o costavano (vedi post di Marco) anche se io avevo visto Caché.
Quelli lgpl (sinceramente dopo 2 anni non mi ricordo i nomi) o erano ancora a livello di ultra beta o mancavano di feature essenziali.
Cmq se ci fossero e funzionassero penso che la gente li userebbe, quest'anno al Devoxx si e' parlato di quale potrebbe essere il futuro del db dopo il fallimento del ODBMS. E nessuno mi pare si sia alzato a protestare.
Quindi se conosci una gemma che funziona, stabile e gratuita (o cmq economica rispetto a Oracle)...
-
Permalink Risposto da Riccardo Lemmi su
-
Io uso da 7 anni lo ZODB.
Lo uso nel contesto Zope, non come ODBMS generico, ma si può usare separatamente.
Nei progetti web che ho gestito (soprattutto CMS) solo in alcuni casi ho scelto
un paradigma diverso per alcuni dati dell'applicazione (DB relazionale o files):
erano dati di tracciamento e venivano periodicamente analizzati e cancellati,
oppure erano generati da altre sorgenti.
Non ho mai avuto problemi di performance che non fossero superabili con il solo
cambio di configurazione della architettura HW e l'uso di ZEO per lo storage.
Per me è una gemma: funziona, è stabile, è gratuito ma soprattutto ha un comunità
open source dietro che ne gestisce il codice. Perchè non venga usato come sistema
separato mi sfugge, probabilmente la maggior parte delle persone pensa che debba
essere usato solo con Zope.
-
Permalink Risposto da uberto su
-
beh nel mio campo (app java enterprise) non esiste (che io sappia) un equivalente di ZODB. Altrimenti spingerei sicuramente per usarlo.
Di ZODB ho ottimi ricordi, per alcune cose penso che Zope sia ancora insuperato.
-
Permalink Risposto da Alberto Brandolini su -
C'è un elemento in comune con uno degli argomenti toccati dal mio intervento su Agile e SOA.
Per certi versi SOA rappresenta un'occasione sprecata: la libertà teoricamente conquistata sul fronte architetturale spostando l'integrazione a livello di servizi e non di dati, dovrebbe permettere anche di "sperimentare" su differenti tecnologie di persistenza nell'implementazione di un servizio, proprio perché vogliamo svincolarci dall'obbligo della retrocompatibilità che è e sarà sempre un fardello.
Però nessuno ne approfitta... :-(
-
Permalink Risposto da uberto su
-
Nessuno?
Direi che invece SOA/REST sia la cosa piu' promettente per il DB del futuro. Anche se e' ancora presto.
-
Permalink Risposto da Alberto Brandolini su
-
Hai ragione. "Nessuno" è sbagliato.
Quello che stavo cercando di dire, è che ragionando in un ottica a servizi, con una granularità differente rispetto alle applicazioni, la soluzione ottimale per un servizio potrebbe essere diversa da quella necessaria per un'applicazione. Il tutto con un potenziale incremento dell'eterogeneità complessiva (cosa che un po' spaventa).
Per tutta una serie di fattori (il costo delle licenze, che avete citato, è uno di quelli: se ho pagato per una cosa spesso la "devo" usare, comprare un'alternativa costosa spesso non è una strada percorribile) l'eterogeneità potenziale di tante soluzioni localmente (forse) ottime viene ridotta a favore di un quadro complessivo più uniforme. In cui tutte le applicazioni/servizi continuano ad assomigliarsi in un ottica di maggiore semplicità di gestione, spesso più organizzativa che tecnologica.
- ‹ Precedente
- 1
- 2
- Successivo ›
© 2012 Creato da Marco.
