Banco de Dados Orientado a Objetos - por que a maioria das empresas não os utiliza [fechado]

Question

Sou muito novo em programação (acabei de terminar a universidade).

Tenho pensado nos últimos 4 anos sobre o desenvolvimento Orientado a Objetos e as inúmeras vantagens desta abordagem.

Minha pergunta é

Não é mais fácil usar um banco de dados puro orientado a objetos em aplicações de desenvolvimento?

Por que os bancos de dados orientados a objetos não são tão difusos quanto relacionais?

Do meu ponto de vista faz sentido utilizar banco de dados OO, este último evitará as inúmeras construções necessárias para o mapeamento de objetos complexos nas tabelas.

Answer 1

Tendo trabalhado para uma empresa de banco de dados orientada a objetos no passado (www.objectstore.com) - E atualmente - acho que tenho uma visão justa do que os torna ótimos e o que os torna tão suficientes.

Excelente:

Nenhuma incompatibilidade de objetos-relatórios. Se você deseja armazenar o objeto X na memória em uma loja persistente, o ObjectStore pode fazê-lo com garantias de quase tempo. Nosso produto tem sido usado por muitas empresas para atender aos requisitos de tempo brutais que seriam difíceis com bancos de dados de relação ou motores ORM.

Nenhuma incompatibilidade de objetos -relatórios - você se desenvolve em objetos, pensa em objetos, armazena em objetos.

Não tão grande:

ORM: os gerentes relacionais de objeto tornaram irrelevantes os bancos de dados de objetos

Evolução do esquema: altere uma classe para adicionar um campo e agora você precisa transformar um banco de dados inteiro. O ObjectStore ficou mais inteligente sobre isso ao longo dos anos, mas ainda é um ponto de dor para muitos OodBMs.

Mau:

Suporte à ferramenta - Foi isso que fez do OODBMS um não iniciante para a maioria dos lugares. Hoje, todos podem tomar relatórios de cristal ou acessar ou se destacar e agitar cargas de relatórios. Com um OODBMS, você teria que criar essa lógica através de um programador, e todos sabemos o quão rápido isso provavelmente acontecerá quando você precisar do seu relatório de orçamento para levar em consideração um parâmetro XYZ que você não pensa no tempo de design.

As ferramentas são o motivo pelo qual o OODBMS falhou no mercado. Não superioridade técnica ou desempenho ou suporte ao idioma (o ObjectStore suporta C ++/Java/.NET e teve suporte para o COM para suportar quaisquer idiomas do IDISPATCH como VB, Perl, etc.).

Então, eu disse algumas coisas depreciativas aqui, principalmente sobre um produto que eu realmente gosto. Mas o ObjectStore é incrível em tarefas muito específicas, mas uma má escolha para a criação de um webapp. Embora em um ponto, estava impulsionando o back -end do gerenciamento de inventário para Amazon.com.

Answer 2

Como você afirma, você acabou de sair da faculdade e acaba de ser intensamente doutrinado no Único Caminho Verdadeiro (Orientado a Objetos).Se, por outro lado, você tivesse aprendido programação declarativa, design de banco de dados e teoria dos conjuntos, perceberia que o modelo relacional é uma abordagem perfeitamente adequada, bem fundamentada na teoria, enquanto OO é uma abordagem mais pragmática que foi inventada principalmente na indústria. em vez da academia.Na verdade, a pesquisa e o desenvolvimento mais interessantes sobre problemas de banco de dados estão sendo feitos por pessoas com mais experiência em matemática, para quem o modelo relacional é a maneira mais natural de trabalhar com dados.Como resultado, os RDBMSs tendem a ser mais estáveis, escaláveis ​​e confiáveis ​​do que seus equivalentes orientados a objetos.Bancos de dados orientados a objetos, assim como XML, são frequentemente usados ​​em uma tentativa imprudente de fazer com que os dados estejam em conformidade com os programas que os utilizam, e não o contrário.

Answer 3

Não há vantagens em usar essa abordagem quando você já tem um banco de dados relacional com muitos gigabytes de tamanho, que já armazena 20 anos de dados e tem centenas ou milhares de tabelas.Este é o mundo real de muitos aplicativos de negócios.Os bancos de dados são usados ​​para muito mais do que mapeamento de objetos de seu aplicativo específico.O banco de dados ainda existirá muito depois que os aplicativos que você escreve desaparecerem.Aproveite e aprenda sobre bancos de dados relacionais, pois eles não irão desaparecer nos próximos 100 anos.

Answer 4

Há dez anos, olhei para o design de banco de dados orientado a objetos (para um projeto pessoal) e descobri que eles não eram muito bons em fazer certos tipos de pesquisas com facilidade ou rapidez (digamos "Encontre todas as pessoas cujo sobrenome começa com 's'), Embora, é claro, haja muitas consultas relacionais que não são necessárias em um banco de dados orientado a objetos. Além disso, na época, o banco de dados orientado a objetos não estava realmente pronto para implantação em larga escala (o que não era uma preocupação minha). Eu Acredite que os mais novos corrigiram esse problema, mas ainda há muita intertia e o Orm's faz o uso de um banco de dados relacional relativamente fácil.

No entanto, há um movimento longe dos bancos de dados relacionais, veja O movimento NOSQL. Acredito que o Google não use um banco de dados relacional (mas também não é orientado a objetos, mas algo proprietário e distribuído).

Answer 5

Desculpas por não poder adicionar isso como um comentário no local onde realmente deveria aparecer.

Mas o seguinte constitui um ataque pessoal em mim, e eu invoco meu direito de responder.

Embora eu concorde com você na prática, eu discordo de você em espírito, acho que você é quem sofreu uma lavagem cerebral em acreditar que baseado em conjuntos é a única maneira (talvez eu esteja colocando palavras na sua boca).

FWIW, certamente não fui "lavado" no que você provavelmente pode chamar de "crença religiosa relacional". A lavagem cerebral é quando algum tutor diz algo, e o aluno aceita cegamente e sem cérebro isso como a única verdade sem qualquer forma de pensamento crítico. Na verdade, nunca aprendi o modelo relacional. Na verdade, tive que descobrir tudo isso sozinho. De fato, é de fato que eu expressei críticas graves em relação às opiniões de Date sobre o assunto da atualização. (Correção: "era" uma questão de fato registrado. A página parece ter sido removida do site onde foi publicado. Provavelmente tem tudo a ver com o fato de que a data realmente abandonou a posição de atualização da exibição que critiquei.)

Então, acho que tenho todos os motivos para dizer que qualquer alegação de que eu me deixasse lavar o cérebro é proposta. Você é livre para pensar como quiser, mas se você expressa publicamente qualquer opinião pessoal gratuita e baseada em uma nada, espero que você também seja suficiente para vê-los refutados por fatos e admiti-lo.

A razão pela qual os modelos hierárquicos e de rede foram substituídos pela RM foi amplamente documentada em bibliotecas inteiras cheias de livros sobre o assunto. Convido você a inspecioná -los com cuidado.

Quanto a "Valor-chave está assumindo o mercado": você é totalmente livre para tomar "a opinião mais comum do mercado" (ou seja: a maioria medíocre dos tolos muito preguiçosos para serem os que são muito felizes deixar a si mesmos (e suas opiniões) ser liderados pelos ellisões, portões e tarefas deste mundo) como o principal critério para o que é valioso e o que não é. Pessoalmente, acho isso uma coisa tola, mas essa é apenas minha opinião pessoal. Copito aqui algumas observações feitas por alguém que enfrenta os horrores do EAV e o valor-chave quase todos os dias de sua vida profissional:

Eu trabalho em um aplicativo que usa o seguinte "modelo EAV" (pelo menos, o "modelo EAV", como eu o entendo) para muitos, mas não todas, tabelas lógicas:

R1 {EAV_RELVAR_NAME*, ... }
R2 {EAV_RELVAR_NAME*, ATTRIBUTE_NUMBER*, COLUMN_NAME, DATA_TYPE, ...}
R3 {EAV_RELVAR_NAME, ATTRIBUTE1, ATTRIBUTE2, ATTRIBUTE3, ..., ATTRIBUTE50}

Em que se pode ver os seguintes valores:

R1 { {'STATE_CODES'} }
R2 { {'STATE_CODES', 1, 'STATE_NAME', 'CHAR(30)'} ,
     {'STATE_CODES', 2, 'STATE_CODE', 'CHAR(2)' } ...}
R3 { {'STATE_CODES', 'ALABAMA', 'AL'} ,
     {'STATE_CODES', 'ALASKA',  'AK'} ...}

Basicamente, "EAV Relvars" são criados/alterados/descartados com inserções/atualizações/exclui em R1 e R2 (em comparação com o DDL). Esta é uma versão reduzida do nosso modelo geral: existem colunas adicionais em R1 e R2 para especificar EAV-Primary-Keys, EAV-Foreign-Keys, Regras de negócios, etc ... tudo aplicado pelo código processual incorporado no "Um Verdadeiro front -end "do modelo.

Hoje de manhã, eu estava a par de uma provação de mais de 20 horas de homem que resultou quando o sistema um code_xyz pensou estaria no atributo2, mas o sistema B realmente definiu no atributo3 ... eu tive que rir do fato de que estava meio que listenia para a conversa, e meio lendo o discurso deste grupo sobre Eav.

No mês passado, pude colocar uma atualização de emergência (16 horas-homem mais "Bad Marks" para o aplicativo) para alterar o atributo16 de 'maio de 2010' para 'maio-2010' para 430 pontos de dados inseridos pelo usuário.

Cerca de 5 a 10% de nossos lançamentos de código estão acompanhados de "limpeza de erro de tempo de segunda-feira na manhã", porque o EAV_RELVARS não foi codificado em R1 ou R2 de forma idêntica na produção, como foi feito em teste/desenvolvimento (o código do aplicativo e o DDL é migrado com Controle de software de verificação rigorosa ... Nosso modelo EAV não está vinculado à burocracia que "permite" desenvolvedores configurarem seus EAVs autonomamente em Dev, Test e Prod.).

No ano passado, passei um sólido software de replicação de 3 semanas, exclusivamente para lidar com a falta de uma chave primária no R3.

Uma vez tive que me desculpar pela incapacidade de colocar um índice no atributo4 de eav_relvar_name_x, pois estava atrapalhando o desempenho de um programa diferente que usava eav_relvar_name_z.

Dois anos atrás, depois de vários anos afundando centenas de horas ajustando perpetuamente consultas complexas que precisavam se juntar ao R3, finalmente passei 3 meses dividindo o R3 em centenas de partições físicas (uma por eav_relvar_name), a fim de dar ao DBMS otimizador as estatísticas Precisava ver que havia, por exemplo, 50 'State_codes' e 200.000 'location_codes'. Fiquei parabenizado pela solução engenhosa, embora a ironia tenha perdido todos quando apontei que, com essa mudança, haveria uma nova política pela qual adicionar uma nova eav_relvar_name implicaria executar um script que adicionou uma partição associada ao R3 (sim , com DDL).

Meus clientes desejam um novo front -end para carregar dados no R3 para um de seus eav_relvar_names (ao mesmo tempo em forçar todas as restrições e segurança apropriadas) e querem saber por que levará 4 meses para ser construído.

Costumo ressaltar que eu poderia reescrever todo o sistema EAV de uma maneira superior em todos os aspectos, usando o dinâmico-DDL contra o dicionário de dados em vez de DML contra R1 e R2, mas sempre estou informado de que estamos "comprometidos "Para essa abordagem (houve uma despesa inicial de 7 dígitos para construí-la, e teríamos que reescrever 98% da nossa base de código para mudar para tabelas independentes) e que os fins não justificam os meios .

Se você realmente acredita que esses cenários são uma melhoria em relação à RM, então vá em frente. Não me culpe o quanto dói quando você finalmente bate a cabeça na parede.

Answer 6

Não há uma boa razão para isso, especialmente com a revolta do uso do ORM (registro ativo) e as dores do mapeamento. Os bancos de dados orientados a objetos são mais rápidos e melhores de várias maneiras. A razão para não ser popular é necessidade. Até agora, os RDBMs têm feito um bom trabalho e, em grandes empresas, a maior dor é chamada de 'migração'. Como na maioria da tecnologia, a necessidade do usuário é o objetivo principal, e a orientação de objetos geralmente não é o ponto de venda. Velocidade, talvez, mas o hardware caro e o ajuste comprovado de RDBMs também possam alcançar o desempenho.

Além disso, as pessoas que são hábeis nessa área teriam que ser treinadas novamente (o que custa um grupo). Sem mencionar todos os consultores caros que aprenderam o mal pl/sql ...

Eu diria, seja o primeiro motor. Como Mahatma Ghandi disse, seja a mudança que você deseja ver. Engraçado, você me fez querer pesquisar no Google para um OOO-DB de código aberto.

Answer 7

Uma razão pela qual a adoção de bancos de dados orientados a objetos é tão lenta é que não existem muitas alternativas OpenSource escaláveis.Para RDBMS existem, por exemplo, MySQL (agora de propriedade da Oracle), PostgreSQL e muitos mais.

Outro problema é que pelo menos para Java as APIs padrão para acesso RDBMS JDBC e JPA para a parte ORM têm empresas maiores por trás e são mais conhecidas.JDO para acesso a banco de dados orientado a objetos é um padrão, mas não tão popular.

Os bancos de dados orientados a objetos têm, na maioria dos casos, uma API ou linguagem mais forte do que o RDBMS, o que é outra razão pela qual empresas maiores com investimentos em múltiplas plataformas e idiomas permanecem com o RDBMS.

Para mim, bancos de dados OpenSource OO populares seriam um motivo para investir mais tempo testando-os.

Answer 8

O banco de dados não se trata apenas de armazenar e recuperar objetos, caso contrário, o Oodbs e o Document DBS teriam dominado o mundo. Outros contextos / aspectos de uso incluem:

• Agregar dados e fazer processamento / manipulação complexos de dados em massa. RDBMSSes são muito bons nisso.
• Outro aspecto importante é a simultaneidade / isolamento (ou seja, transações). Os RDBMSs são muito maduros nesta área.
• Outro aspecto é a indexação para garantir consultas rápidas.
• Outro aspecto, como "Chris Kaminski", mencionado acima, é poder evoluir seu esquema ao longo do tempo, preservando os dados.

Finalmente, há um pouco de inércia da indústria, com grandes fornecedores não dispostos a apostar dinheiro em algo pelos quais os clientes não estão prontos para pagar e os clientes esperando à margem até que os principais fornecedores se juntem ao jogo.

Answer 9

Outra questão é o suporte ao idioma. E os idiomas que não são orientados para objetos? Um bom banco de dados precisa ser acessível por todos, independentemente do idioma. É por isso que muitos bancos de dados específicos de idiomas falham, porque seu mercado é apenas pessoas desse idioma.

Há também o fator de migração. Os maiores usuários do MySQL são usuários de longa data. Migrar para um sistema de banco de dados completamente novo com um design fundamental completamente diferente com um grande existente seria muito caro e daria pouca recompensa.