RE: [SouJava-J] Persistencia de Objetos

2000-07-17 Por tôpico Alysson Neves Bessani

On Thu, 13 Jul 2000, Andre wrote:
> 
> Se voce esta pensando em implementar transacoes 
> distribuidas, o banco que eu te indiquei talvez nao ajude
> muito. Apesar de permitir que multiplos threads acessem 
> os dados concorrentemente, ele nao suporta mais de uma 
> maquina virtual simultaneamente. No meu caso eu tinha um
> servidor RMI que concentrava o acesso ao banco oferecendo
> uma serie de servicos para as demais maquinas virtuais.
> Funciona.

Na verdade sao varios servidores, um para cada dominio de objetos,
temos um soh para ferramentas, outro soh para tarefas e agendamento e por
aih vai... Estou usando CORBA (ORBacus 4) na implementacao, acho que vou
tentar utilizar este banco de dados que voce me indicou, pelo menos para
fazer alguns testes e sentir como eh que eh o negocio... Eu usei o
ObjectStore um tempo, soh que era em C++, num outro projeto relacionado a
Workflow. Gostei bastante do banco, tomara que este que voce me indicou
tambem caia bem no projeto (este banco que vc me indicou nao eh uma
versao do ObjectStore para Java?).

Obrigado mais uma vez pela dica. 

Alysson Neves Bessani   
mailto:[EMAIL PROTECTED]

--- LISTA SOUJAVA ---
http://www.soujava.org.br  -  Sociedade de Usuários Java da Sucesu-SP
[dúvidas mais comuns: http://www.soujava.org.br/faq.htm]
[para sair da lista: http://www.soujava.org.br/forum/cadastrados.htm]
[regras da lista: http://www.soujava.org.br/regras.htm]
-




Re: [SouJava-J] Persistencia de Objetos

2000-07-14 Por tôpico Alexandre G. L. Fernandes

Caro André:
Se for possível, gostaria de saber mais a respeito de sua experiência
com um banco de dados orientado à objetos. Até onde pude saber,
algumas tentativas de se utilizar bancos assim foram por água abaixo.
Minhas principais dúvidas são:
1) em relação à performance: vc trabalhou com grande quantidade de dados?
Como foi a performance do banco? O que é mais custoso, consultas ou
inserções/exclusões?
2) em relação ao gerenciamento de transações: como ele gerencia transações?
(não estou
falando de banco distribuído, mas transações simples) Mais
exatamente, o que acontece se eu estiver inserindo vários objetos de várias
classes
inter-relacionadas e der um pau na máquina, ele consegue voltar todos os
objetos
já inseridos?
Desde já agradeço-lhe a atenção,

--

 Alexandre G. L. Fernandes
   [EMAIL PROTECTED]
 Phone: +55 (19) 3737.4548
Ci&T - software enabling the e-world
   http://www.cit.com.br



Andre wrote:

> Alysson,
>
> > Estou tentando fugir do SQL, quanto ao
> > OQL ela eh padronizada? Se nao for jah
> > estah fora de cogitacao...
>
> A ODMG definiu um padrao para esta linguagem (OQL) mas,
> ate onde eu sei, este banco de dados que eu mencionei
> nao implementa este padrao. Eh claro que, como voce
> estara trabalhando com objetos em sua forma nativa,
> a necessidade de uma linguagem declarativa para vazer
> as consultas (SQL, por exemplo) diminui drasticamente,
> uma vez que voce pode navegar nos objetos diretamente
> sem ter que fazer o mapeamento que eu mencionei no
> e-mail anterior. A ideia eh que se voce armazena um
> objeto da classe "Workflow" no banco, voce nao vai ter
> que "montar" todo o objeto a partir das tabelas. Voce
> simplesmente vai no banco e pega o proprio objeto (a
> partir de uma chave, um nome ou qualquer coisa que o
> identifique). Se voce tiver muitos destes objetos, por
> exemplo, voce pode incluir todos eles em um Map (ou List,
> ou qualquer outra coisa) e armazenar tudo.
>
> > Quanto as transacoes,
> > estou tentando bolar algo que substitua
> > visto que estarei trabalhando com transacoes
> > distribuidas e ainda nao chegamos a um
> > consenso neste ponto do projeto.
>
> Se voce esta pensando em implementar transacoes
> distribuidas, o banco que eu te indiquei talvez nao ajude
> muito. Apesar de permitir que multiplos threads acessem
> os dados concorrentemente, ele nao suporta mais de uma
> maquina virtual simultaneamente. No meu caso eu tinha um
> servidor RMI que concentrava o acesso ao banco oferecendo
> uma serie de servicos para as demais maquinas virtuais.
> Funciona.
>
> Em outras palavras, se voce tiver multiplos bancos de
> dados (distribuidos entre diversas maquinas, por exemplo),
> o banco mencionado nao oferece uma maneira de controlar
> as transacoes em todos os bancos.
>
> > Vou dar uma olhadinha, pode ser uma boa.
>
> Boa sorte! Qualquer coisa...
>
> Andre Mendonca
> [EMAIL PROTECTED]
>
> --- LISTA SOUJAVA ---
> http://www.soujava.org.br  -  Sociedade de Usuários Java da Sucesu-SP
> [dúvidas mais comuns: http://www.soujava.org.br/faq.htm]
> [para sair da lista: http://www.soujava.org.br/forum/cadastrados.htm]
> [regras da lista: http://www.soujava.org.br/regras.htm]
> -



--- LISTA SOUJAVA ---
http://www.soujava.org.br  -  Sociedade de Usuários Java da Sucesu-SP
[dúvidas mais comuns: http://www.soujava.org.br/faq.htm]
[para sair da lista: http://www.soujava.org.br/forum/cadastrados.htm]
[regras da lista: http://www.soujava.org.br/regras.htm]
-




RE: [SouJava-J] Persistencia de Objetos

2000-07-13 Por tôpico Andre

Alysson,

> Estou tentando fugir do SQL, quanto ao 
> OQL ela eh padronizada? Se nao for jah 
> estah fora de cogitacao... 

A ODMG definiu um padrao para esta linguagem (OQL) mas, 
ate onde eu sei, este banco de dados que eu mencionei 
nao implementa este padrao. Eh claro que, como voce 
estara trabalhando com objetos em sua forma nativa, 
a necessidade de uma linguagem declarativa para vazer 
as consultas (SQL, por exemplo) diminui drasticamente,
uma vez que voce pode navegar nos objetos diretamente
sem ter que fazer o mapeamento que eu mencionei no 
e-mail anterior. A ideia eh que se voce armazena um
objeto da classe "Workflow" no banco, voce nao vai ter 
que "montar" todo o objeto a partir das tabelas. Voce 
simplesmente vai no banco e pega o proprio objeto (a 
partir de uma chave, um nome ou qualquer coisa que o 
identifique). Se voce tiver muitos destes objetos, por
exemplo, voce pode incluir todos eles em um Map (ou List,
ou qualquer outra coisa) e armazenar tudo.

> Quanto as transacoes, 
> estou tentando bolar algo que substitua 
> visto que estarei trabalhando com transacoes 
> distribuidas e ainda nao chegamos a um 
> consenso neste ponto do projeto.

Se voce esta pensando em implementar transacoes 
distribuidas, o banco que eu te indiquei talvez nao ajude
muito. Apesar de permitir que multiplos threads acessem 
os dados concorrentemente, ele nao suporta mais de uma 
maquina virtual simultaneamente. No meu caso eu tinha um
servidor RMI que concentrava o acesso ao banco oferecendo
uma serie de servicos para as demais maquinas virtuais.
Funciona.

Em outras palavras, se voce tiver multiplos bancos de 
dados (distribuidos entre diversas maquinas, por exemplo), 
o banco mencionado nao oferece uma maneira de controlar 
as transacoes em todos os bancos.

> Vou dar uma olhadinha, pode ser uma boa.

Boa sorte! Qualquer coisa...

Andre Mendonca
[EMAIL PROTECTED]


--- LISTA SOUJAVA ---
http://www.soujava.org.br  -  Sociedade de Usuários Java da Sucesu-SP
[dúvidas mais comuns: http://www.soujava.org.br/faq.htm]
[para sair da lista: http://www.soujava.org.br/forum/cadastrados.htm]
[regras da lista: http://www.soujava.org.br/regras.htm]
-




RE: [SouJava-J] Persistencia de Objetos

2000-07-13 Por tôpico Alysson Neves Bessani

On Thu, 13 Jul 2000, Andre wrote:

> Alysson,
> 
> As grandes desvantagens seriam nao poder recuperar 
> seus objetos utilizando uma linguagem de consulta 
> (SQL, OQL) e nao haver um mecanismo de controle de 
> transacoes, de modo que seus dados nao sejam corrompidos
> no caso de alguma falha durante o processo de armazenamento
> dos dados (begin/commit/rollback).

Estou tentando fugir do SQL, quanto ao OQL ela eh padronizada? Se
nao for jah estah fora de cogitacao... Quanto as transacoes, estou
tentando bolar algo que substitua visto que estarei trabalhando com
transacoes distribuidas e ainda nao chegamos a um consenso neste ponto do
projeto.

> Se voce puder utilizar um banco de dados orientado a 
> objetos, voce mantem a facilidade de implementacao e
> ainda tem linguagem de consulta e controle de
> transacoes. Ha uma versao "light" de um BD OO que nao
> eh tao cara e funciona muito bem:
> 
> http://www.exceloncorp.com/products/objectstore/os_download.html

Vou dar uma olhadinha, pode ser uma boa.

Alysson Neves Bessani   
mailto:[EMAIL PROTECTED]

--- LISTA SOUJAVA ---
http://www.soujava.org.br  -  Sociedade de Usuários Java da Sucesu-SP
[dúvidas mais comuns: http://www.soujava.org.br/faq.htm]
[para sair da lista: http://www.soujava.org.br/forum/cadastrados.htm]
[regras da lista: http://www.soujava.org.br/regras.htm]
-




RE: [SouJava-J] Persistencia de Objetos

2000-07-13 Por tôpico Andre

Alysson,

As grandes desvantagens seriam nao poder recuperar 
seus objetos utilizando uma linguagem de consulta 
(SQL, OQL) e nao haver um mecanismo de controle de 
transacoes, de modo que seus dados nao sejam corrompidos
no caso de alguma falha durante o processo de armazenamento
dos dados (begin/commit/rollback).

Se voce puder utilizar um banco de dados orientado a 
objetos, voce mantem a facilidade de implementacao e
ainda tem linguagem de consulta e controle de
transacoes. Ha uma versao "light" de um BD OO que nao
eh tao cara e funciona muito bem:

http://www.exceloncorp.com/products/objectstore/os_download.html

Voce armazena os objetos em sua forma nativa e nao 
precisa implementar o mapeamento entre tabelas e 
objetos.

Andre Mendonca
[EMAIL PROTECTED]
Sakonnet Technology, LLC
594 Broadway, Suite 403
New York, NY 10012 

-Original Message-
From: Alysson Neves Bessani [mailto:[EMAIL PROTECTED]]
Sent: Thursday, July 13, 2000 3:11 PM
To: [EMAIL PROTECTED]
Subject: [SouJava-J] Persistencia de Objetos



Ola amigos

Estou desenvolvendo um projeto de um sistema de gerenciamento de
workflow em java e a principio pensei em utilizar um Banco de Dados
relacionais como o DB2 ou o Oracle, entretanto ultimamente venho tendo
boas ideias em termos de utilizacao da serializacao de objetos para prover
a persistencia que eu tanto necessito... Algum amigo da lista tem ideia de
quais seriam as perdas/ganhos (o principal ganho eh na facilidade de
implementacao) que eu poderia ter? Em tempo, tenho que armazenar grafos
bem grandes soh que nao necessariamente em grande quantidade...

Resumindo: Eh ou nao uma boa ideia utilizar peristencia no lugar
de banco de dados?

Alysson Neves Bessani   
mailto:[EMAIL PROTECTED]

--- LISTA SOUJAVA ---
http://www.soujava.org.br  -  Sociedade de Usuarios Java da Sucesu-SP
[dzvidas mais comuns: http://www.soujava.org.br/faq.htm]
[para sair da lista: http://www.soujava.org.br/forum/cadastrados.htm]
[regras da lista: http://www.soujava.org.br/regras.htm]
-

--- LISTA SOUJAVA ---
http://www.soujava.org.br  -  Sociedade de Usuários Java da Sucesu-SP
[dúvidas mais comuns: http://www.soujava.org.br/faq.htm]
[para sair da lista: http://www.soujava.org.br/forum/cadastrados.htm]
[regras da lista: http://www.soujava.org.br/regras.htm]
-




[SouJava-J] Persistencia de Objetos

2000-07-13 Por tôpico Alysson Neves Bessani


Ola amigos

Estou desenvolvendo um projeto de um sistema de gerenciamento de
workflow em java e a principio pensei em utilizar um Banco de Dados
relacionais como o DB2 ou o Oracle, entretanto ultimamente venho tendo
boas ideias em termos de utilizacao da serializacao de objetos para prover
a persistencia que eu tanto necessito... Algum amigo da lista tem ideia de
quais seriam as perdas/ganhos (o principal ganho eh na facilidade de
implementacao) que eu poderia ter? Em tempo, tenho que armazenar grafos
bem grandes soh que nao necessariamente em grande quantidade...

Resumindo: Eh ou nao uma boa ideia utilizar peristencia no lugar
de banco de dados?

Alysson Neves Bessani   
mailto:[EMAIL PROTECTED]

--- LISTA SOUJAVA ---
http://www.soujava.org.br  -  Sociedade de Usuários Java da Sucesu-SP
[dúvidas mais comuns: http://www.soujava.org.br/faq.htm]
[para sair da lista: http://www.soujava.org.br/forum/cadastrados.htm]
[regras da lista: http://www.soujava.org.br/regras.htm]
-




Re: [SouJava-J] Persistencia de objetos e Java Blend

2000-02-17 Por tôpico Andre Mendonca

Ricardo,

> Estou pesquisando muito a respeito de mapeamento e bancos de dados oritentados
> a objetos, e estou encontrando um pouco de dificuldade.

Em www.cetus-links.org tem bastante coisa. De uma olhada por la pois
pode ser util. Tem um livro chamado "Building Scalable Object-Oriented
Database Applications" que descreve uma possivel solucao para o
isolamento de uma aplicacao dos detalhes de implementacao da camada de
banco de dados.

> Li a documentagco do PSE e achei ele meio limitado.

O PSE eh um banco de dados 100% escrito em Java (o que ja eh uma grande
vantagem) e nao eh indicado para aplicacoes 2-tier. Quais foram as
limitacoes que mais lhe incomodaram? (em private, por favor) A
documentacao eh bastante extensa.

> Procurei algum Bd Orientado a objetos free mas nco encontrei nenhum e Bancos de
> dados relacionais
> Free existem varios por am (Postgres,mySQL,...), e ouvi falar que sco bem
> rapidos. 

O problema destes bancos de dados free eh que nao ha garantias que
havera continuidade em seu desenvolvimento (upgrade para novas versoes
de sistema operacional, eliminacao de bugs, etc.). Ha casos em que a
saude financeira da empresa que desenvolve o produto que iremos utilizar
deve ser levada em consideracao. A Ardent Software, por exemplo,
simplesmente nao mais comercializa o O2 que era um SGBD OO. Na ha
garantias que a empresa ira dar continuidade ao seu desenvolvimento.

> Ainda estou procurando outras opgues..

Ha uma serie delas. Acho que TopLink (www.objetopeople.com) e CocoBase
(www.thoughtinc.com) sao as mais conhecidas. Todas elas com suporte a
Java.

Andre Mendonca
[EMAIL PROTECTED]

> Aguardo seus comentarios.
> Ricardo Neisse - [EMAIL PROTECTED]
> 
> Andre Mendonca gravada:
> 
> > Silvio,
> > Os SGBDs orientados a objeto eliminam a necessidade de mapeamento entre
> > objetos e tabelas. As ferramentas de mapeamento (como Java Blend, JRB,
> > CocoBase, TopLink, etc.) facilitam o trabalho mas voce podera ter
> > problemas de performance a medida em que o seu banco de dados cresce.
> > Caso o seu modelo de objetos seja razoavelmente complexo, fazer tudo na
> > mao pode te dar dor de cabeca.
> >
> > Caso voce tenha necessariamente que usar algum SGBD relacional, uma boa
> > pedida seria utilizar as extensoes objeto-relacionais de SGBDs o Oracle
> > 8i e o DB2. Apesar de internamente eles gravarem os dados como tabelas,
> > sua definicao eh bastante facilitada.
> >
> > Nao sei se JDBC oferece facilidades para a utilizacao destas extensoes.
> > Alguem poderia comentar algo a respeito?
> >
> > Andre
> > [EMAIL PROTECTED]
> >
> > PS: ObjectStore/PSE Pro (www.odi.com), POET (www.poet.com), Versant
> > (www.versant.com) e Jasmine (nao necessariamente nesta mesma ordem) sao
> > os SGBDs OO mais conhecidos.
> >
> > PS1: A Sun esta inicializando o processo de discussao para a definicao
> > da API JDO (Java Data Objects). Podera ser util no futuro. De uma olhada
> > no endereco abaixo:
> >
> > http://java.sun.com/aboutJava/communityprocess/jsr/jsr_012_dataobj.html
> >
> > "Silvio L. de Morais" wrote:
> > >
> > > Ola pessoal.
> > >
> > > Alguem ja teve a oportunidade de testar ou mesmo usar profissionalmente
> 
> > o pacote Java Blend da Sun para persistencia de objetos? De preferencia
> 
> > > com o Oracle?
> > > Ou mesmo alguma outra solucao para esse problema?
> > >
> > > No meu projeto atual, preciso fazer o caminho Objetos Java ->  Banco
> > > Relacional.  Mas em futuros projetos certamente sera preciso o inverso
> > > RDBMS -> Objetos Java.
> > >
> > > Alguma ideia? Experienciaas para trocar?
> > >
> > > Obrigado.
> > >
> > > --- LISTA SOUJAVA ---
> > > http://www.soujava.org.br  -  Sociedade de Usuarios Java da Sucesu-SP
> > > [dzvidas mais comuns: http://www.soujava.org.br/faq.htm]
> > > [para sair da lista: http://www.soujava.org.br/forum/cadastrados.htm]
> > > -
> >
> > --- LISTA SOUJAVA ---
> > http://www.soujava.org.br  -  Sociedade de Usuarios Java da Sucesu-SP
> > [dzvidas mais comuns: http://www.soujava.org.br/faq.htm]
> > [para sair da lista: http://www.soujava.org.br/forum/cadastrados.htm]
> > -
> 
> --- LISTA SOUJAVA ---
> http://www.soujava.org.br  -  Sociedade de Usuarios Java da Sucesu-SP
> [dzvidas mais comuns: http://www.soujava.org.br/faq.htm]
> [para sair da lista: http://www.soujava.org.br/forum/cadastrados.htm]
> -

--- LISTA SOUJAVA ---
http://www.soujava.org.br  -  Sociedade de Usuários Java da Sucesu-SP
[dúvidas mais comuns: http://www.soujava.org.br/faq.htm]
[para sair da lista: http://www.soujava.org.br/fo

Re: [SouJava-J] Persistencia de objetos e Java Blend

2000-02-17 Por tôpico Ricardo Neisse

Olá,

Estou pesquisando muito a respeito de mapeamento e bancos de dados oritentados
a objetos, e estou encontrando um pouco de dificuldade.

Um lugar onde encontrei muita informação :
Object Data Management Group
http://www.odmg.org
(Papers -> Solving the Java Object Storage Problem by Douglas Barry and
Torsten)

Encontrei alguma coisa também no site da IBM, onde há um artigo
sobre uma ferramenta que faz o mapeamento OO para BD relacional
VADD - Object to Relational Table Mapping Techniques with Persistence Builder
http://www7.software.ibm.com/vad.nsf/Data/Document3124

Sobre o Jasmine tenho uma cópia mas não testei, pois ele só roda em Windows NT.

Li a documentação do PSE e achei ele meio limitado.

A objectivity (http://www.objectivity.com/) tem uma ferramenta que realziza
mapemento,
mas não possui representante no Brasil e não há download ná página, mandei um
e-mail
para eles e disseram que devido ao fato de não possuirem representante no
Brasil para dar
suporte não poderiam me enviar uma cópia de avaliação do produto.

Fiz o download do JavaBlend mas ainda não testei.

Estou desenvolvendo um sistema utilizando servlets e os meus dados estão
armazenados em
um banco de dados Access. O mapeamento estou realizando no braço..., pois o meu
modelo
é pequeno, poucas classes. Na minha opinião não é uma coisa muito produtiva.
Assim que eu
terminar este projeto irei desenvolver outro um pouco maior, e até lá pretendo
encontrar uma
solução mais elegante para armazenar meus objetos.
Procurei algum Bd Orientado a objetos free mas não encontrei nenhum e Bancos de
dados relacionais
Free existem vários por aí (Postgres,mySQL,...), e ouvi falar que são bem
rápidos. Por isto optei por
realizar o mapeamento dos objetos e utilizar um banco de dados free.
Ainda estou procurando outras opções..
Aguardo seus comentários.
Ricardo Neisse - [EMAIL PROTECTED]

Andre Mendonca gravada:

> Silvio,
> Os SGBDs orientados a objeto eliminam a necessidade de mapeamento entre
> objetos e tabelas. As ferramentas de mapeamento (como Java Blend, JRB,
> CocoBase, TopLink, etc.) facilitam o trabalho mas voce podera ter
> problemas de performance a medida em que o seu banco de dados cresce.
> Caso o seu modelo de objetos seja razoavelmente complexo, fazer tudo na
> mao pode te dar dor de cabeca.
>
> Caso voce tenha necessariamente que usar algum SGBD relacional, uma boa
> pedida seria utilizar as extensoes objeto-relacionais de SGBDs o Oracle
> 8i e o DB2. Apesar de internamente eles gravarem os dados como tabelas,
> sua definicao eh bastante facilitada.
>
> Nao sei se JDBC oferece facilidades para a utilizacao destas extensoes.
> Alguem poderia comentar algo a respeito?
>
> Andre
> [EMAIL PROTECTED]
>
> PS: ObjectStore/PSE Pro (www.odi.com), POET (www.poet.com), Versant
> (www.versant.com) e Jasmine (nao necessariamente nesta mesma ordem) sao
> os SGBDs OO mais conhecidos.
>
> PS1: A Sun esta inicializando o processo de discussao para a definicao
> da API JDO (Java Data Objects). Podera ser util no futuro. De uma olhada
> no endereco abaixo:
>
> http://java.sun.com/aboutJava/communityprocess/jsr/jsr_012_dataobj.html
>
> "Silvio L. de Morais" wrote:
> >
> > Ola pessoal.
> >
> > Alguem ja teve a oportunidade de testar ou mesmo usar profissionalmente

> o pacote Java Blend da Sun para persistencia de objetos? De preferencia

> > com o Oracle?
> > Ou mesmo alguma outra solucao para esse problema?
> >
> > No meu projeto atual, preciso fazer o caminho Objetos Java ->  Banco
> > Relacional.  Mas em futuros projetos certamente sera preciso o inverso
> > RDBMS -> Objetos Java.
> >
> > Alguma ideia? Experienciaas para trocar?
> >
> > Obrigado.
> >
> > --- LISTA SOUJAVA ---
> > http://www.soujava.org.br  -  Sociedade de Usuarios Java da Sucesu-SP
> > [dzvidas mais comuns: http://www.soujava.org.br/faq.htm]
> > [para sair da lista: http://www.soujava.org.br/forum/cadastrados.htm]
> > -
>
> --- LISTA SOUJAVA ---
> http://www.soujava.org.br  -  Sociedade de Usuários Java da Sucesu-SP
> [dúvidas mais comuns: http://www.soujava.org.br/faq.htm]
> [para sair da lista: http://www.soujava.org.br/forum/cadastrados.htm]
> -

--- LISTA SOUJAVA ---
http://www.soujava.org.br  -  Sociedade de Usuários Java da Sucesu-SP
[dúvidas mais comuns: http://www.soujava.org.br/faq.htm]
[para sair da lista: http://www.soujava.org.br/forum/cadastrados.htm]
-



Re: [SouJava-J] Persistencia de objetos e Java Blend

2000-02-16 Por tôpico Andre Mendonca

Silvio,
Os SGBDs orientados a objeto eliminam a necessidade de mapeamento entre
objetos e tabelas. As ferramentas de mapeamento (como Java Blend, JRB,
CocoBase, TopLink, etc.) facilitam o trabalho mas voce podera ter
problemas de performance a medida em que o seu banco de dados cresce.
Caso o seu modelo de objetos seja razoavelmente complexo, fazer tudo na
mao pode te dar dor de cabeca.

Caso voce tenha necessariamente que usar algum SGBD relacional, uma boa
pedida seria utilizar as extensoes objeto-relacionais de SGBDs o Oracle
8i e o DB2. Apesar de internamente eles gravarem os dados como tabelas,
sua definicao eh bastante facilitada.

Nao sei se JDBC oferece facilidades para a utilizacao destas extensoes.
Alguem poderia comentar algo a respeito?

Andre
[EMAIL PROTECTED]

PS: ObjectStore/PSE Pro (www.odi.com), POET (www.poet.com), Versant
(www.versant.com) e Jasmine (nao necessariamente nesta mesma ordem) sao
os SGBDs OO mais conhecidos.

PS1: A Sun esta inicializando o processo de discussao para a definicao
da API JDO (Java Data Objects). Podera ser util no futuro. De uma olhada
no endereco abaixo:

http://java.sun.com/aboutJava/communityprocess/jsr/jsr_012_dataobj.html




"Silvio L. de Morais" wrote:
> 
> Ola pessoal.
> 
> Alguem ja teve a oportunidade de testar ou mesmo usar profissionalmente
> o pacote Java Blend da Sun para persistencia de objetos? De preferencia
> com o Oracle?
> Ou mesmo alguma outra solucao para esse problema?
> 
> No meu projeto atual, preciso fazer o caminho Objetos Java ->  Banco
> Relacional.  Mas em futuros projetos certamente sera preciso o inverso
> RDBMS -> Objetos Java.
> 
> Alguma ideia? Experienciaas para trocar?
> 
> Obrigado.
> 
> --- LISTA SOUJAVA ---
> http://www.soujava.org.br  -  Sociedade de Usuarios Java da Sucesu-SP
> [dzvidas mais comuns: http://www.soujava.org.br/faq.htm]
> [para sair da lista: http://www.soujava.org.br/forum/cadastrados.htm]
> -

--- LISTA SOUJAVA ---
http://www.soujava.org.br  -  Sociedade de Usuários Java da Sucesu-SP
[dúvidas mais comuns: http://www.soujava.org.br/faq.htm]
[para sair da lista: http://www.soujava.org.br/forum/cadastrados.htm]
-



[SouJava-J] Persistencia de objetos e Java Blend

2000-02-16 Por tôpico Silvio L. de Morais

Ola pessoal.

Alguem ja teve a oportunidade de testar ou mesmo usar profissionalmente
o pacote Java Blend da Sun para persistencia de objetos? De preferencia
com o Oracle?
Ou mesmo alguma outra solucao para esse problema?

No meu projeto atual, preciso fazer o caminho Objetos Java ->  Banco
Relacional.  Mas em futuros projetos certamente sera preciso o inverso
RDBMS -> Objetos Java.

Alguma ideia? Experienciaas para trocar?

Obrigado.

--- LISTA SOUJAVA ---
http://www.soujava.org.br  -  Sociedade de Usuários Java da Sucesu-SP
[dúvidas mais comuns: http://www.soujava.org.br/faq.htm]
[para sair da lista: http://www.soujava.org.br/forum/cadastrados.htm]
-