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]
---------------------------------------------------------------------
