você pode representar um objeto de aplicação de uma forma que um banco de dados relacional pode entender?

votos
2

Bill Karwin tem um post chamado Por que você deve usar um ORM ? que está sendo discutido no Reddit e eu estava confuso sobre um par de pontos.

Nela, ele diz na seção de comentários:

OODBMS e ORM funciona somente em objetos que já instanciado na camada de aplicação. Ou seja, não há nenhuma maneira de fazer uma consulta como esta:

Erros atualização de status = 'FECHADO' WHERE status = 'aberto';

Para fazer isso em um ORM ou um OODBMS, você teria que buscar todos os erros que correspondem aos critérios e instanciar objetos para eles. Em seguida, você pode definir o atributo e salvar os objetos de volta para o banco de dados, um por um. Isso é caro e, certamente, requer mais código do que a operação SQL equivalente mostrado acima.

Isto ilustra uma vantagem de uma linguagem como SQL que trata conjuntos como um tipo de dados de primeira classe. O paradigma OO não pode substituir o paradigma relacional em todos os casos. Existem algumas operações comuns que SQL pode fazer muito melhor.

I em negrito a parte onde ele diz que você tem que instanciar objetos para estes erros quando você usa um ORM, porque essa é a parte que eu estou confuso sobre.

Minha pergunta é por que você precisa? Ok,-orientado a objeto é uma coisa e relacional é outro. Mas é realmente verdade que eles são tão diferentes que não há nenhuma maneira para representar um objeto para que ele possa ser entendido pelo banco de dados relacional? Por exemplo, eu estou pensando sobre como você pode serializar um objeto e, em seguida, ele é escrito em um formato de arquivo armazenável. Você não pode usar um formato como que para transferir o objeto para um banco de dados relacional?

Publicado 26/08/2009 em 23:07
fonte usuário
Em outras línguas...                            


3 respostas

votos
3

é [há] nenhuma maneira de representar um objeto para que ele possa ser entendido pelo banco de dados relacional?

Você perdeu o ponto de minhas declarações. Eu não quis dizer que não se podia armazenar um objeto em um banco de dados relacional. Eu quis dizer que o paradigma OO assume que você tem uma instância desse objeto no espaço de aplicação . Ou seja, você pode chamar métodos e propriedades de acesso de um objeto:

$bug->status = 'CLOSED';
$bug->save();

Mas em qualquer ORM Eu vi * , você não pode operar em uma instância de objeto sem antes buscar-lo do banco de dados. Também não se pode operar em conjuntos inteiros de linhas de cada vez, como você pode com SQL.

Seria interessante ver um pacote de ORM que teve um mapeamento de tipo de objeto a um conjunto de dados. Então, quando você alterar um atributo, aplica-se a todas as linhas em que set. Eu não vi qualquer tentativa ORM para fazer isso.

Seria muito difícil, por causa de problemas de concorrência. Será que o conjunto incluir linhas que estavam nesse conjunto quando instanciado o objeto, ou quando você executar a mudança, ou quando você salvar as alterações? Se ele suporta todas estas permutações como opções, em seguida, ele começa a ficar tão complexo de usar que se pode, com razão, acho que ela representa nenhuma melhoria real sobre usando SQL diretamente.

Re seu comentário: Não é que define e objetos são incompatíveis. Um conjunto pode ser um objeto (Java ainda tem classes para Recolha e Set). Mas o paradigma OO assume operações aplicam-se a uma instância do objeto, enquanto operadores relacionais sempre se aplicam a conjuntos (um conjunto de uma linha ainda é um conjunto). E, na realidade, pacotes de ORM que existem hoje fazer a mesma suposição, que se pode mudar apenas uma instância de uma linha de cada vez, e você deve ter buscado essa linha antes que você pode mudá-lo.

É possivelmente em teoria para expandir as capacidades de um ORM para trabalhar em conjuntos - mas AFAIK ninguém tentou fazer isso. Minha alegação é que um ORM que poderia fazer tudo o que operadores relacionais pode fazer seria muito pior para usar do que SQL.

* Eu estou excluindo pseudolanguages SQL-like como HQL, que acontecerá a ser parte de um pacote ORM (Hibernate no caso de HQL), mas que pseudolanguage em si não se qualifica como um ORM.

Respondeu 26/08/2009 em 23:18
fonte usuário

votos
1

O objetivo fundamental de um ORM é converter dados de uma representação para outra; o tom de sua citação é que SQL é mais adequado para batch-obra, o que é verdade - desde o ORM iria converter as tabelas de dados relacionais de se opor gráficos, em seguida, volta para as tabelas.

A (muito solto) analogia está tendo uma cuba de polpa que deseja corante vermelho. Se o IVA representa o banco de dados SQL que você simplesmente despejar o corante e mexa. Usando um ORM seria como a conversão da celulose em papel, morrendo as folhas individuais, em seguida, re-formação de pasta do papel (agora cor) para colocar de volta na cuba.

Respondeu 26/08/2009 em 23:15
fonte usuário

votos
1

ORM de mapear o estado de objetos para um estado equivalente no banco de dados. Então, se você quiser alterar o estado de algo no banco de dados usando ORM , o único mecanismo que você tem disponível para você é a primeira a manipular os objetos representados pelo banco de dados, e depois salvar seu estado.

Eu não tenho certeza que você entende por:

Estou pensando em como você pode serializar um objeto e, em seguida, ele é escrito em um formato de arquivo armazenável. você não pode usar um formato como que para transferir o objeto para um banco de dados relacional?

Você quer dizer serializar um objeto em uma estrutura que você pode armazenar principalmente em um arquivo simples (por exemplo, um formato XML), e, em seguida, armazenar os dados no banco de dados? Se assim for, sim, você poderia. O desafio seria quando você deseja procurar essa informação. Digamos que você queria encontrar todos "fechado" erros, você teria que ler cada bug, desserializá-lo e examinar seu status para ver se ele deve ser incluído na lista.

Respondeu 26/08/2009 em 23:12
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more