IBM sfoggia un database alle vitamine

Preparandosi al rilascio della prima versione beta del suo nuovo dabatase, Big Blue snocciola alcune delle nuove caratteristiche di DB2: tra queste, il supporto ai dati XML

Atlanta (USA) - Anticipando di poche settimane l'avvio del beta testing del prodotto, IBM ha svelato nuovi dettagli sulla prossima major release del suo noto database di classe enterprise DB2. Anche nota con il nome in codice di Viper, la prossima versione di DB2 includerà per la prima volta funzionalità per la gestione dei dati XML.

In particolare, IBM sostiene che il nuovo motore del proprio DBMS sarà capace di fondere in maniera trasparente i dati relazionali classici con i dati XML senza dover operare una nuova formattazione di questi ultimi o doverli inserire all'interno di oggetti di grandi dimensioni residenti nel database. Questa caratteristica promette di rendere l'accesso alle informazioni più efficiente e flessibile e, nel contempo, di ridurre i costi associati alle attuali tecniche di data management. IBM afferma poi che Viper ridurrà la complessità e il tempo necessario a uno sviluppatore per creare applicazioni capaci di accedere simultaneamente a repository di dati sia relazionali che XML.

"DB2 Viper modificherà sostanzialmente le regole del gioco della gestione di un database", ha dichiarato l'azienda. "Con Viper al cuore delle loro infrastrutture informatiche, i clienti potranno rapidamente evolvere da attività tradizionali di data management a rivoluzionarie tecniche di gestione delle informazioni che consentiranno di sfruttare le informazioni come un servizio".
Le funzionalità XML native di Viper andranno a sposare le cosiddette Service-Oriented Architecture (SOA), che offrono la possibilità di accedere a enormi quantità di dati memorizzati in formati differenti.

Secondo IBM, DB2 Viper sarà anche il primo database a supportare simultaneamente tutti i tre metodi più comuni di partitioning dei database: range partitioning, clustering multidimensionale e hashing. Questo, a detta del colosso, permetterà alle aziende di organizzare e ordinare le informazioni in modo più adatto alle proprie esigenze.

La tecnologia XML nativa di Viper integrerà anche il supporto di XQuery, un nuovo linguaggio standard che estende XPath ed è appositamente progettato per trattare dati XML. Le applicazioni potranno usare XQuery, SQL o entrambi gli standard per recuperare documenti memorizzati con uno o entrambi i formati.

IBM ha infine confermato che prevede di estendere il supporto iniziale di Viper alla comunità di sviluppatori PHP utilizzando Zend Core for IBM. Clienti, sviluppatori e partner possono iscriversi al programma beta di DB2 Viper qui.
TAG: sw
21 Commenti alla Notizia IBM sfoggia un database alle vitamine
Ordina
  • Dai che le vitamine fanno bene : rinforzano il codice !   ;)    A bocca aperta
    non+autenticato

  • Diciamo che è compreso nel prezzo. Anche in DB2 è così comunque.

    P.S.: mi piace l'articolo linkato (e anche SQL 2005)
    non+autenticato
  • Con db2 sarà compreso nel prezzo, SqlServer 2005 express è gratuito.

    - Scritto da: Anonimo
    >
    > Diciamo che è compreso nel prezzo. Anche in DB2 è
    > così comunque.
    >
    > P.S.: mi piace l'articolo linkato (e anche SQL
    > 2005)
    non+autenticato
  • >SqlServer 2005 express è gratuito.

    Sì, ma ci fai DB piccoli piccoli. Appena crescono devi pagare lo stesso....
    non+autenticato
  • Oracle lo fa da tre versioni....
    non+autenticato

  • - Scritto da: Anonimo
    > http://www.dotnethell.it/articles/SQL-Server-2005-

    L'unica cosa che fa sql server è cagare.
    non+autenticato

  • - Scritto da: Anonimo
    >
    > - Scritto da: Anonimo
    > >
    > http://www.dotnethell.it/articles/SQL-Server-2005-
    >
    > L'unica cosa che fa sql server è cagare.


    Prego, motiva un pò questa rispostaOcchiolino
    non+autenticato
  • Ti sfugge che DB2 gestisce decine di TB di dati senza particolari problemi.
    non+autenticato
  • Anche SQL Server.
    In entrambi casi per arrivare a quei limiti bisogna sapere come fare. Non basta riempire un DB di qualche tera e pregare come vedo spesso Occhiolino
    non+autenticato
  • Che p***e questo XML, ma serve veramente?
    Voglio dire, capisco quando bisogna usare un formato per far comunicare differenti sistemi fra di loro (penso ai web service). Però basta!
    Attualmente si vede usare XML anche per file di configurazione e per formati di file tipo documento (vedi ODF). Secondo me dovrebbe essere usato SOLTANTO come formato per messaggi.
    Ora non voglio essere polemico (sono bugiardoCon la lingua fuori ) ma memorizzare documenti XML direttamente in un DB è una vaccata. Infatti ogni volta che bisogna estrarre dei dati "veri" dai documenti bisogna parsarli, e viceversa quando si vogliono trasformare i dati veri in XML bisogna serializzarli, sono costi non da poco.
    Secondo me bisognerebbe spingere verso DBMS ad oggetti che mi sembrano il VERO futuro.
    non+autenticato
  • > Che p***e questo XML, ma serve veramente?

    Sì. Serve veramente.

    > Attualmente si vede usare XML anche per file di
    > configurazione e per formati di file tipo

    Esatto. Cosa dovresti usare? Un formato diverso per ogni file di configurazione, e reinventarti un parser ogni volta? Formati proprietari per i documenti che da qui a cinque anni rischi di non leggere più?

    > documento (vedi ODF). Secondo me dovrebbe
    > usato SOLTANTO come formato per messaggi.

    Perché? XML non è nato per i messaggi. SOAP è venuto dopo.

    > Ora non voglio essere polemico (sono bugiardoCon la lingua fuori
    > ) ma memorizzare documenti XML direttamente in un
    > DB è una vaccata. Infatti ogni volta che bisogna

    Dipende. Se lo usi male fai una vaccata. Se lo usi bene ci guadagni parecchio.

    > Secondo me bisognerebbe spingere verso DBMS ad
    > oggetti che mi sembrano il VERO futuro.

    Sembravano, direi. Se ne parla da anni ormai, ma non hanno mai sfondato, probabilmente un motivo c'è.
    non+autenticato

  • - Scritto da: Anonimo
    > > Che p***e questo XML, ma serve veramente?
    >
    > Sì. Serve veramente.

    Intendevo, serve veramente in un DB?

    >
    > > Attualmente si vede usare XML anche per file di
    > > configurazione e per formati di file tipo
    >
    > Esatto. Cosa dovresti usare? Un formato diverso
    > per ogni file di configurazione, e reinventarti
    > un parser ogni volta? Formati proprietari per i
    > documenti che da qui a cinque anni rischi di non
    > leggere più?

    Ci sono prodotti che gestiscono la configurazione tramite codice (es. PicoContainer usa per la configurazione puro e semplice codice Java).
    Non parlo di configurazioni che devono stare in un file di testo (ad esempio i parametri di connessione ad un DB) ma di configurazioni interne dell'applicazione (sto pensando ai file xml di configurazione di Struts ad esempio).

    >
    > > documento (vedi ODF). Secondo me dovrebbe
    > > usato SOLTANTO come formato per messaggi.
    >
    > Perché? XML non è nato per i messaggi. SOAP è
    > venuto dopo.

    XML è nato per fare da tramite tra aziende diverse, quindi di fatto è nato per messaggi di interoperabilità tra aziende.

    >
    > > Ora non voglio essere polemico (sono bugiardoCon la lingua fuori
    > > ) ma memorizzare documenti XML direttamente in
    > un
    > > DB è una vaccata. Infatti ogni volta che bisogna
    >
    > Dipende. Se lo usi male fai una vaccata. Se lo
    > usi bene ci guadagni parecchio.

    La mia avversione ad XML (usato male) è fondamentalmente una: nonostante alcuni dicano il contrario, XML non è scalabile (bisogna cominciare a leggerlo sempre dall'inizio). Questo è il suo problema più grande.

    >
    > > Secondo me bisognerebbe spingere verso DBMS ad
    > > oggetti che mi sembrano il VERO futuro.
    >
    > Sembravano, direi. Se ne parla da anni ormai, ma
    > non hanno mai sfondato, probabilmente un motivo
    > c'è.

    http://www.db4o.com/ sembra molto promettente. Tra l'altro ultimamente su theserverside hanno detto che avrebbero supportato query scritte direttamente in Java. Addio SQL (scherzo).

    P.S. Secondo me ODF è un passo enorme avanti, perché è uno standard. Solo che magari ci possono essere metodi migliori (sto pensando a TeX).
    non+autenticato
  • > Intendevo, serve veramente in un DB?

    Sì, serve veramente. Perché è spesso è inutile convertire da codice da XML Tabelle DB. Si perde un sacco di tempo inutilmente.

    > interne dell'applicazione (sto pensando ai file
    > xml di configurazione di Struts ad esempio).

    È una comodità. Hai già il parser, il file è autodescrittivo, è human-readable, ci puoi accedere anche con altri strumenti.

    > XML è nato per fare da tramite tra aziende
    > diverse, quindi di fatto è nato per messaggi di
    > interoperabilità tra aziende.

    No, ti sbagli. XML è nato per avere un linguaggio di mark-up flessibile più semplice di SGML. Si dall'inizio uno dei compiti principali è stato quello di essere usato per "documenti", anche non strettamente gerarchici. L'uso per la messaggistica è solo una delle tante possibilità, ma non è mai stato lo scopo principale.

    > cominciare a leggerlo sempre dall'inizio). Questo
    > è il suo problema più grande.

    Anche molti formati binari hanno lo stesso problema. Comunque XML sacrifica la velocità in cambio di flessibilità e indipendenza. Non è detto che sia sempre la cosa migliore, non vorrei vedere un TCP/IP con i pacchetti in formato XML... Sorride

    Del resto i DB non abbandonano la struttura standard. Aggiungono solo una funzionalità in più che in diversi casi è estremamente comoda. Se hai già contenuti in XML è comodo memorizzarli e interrogarli in formato nativo.

    > http://www.db4o.com/ sembra molto promettente.

    Sì, ma come vedi siamo ancora alle promesse. Per ora nessuno ha sfondato, e ce ne sono diversi in giro da anni.

    > direttamente in Java. Addio SQL (scherzo).

    Non scherzi più di tanto... dai un'occhiata a LINQ.

    > essere metodi migliori (sto pensando a TeX).

    Ma TeX è in giro da anni e non si è affermato come standard. Quindi...
    non+autenticato

  • - Scritto da: Anonimo

    > Ora non voglio essere polemico (sono bugiardoCon la lingua fuori
    > ) ma memorizzare documenti XML direttamente in un
    > DB è una vaccata. Infatti ogni volta che bisogna
    > estrarre dei dati "veri" dai documenti bisogna
    > parsarli, e viceversa quando si vogliono
    > trasformare i dati veri in XML bisogna
    > serializzarli, sono costi non da poco.

    Infatti DB2 Viper li gestisce direttamente e questi costi diminuiscono drasticamente.

    Non per essere polemico A bocca aperta ma avere la gestione diretta dell'XML oramai è una esigenza che deve essere colmata. XML va anche bene per gestire dati di tipo "documento". Un db relazionale/documentale può gestire una serie di scenari veramente interessanti. Tra l'altro sono gli scenari più innovativi.

    Purtroppo penso che i db ad oggetti non li vedremo mai. Triste

    non+autenticato

  • - Scritto da: Anonimo
    >
    > - Scritto da: Anonimo
    >
    > > Ora non voglio essere polemico (sono bugiardoCon la lingua fuori
    > > ) ma memorizzare documenti XML direttamente in
    > un
    > > DB è una vaccata. Infatti ogni volta che bisogna
    > > estrarre dei dati "veri" dai documenti bisogna
    > > parsarli, e viceversa quando si vogliono
    > > trasformare i dati veri in XML bisogna
    > > serializzarli, sono costi non da poco.
    >
    > Infatti DB2 Viper li gestisce direttamente e
    > questi costi diminuiscono drasticamente.

    Un momento... io intendo che, quando ti arrivano dopo una query, tu hai un documento XML che devi gestire, e per gestirlo devi fare il parsing con qualcosa. Se ti arriva direttamente una riga di una query, il parsing è praticamente zero (giusto spostamento di variabili).

    >
    > Non per essere polemico A bocca aperta ma avere la
    > gestione diretta dell'XML oramai è una esigenza
    > che deve essere colmata.

    Perché tutti ci dicono che XML è il futuro...

    > XML va anche bene per
    > gestire dati di tipo "documento".

    Certo che "va bene" ma non è il massimo

    > Un db
    > relazionale/documentale può gestire una serie di
    > scenari veramente interessanti. Tra l'altro sono
    > gli scenari più innovativi.

    Tipo?

    >
    > Purtroppo penso che i db ad oggetti non li
    > vedremo mai. Triste
    >

    http://www.db4o.com/
    non+autenticato
  • > Un momento... io intendo che, quando ti arrivano
    > dopo una query, tu hai un documento XML che devi
    > gestire, e per gestirlo devi fare il parsing con

    Ma in molti contesti è esattamente quello che voglio!!! Sorride

    Caso pratico: devo memorizzare delle informazioni (documenti), che devo poi visualizzare in modo diverso (XHTML, PDF, ecc.) su dispositivi diversi (dal PC al palmare, passando magari per un televisore). Qual'è la soluzione più semplice? Fare n copie del documento e memorizzarle in un BLOB? Io preferisco memorizzare il documento in formato XML, estrarlo (e la possibilità do ricerca *all'interno* dell'XML memorizzato è essenziale, così come la manipolazione diretta) e quindi con XSLT (o XSL-FO, ecc.) convertirlo nel formato finale.

    > Perché tutti ci dicono che XML è il futuro...

    Perché XML è uno standard e ci sono in giro un mucchio di tool per manipolarlo... perché reinventare tutte le volte l'acqua calda?

    > Certo che "va bene" ma non è il massimo

    Da quando? XML *è nato* per gestire documenti! Ma andate un po' sul sito del W3C a leggervi la documentazione! Come volete gestirli i documenti? In formato Microsoft Word? In PDF? Ma ci avete mai lavorato con un documentale?

    non+autenticato
  • >
    > Purtroppo penso che i db ad oggetti non li
    > vedremo mai. Triste
    >
    Basta avere il coraggio di uscire dal coro e non scegliere in base al "così fan tutti".

    http://www.intersystems.com/cache/index.html

    Concordo sul fatto che XML è un modello di rappresentazionedei dati e IMO non è adatto (performante, comodo, efficace....) ad essere utilizzato come modello di archiviazione dati in un database.
    Altra cosa è avere un database (e i database non solo solo relazionali, se non fai parte del coro) "che fa il suo mestiere" dando la possibilità di "proiettare" (o rappresentare se preferite) i dati in formato XML.
    Certo che se il database è limitato nelle possibilità di modellizzazione come un relazionale....i problemi di proiezione verso l'XML (o, peggio, viceversa) diventano dolori.....e allora si inventano strati/accrocchi per ovviare al problema di base: i limiti del modello relazionale nel rapresentare in modo semplice problemi del mondo reale.

    Ovviamente è una mia opinione personale...molto personale visto come va il mercato.....

    Saluti
    non+autenticato
  • Dall'articolo:

    "In particolare, IBM sostiene che il nuovo motore del proprio DBMS sarà capace di fondere in maniera trasparente i dati relazionali classici con i dati XML senza dover operare una nuova formattazione di questi ultimi o doverli inserire all'interno di oggetti di grandi dimensioni residenti nel database. Questa caratteristica promette di rendere l'accesso alle informazioni più efficiente e flessibile e, nel contempo, di ridurre i costi associati alle attuali tecniche di data management."

    Se ho ben capito sarà possibile interrogare dati contenuti in file XML che però non risiederanno sul database. Quindi le transazioni, il recovery dei dati e tutte le cose che i dbms fanno per garantirne l'integrità non saranno applicabili ai dati in XML?



  • - Scritto da: matcion
    > Dall'articolo:
    >
    > "In particolare, IBM sostiene che il nuovo motore
    > del proprio DBMS sarà capace di fondere in
    > maniera trasparente i dati relazionali classici
    > con i dati XML senza dover operare una nuova
    > formattazione di questi ultimi o doverli inserire
    > all'interno di oggetti di grandi dimensioni
    > residenti nel database. Questa caratteristica
    > promette di rendere l'accesso alle informazioni
    > più efficiente e flessibile e, nel contempo, di
    > ridurre i costi associati alle attuali tecniche
    > di data management."
    >
    > Se ho ben capito sarà possibile interrogare dati
    > contenuti in file XML che però non risiederanno
    > sul database. Quindi le transazioni, il recovery
    > dei dati e tutte le cose che i dbms fanno per
    > garantirne l'integrità non saranno applicabili ai
    > dati in XML?

    Diciamo che l'articolista ha tradotto male. Il DB2 è un database ORDBMS (relazionale ad oggetti). Finora il DB2 gestiva i dati di tipo XML con il meccanismo degli extender che permette di definire oggetti. Il tipico store di questi oggetti sono LOB (Large OBject) sia binari (BLOB) che carattere (CLOB). Con Viper il dato XML diventa un dato per così dire nativo e quindi estremamente integrato. La parte ACID ovviamente vale ancora.
    non+autenticato

  • - Scritto da: Anonimo
    >
    > - Scritto da: matcion
    > > Dall'articolo:
    > >
    > > "In particolare, IBM sostiene che il nuovo
    > motore ... dati in XML?
    >
    > Diciamo che l'articolista ha tradotto male. Il
    > DB2 è un database ORDBMS (relazionale ad
    > oggetti). Finora il DB2 gestiva i dati di tipo
    > XML con il meccanismo degli extender che permette
    > di definire oggetti. Il tipico store di questi
    > oggetti sono LOB (Large OBject) sia binari (BLOB)
    > che carattere (CLOB). Con Viper il dato XML
    > diventa un dato per così dire nativo e quindi
    > estremamente integrato. La parte ACID ovviamente
    > vale ancora.

    Vien via non registrato, registrati che cosi' riesco a filtrare i discorsi utili da quelli stupidi.
    Anche se non usero' mai un DB2 la tua opinione ha un valore.