Por que os bancos de dados orientados a objeto não foi bem sucedido (ainda)? [fechadas]

Question

Essa é a pergunta. Dê apenas uma razão que você pensa por que OODB falhou ou porque muitos sistemas hoje em dia ainda usam bancos de dados relacionais.

Answer 1

Podemos responder a mais de uma vez? Outra razão é que o banco de dados relacional tem uma forte base em matemática: a partir da definição de uma relação, através do direito às formas normais, a teoria é rocha sólida. É verdade que o modelo relacional não mapeia bem para OO, mas IMHO os benefícios e estabilidade desse modelo superam o problema de mapeamento.

Answer 2

A principal razão é SQL. É muito útil para ser capaz de utilizar os dados a partir de um banco de dados em outros contextos fora do aplicativo, e muitas vezes com bancos de dados de objetos os dados são armazenados em um formato que não pode ser facilmente consultado. Com um banco de dados relacional os dados podem tornar-se parte de um armazém de dados, por exemplo, ou apenas consultado por sys admins etc.

Answer 3

Eu acho que é porque "banco de dados orientado a objetos" está resolvendo um problema que (quase) ninguém realmente tem. Para simples persistência de gráficos de objetos, a serialização incorporado na maioria dos ambientes OO é "suficientemente bom". Se você quer fazer operações sofisticadas em um subconjunto de seus dados, em seguida, um banco de dados relacional e SQL são um ajuste perfeito.

Além de algumas aplicações de franja (enormes gráficos de objetos que não podem ser guardados na memória, mas para o qual as relações não simplificar baixo bem para uso RDBMS), não há realmente nenhuma necessidade para essas ferramentas.

Answer 4

Só porque OODB não são o mainstream ainda devemos considerar os sucessos que eles tiveram. Cache e Zope são amplamente utilizados (relativamente), mas seria considerado bem-sucedido por alguns padrões.

Talvez a maior razão que OODB não se apoderaram dramaticamente é por causa do sucesso dos sistemas híbridos objeto-relacional que tomam a maior parte do marketshare potencial de OODB:. PostgreSQL e Informix

Eu sei que isso não respondeu diretamente à pergunta, mas é, penso eu, uma parte da equação. No geral, porém, acho que a dinâmica e os processos de pensamento fortemente enraizados que suportam bancos de dados de relações tornam difícil para as pessoas a mudar. Atualmente a profissão DB é treinado quase exclusivamente na teoria relacional fazer seus profissionais DB muito interessado em evitar OODB e academia ensina teoria DB para os profissionais quase que exclusivamente em relacional.

Até grandes, DBAs corporativos e professores tradicionais e currículo e transformar-funcionários além desenvolvedores preparados para gerenciado OODB eu sinto que é improvável para ver apelo de massa, não importa o quão bom ele é do lado do desenvolvimento.

Answer 5

Bem, é estranho não é? Não é tal empurrão a direção design orientado domínio como o auge de objeto orientado análise e design, e há padrões corporativos lá fora, para sistemas de alavancagem ORM persistir nossos objetos. Ela só faz total sentido para mim que se o design do aplicativo é objeto orientado e domínio centrada no coração, que um OODB irá beneficiar grandemente a sua aplicação.

Além das questões em torno da maturidade e absorção, a partir de uma perspectiva filosófica um OODB parece benéfica ou um aplicativo OO. não ter de manter essa camada de mapeamento para entradas;)

Mas olha, se você não está fazendo objetos de design e uso de unidade de domínio como objetos de dados e como seus procedimentos armazenados, então você não está realmente indo para obtê-lo;)

Answer 6

RDBMS estão (construída sobre uma forte base teórica, ter sido no mercado por muito mais tempo, pode modelar dados com mais fidelidade do OODBs em muitos casos, pode ser usado por mais DBAs que OODBs). Essa é uma razão na forma de uma tupla relacional.

Answer 7

Se eu pode amplificar ponto de Phil: a padronização de SQL. de OODB tentaram linguagens de consulta, como QVG mas nunca parecia seguir um verdadeiro padrão. Também a qualidade das linguagens de consulta eram suspeitos, sem dúvida, devido à falta de padronização. Padrões de concorrência Foster, que gera qualidade.

Answer 8

Uma razão é que bancos de dados são sobre dados e objetos são sobre estruturas e algoritmos. Depois de tomar os dados e incorporá-lo nas aulas, você caracterizar as relações e operações em uma estrutura estática. Bases de dados, por outro lado, são cerca de desestruturação os dados em um monte de instâncias de tabelas atômicas que podem ser reagrupados em diferentes estruturas (geralmente com aulas), sem perturbar a integridade dos átomos.

Os bancos de dados são um pouco análogo ao hexahexaflexagons.

Answer 9

Isso, e o / r-mapeadores. Através deles, a diferença para os verdadeiros OO-DBS torna-se muito menor, enquanto os benefícios acima mencionados permanecer válido.

Answer 10

decisões tecnologia cara não são feitas por pessoas com conhecimento técnico. As empresas que utilizam bancos de dados relacionais empregam muitas pessoas que se sentem ameaçados por OODBs e, portanto, evitar a aprender sobre eles.

Answer 11

Eu acho que há duas razões filosóficas.

Em primeiro lugar, as pessoas tradicionalmente tendem a persistência separado da funcionalidade real. Uma vez que você tira fora "vida" de um objeto para longe dele e mantê-lo principalmente para a persistência, torna-se um registro e, em seguida, há uma tendência de tratá-lo como um "sem vida" objeto de dados.

Na sequência disso, quando as pessoas pensam de uma grande coleção de coisas muito semelhantes, eles começam a pensar neles como tabelas em vez de objetos.

Eu acho que com O / R, a distinção está começando a desaparecer. Por exemplo, eu uso hibernate para despejar hierarquias de classe realmente complexos em um banco de dados MySQL. No entanto, eu não escrevo coisas desempenho crítico para o meu projeto para que eu tenho certeza que não é feito de forma eficiente.

Answer 12

A razão para a adoção lenta do de OODB são amplamente baseado em alguns fatores importantes que fazem os bancos de dados SQL relacional mais popular e / ou mais apropriado. Enquanto bancos de dados orientados a objetos puros estão agora em um estado onde eles superam muito das desvantagens do modelo relacional, existem algumas peças-chave ausentes.

Por um lado, eles tendem a apoiar falta de gerenciamento de banco central, embora isso rapidamente está sendo retificada em vários produtos.

A segunda razão é que muito poucos sistemas implementar uma linguagem de consulta padrão e, em vez depende da linguagem de programação ou linguagens de consulta especializados para obter e manipular os dados na loja. Este é um show rolha para muitos, se eles têm que aprender uma nova linguagem de consulta em cima da mentalidade totalmente diferente de um programador usado para soluções baseadas NoSQL. Além disso, a maioria dos SQL Técnicos / Bancos de dados relacionais têm agora algum suporte para Object Oriented design, e ainda temos wrappers como ORM que muitos usam para "ignorar" os problemas de bancos de dados relacionais não sendo prontamente disponíveis na linguagem de programação de escolha.

Mas estes problemas existem principalmente em ambientes corporativos. Como bancos de dados incorporados em dispositivos pequenos, como o armazenamento de web site e em áreas como aeroespacial tornaram-se muito popular e em muitos casos substituiu totalmente a necessidade de bancos de dados relacionais regulares.

Quem sabe o que o futuro nos reserva?

Answer 13

A serialização fornecido pela maioria de Idioma permite flaten os atributos de objeto e, assim, armazenar facilmente-los para o RDBMS e similarmente recuperar objetos não é um grande problema. A fundação ampla e sólida ainda não tem o que dificulta o uso de OODBMS a ser implementado.

Eu atualmente pensando em fazer isso como a minha tese de mestrado projeto para fornecer um quadro geral de OODBMS que suporta quase todos os componentes que é comumente usado em agora um dia RDBMS proporcionando assim um não-linear DBMS estruturados. Enquanto estudava me deparei com um projeto chamado db4o que é uma abordagem (implementado) de usar OODBMS para Java e .net somente, assim que este poderia ser outra razão da falta de generalidade para todos os tipos de plataformas e linguagens.

Answer 14

Eu acho que é porque grandes caras como Oracle tinha sido investir em bancos de dados relacionais, enquanto objeto movimento orientado estava recebendo impulso ... pode ser que eles vão se tornar mainstream se Oracle / Microsoft investir nele em grande forma ... o que parece improvável porque eles não têm uma forte razão para fazê-lo ... ele irá simplificar a vida de muitos programadores ... mas "fazendo programadores vidas mais simples" não é um objetivo de negócio muito bom para eles!