SQL o problema ou a solução?

Acho que a solução futura será banco de dados nativo de xml.

eu nunca usei, mas o prof aqui na facul vai usa-lo em um trabalho com a turma… o Ozone ( db oo)

http://www.ozone-db.org/frames/home/what.html

Pra cada problema, uma solucao. Basear um banco de dados em XML eh extremamente ineficiente, e nao eh qualquer grafo de objetos que pode ser representado no modelo hierarquico do XML. Mesmo assim, eu estou interessado na sua opiniao… pq vc acha isso?

Solucao pratica e eficiente para hoje? Crie seu modelo relacional. Crie seu modelo em objetos. Crie uma camada simples que faca o meio-de-campo entre os dois modelos. Opcionalmente use um framework ja pronto para este fim (Hibernate, OJB, etc).

Prevayler pode ser uma solucao tambem. Eh um conceito diferente e novo. Pode servir para boa parte dos casos onde se utiliza um SGBD hoje em dia (na pratica nunca usei).

SQL (e o mundo relacional) nao eh um bicho-de-sete-cabecas - voce nao precisa fugir de qualquer mencao a tabelas e/ou SQL.

Marcio Kuchma

Pra cada problema, uma solucao.

Sim, concordo com você plenamente. Foi só um exagero. O que eu quis dizer é que acho banco de dados nativo de xml vai pegar. Na minha opinião, vai fazer o que Banco de Objetos não fez.

Não sei muito sobre esse assunto, mas parece que Bancos de XML combinam pontos positivos de muitas alternativas rivais:
:arrow: Simplicidade (Comparado a BDOO)
:arrow: Expressividade (XQuery em relação a SQL)

Além de possuir algumas características novas
:arrow: Portabilidade de SO
:arrow: Maior facilidade em integrar com qualquer LP

Imagine guardar os dados em um “XMLBD”, manter regras de negócio com XML, componentizadas com Web Services, e exibir com XSLT! Dá para qualquer um xmlmaníaco pirar de felicidade!

A ineficiência quase sempre fica para trás nessas horas. Alguém aí prefere C a Java?

t+

Obs: Por favor, me corrijam se falei alguma besteira.

Só de curiosidade, mostra um…

"vamorim":

"cv":

nao eh qualquer grafo de objetos que pode ser representado no modelo hierarquico do XML.

Só de curiosidade, mostra um...

Ta bom :mrgreen:

class A {
  B b;
}

class B {
  B b;
  A a;
}

public class Main {
 A a = new A();
 a.b = new B();
 b.a = a;
}

Pronto, melou ;)

“kuchma”:

Solucao pratica e eficiente para hoje? Crie seu modelo relacional. Crie seu modelo em objetos. Crie uma camada simples que faca o meio-de-campo entre os dois modelos. Opcionalmente use um framework ja pronto para este fim (Hibernate, OJB, etc).

A camada que vc chama de simples que fica no meio de campo, pode se tornar complexa a depender da minha aplicação.
Se eu tiver um objeto com uma série de atributos que não possam ser guardados em uma única tabela.
E outra dúvida as classes viram tabelas, mas e os métodos que atuam nos dados (objetos) descritos na classe vc transforma em q?

Cv, vc esqueceu o mecanismo de referencia do xml? Ele permite criar grafos de nodos que não são florestas.

<repositorio>
    <objeto id="a" tipo="A">
       <propriedade nome="b" ref="b"/>
    </objeto>
    <objeto id="b" tipo="B">
       <propriedade nome="a" ref="a"/>
    </objeto>
</repositorio>

louds melou você :roll: :roll:

“geofrey”:

A camada que vc chama de simples que fica no meio de campo, pode se tornar complexa a depender da minha aplicação.
Se eu tiver um objeto com uma série de atributos que não possam ser guardados em uma única tabela.

Hibernate resolve esse caso - nao?

Creio que outros frameworks tambem. Eh o que coloquei anteriormente com relacao aos frameworks prontos. Nao eh tao interessante utilizar o Hibernate se voce tem meia duzia de classes simples pra serem armazenadas (mas tambem nao existe nada que impeca - se voce ja tem pratica no negocio e nao vai perder tempo brincando com as configuracoes - go ahead :D). Mas se voce tem uma estrutura complexa (ou seja - a camada intermediaria nao fica taaao simples assim), use uma ferramenta que tem por objetivo resolver o problema.

Ueh - nada.

Nao sei se entendi tua colocacao… um objeto, em tese, representa um conjunto de dados e um conjunto de operacoes que podem ser executadas sobre esses dados. SBGD relacionais tem por objetivo armazenar os dados (sim, sim, tem como realizar operacoes tambem atraves de stored procedures e etc, mas nao vou entrar nesse caso). Voce armazena os dados e recupera quando precisar, restaurando o estado do objeto ao que era originalmente, no momento do armazenamento.

Marcio Kuchma

voltando uma questão que o geofrey colocou sobre banco de dados oo.
Por que ele não são muito utilizados? o que ha de errado com eles??

Já que programamos (ou tentamos, no meu caso) OO não seria mais conveniente usar um banco OO?

“louds”:

Cv, vc esqueceu o mecanismo de referencia do xml? Ele permite criar grafos de nodos que não são florestas.

<repositorio> <objeto id="a" tipo="A"> <propriedade nome="b" ref="b"/> </objeto> <objeto id="b" tipo="B"> <propriedade nome="a" ref="a"/> </objeto> </repositorio>

Esse mecanismo nao eh DO XML, ele pode ser implementado (afinal, nao tem nada que diga pra que serve o ‘ref’…). O ponto que eu estou tentando levantar aqui eh que, sem olhar para os dados contidos dentro dos atributos e tags, voce nao consegue representar estruturas nao-hierarquicas, e isso continua valendo - o seu exemplo mostra como isso pode ser feito, mas concorda que nao eh nada eficiente, comparando-se com um RDBMS, mesmo assim?

Acho que entendi o que você quis dizer. Mas, chateando um pouco, acho que podemos dizer sim que o idref faz parte DO XML. Afinal, ele se encontra na própria especificação da dita cuja!

Mostrar que qualquer grafo pode ser representado em xml não é muito complicado. Se um grafo pode ser representado como uma lista de vértices e uma lista de arestas, e sabendo que uma lista é uma árvore de um apenas um ramo, logo, todo grafo pode ser representado na forma de árvores!

Tem mais, acho que tudo o que é representável, pode ser representado em xml. Sim, tudo. Pensa comigo, se com apenas 0’s e 1’s podemos representar qq coisa (isso é verdade, não é?) , então qualquer coisa mais colorida tal como XML também representa tudo que é representável tb!

<vinci_despertando_o_matemático_maluco_ que_tem_dentro_de_si/>

“cv”:

Esse mecanismo nao eh DO XML, ele pode ser implementado (afinal, nao tem nada que diga pra que serve o ‘ref’…). O ponto que eu estou tentando levantar aqui eh que, sem olhar para os dados contidos dentro dos atributos e tags, voce nao consegue representar estruturas nao-hierarquicas, e isso continua valendo - o seu exemplo mostra como isso pode ser feito, mas concorda que nao eh nada eficiente, comparando-se com um RDBMS, mesmo assim? ;)

Falha minha o xml correto seria:

<repositorio>
    <objeto id="a" tipo="A">
       <propriedade nome="b" idref="b"/>
    </objeto>
    <objeto idf="b" tipo="B">
       <propriedade nome="a" idref="a"/>
    </objeto>
</repositorio>

Prova do crime: http://www.w3.org/TR/2004/REC-xml-20040204/#sec-attribute-types

Os atributos ‘id’ e ‘idref’ são parte do padrão , cv não desvie do assunto, tou mostrando como funciona, não se é rápido ou lento. Vc consegue seguir esses links se usar 1 parser DOM.

cv ajoelha-se perante a nerdice do louds

Ok, voce ganhou… :mrgreen: posso ir pro meu cantinho ter um ataque histerico por nunca ter lido essa spec direito? :lol:

Bá, eu falei disso pq já usei várias vezes. Então foi só buscar a prova para aumentar meu prepotencia-foo . :twisted:

Fora issso, quanto a ler especificações, eu já devo ter lido uns 5% das especificações sobre ??ML da w3c: XML, Schemas, DOM level 1 e 2, HTML, CSS e outras que não lembro agora. Mas somente em horario comercial devo ressalvar. Eu tentei ler as de wsdl e soap mas meu cérebro fritou um pouco antes…

Não tem nada até hoje que tenha superado ou desmerecido o modelo relacional.

Prova disso são todos os sistemas que existem até hoje. E que certamente irão perpetuar a frente.

Nenhuma “fabrica” de banco de dados incluindo a Oracle conseguiu até agora montar um produto que fosse comercial puramente OO, Apesar de tentar bastante ! XML a Oracle realmente vem tentando … versões 9i e 10g estão ai com força em xml.

Penso que por definição “Banco de Dados” armazena, recupera e HOJE até PROCESSA dados com muita eficiencia. Eles são especialistas nisso, os bancos de dados são especialistas em tarefas relacionadas a dados.

Vocês estão discutindo somente uma parte da complexidade de um banco de dados.

E quanto ao resto (que eu lembro):

-integridade dos dados
-integridade do banco (backup/recovery)
-desempenho
-segurança
-replicação
-integração (com outros bancos)
-escalabilidade

Claro que cada caso é um caso, mas em bancos de dados
de Gigabytes ou TeraBytes, será que existe a possibilidade
de usar só XML?

Eu acho dificil…

“Marcos Ortega”:

Não tem nada até hoje que tenha superado ou desmerecido o modelo relacional.

Em que sentido? utilização no mercado?
Porque existem muitas vantagens do modelo OO sobre o relacional.

A questão que eu quis levantar nesse tópico é que SQL foi feita pra consultar tabelas e o faz muitissimo bem, e porque não existe nenhuma OQL ou algo do gênero que funcione tão bem quanto a SQL só que voltado para objetos é claro.
A necessidade é a mãe da invenção… talvez ninguém tenha sentido essa necessidade ainda!
Outra coisa, eu não apredi nada sobre bancos de dados orientados a objeto na faculdade, nunca ouvi falar de um no mercado de trabalho eles existem mesmo?

“Marcos Ortega”:

Não tem nada até hoje que tenha superado ou desmerecido o modelo relacional.

Exceto pelo fato que ele complica excessivamente o desenvolvimento de software OO. Cacete, precisamos de um framework super complexo para guardar o estado de um objeto? Isto é surreal!!

Não é a toa que o JCP meteu JDBC no meio de JCA…

SGBDs foram feitos para dados simples combinados em estruturas e relacionados. Eles estão prontos para:

struct aluno{
    char * nome;
     int idade;
} a1;

Não para

public class Aluno extends Usuario{
     ...
}

E isso porque foram concebidos para este universo, não para este tipo de relação.

Dá pra desmontar um objeto em tabelas como dá para desmontar um objeto em structs. É prático? Não. Fácil? Não. Seria melhor se tudo fosse OO.

Argumento complicado… tem tanta coisa em CLIPPER por aí, conheço sistemas enormes sendo criados em COBOL…

Uhm… por que bancos de dados OO não deram certo?

Cada linguagem implementa objetos de um modo. Objetos sempre irão incluir os métodos/funções-membros, estes serão implementados na linguagem usada. Comof azer um subsistema armazenar objetos implementados em tantas linguagens possíveis e que possa ser utilizado com um simples driver, como o ODBC/JDBC?

Alguma IDL tipo CORBA? Talvez, mas como o objeto seria criado? Eu crio o objeto em java e o OODBMS transforma em sua própria linguagem?

“Marcos Ortega”:

Penso que por definição “Banco de Dados” armazena, recupera e HOJE até PROCESSA dados com muita eficiencia. Eles são especialistas nisso, os bancos de dados são especialistas em tarefas relacionadas a dados.

E quais tarefas em um programa não estão relacionadas a dados? Abaixo às linguagens e viva o T/SQL, PLSQL, PQP SQL!!! Tudo é dado, cara, como algo não estaria no escopo do SGBD então?!?

O papel do SGBD é armazenar dados. Transformar o SGBD em um super-servidor-faz-tudo é, no mínimo, voltar muitos anos atrás na engenharia.

[]s