Pouvez-vous représenter un objet d'application d'une manière qui peut comprendre une base de données relationnelle?

voix
2

Bill Karwin a un billet de blog intitulé « Pourquoi devriez - vous utiliser un ORM ? » qui est en cours de discussion sur Reddit et je suis confus au sujet de quelques points.

Dans ce document, dit-il dans la section des commentaires:

SGBDOO et ORM ne fonctionne que sur des objets que nous avons instancié dans la couche d'application. -À-dire qu'il n'y a pas moyen de faire une requête comme celle-ci:

MISE À JOUR Bugs état SET = « fermé » où le statut = « OUVERT »;

Pour ce faire , dans un ORM ou un SGBDOO, vous auriez à chercher tous les bugs qui correspondent aux critères et objets instancier pour eux. Ensuite , vous pouvez définir l'attribut et enregistrer les objets revenir à la base de données un par un. Ceci est coûteux et nécessite certainement plus de code que l'opération SQL équivalent indiqué ci - dessus.

Ceci illustre un avantage d'une langue comme SQL qui traite des jeux comme une première classe type de données. Le paradigme OO ne peut pas se substituer au paradigme relationnel dans tous les cas. Il y a quelques opérations ordinaires que SQL peut faire beaucoup mieux.

Je la partie où est indiquée en gras, il dit que vous devez instancier des objets pour ces bugs lorsque vous utilisez un ORM parce que c'est la partie que je suis confus au sujet.

Ma question est pourquoi vous devez? D' accord, orienté objet est une chose et relationnelle est une autre. Mais est - ce vraiment vrai qu'ils sont si différents qu'il n'y a aucun moyen de représenter un objet afin qu'il puisse être compris par la base de données relationnelle? Par exemple, je pense à la façon dont vous pouvez sérialiser un objet, puis il les écrit dans un format de fichier stockable. Ne pourriez - vous utiliser un format comme celui de transférer l'objet à une base de données relationnelle?

Créé 26/08/2009 à 23:07
source utilisateur
Dans d'autres langues...                            


3 réponses

voix
3

est [il] aucun moyen de représenter un objet afin qu'il puisse être compris par la base de données relationnelle?

Vous avez manqué le point de mes déclarations. Je ne voulais pas que l' on ne pouvait pas stocker un objet dans une base de données relationnelle. Je voulais dire que le paradigme OO suppose que vous avez une instance de cet objet dans l' espace d'application . Autrement dit, vous pouvez appeler des méthodes et des propriétés d'accès d'un objet:

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

Mais dans tous les ORM que j'ai vu * , vous ne pouvez pas fonctionner sur une instance d'objet sans avoir d' abord aller chercher à partir de la base de données. Et vous ne pouvez fonctionner sur des jeux complets de lignes à la fois, que vous pouvez avec SQL.

Il serait intéressant de voir un ensemble ORM qui avait un mappage de type d'objet à un ensemble de données. Ensuite , lorsque vous modifiez un attribut, il applique à toutes les lignes de cet ensemble. Je ne l' ai pas vu toute tentative ORM de le faire.

Il serait très difficile, en raison de problèmes de concurrence. L'ensemble comprend des lignes qui étaient dans cet ensemble lorsque vous instancié l'objet, ou lorsque vous exécutez le changement, ou lorsque vous enregistrez les modifications? Si elle prend en charge toutes ces permutations que les options, il commence à devenir si complexe à utiliser que l'on pourrait penser à juste titre qu'il ne représente aucune amélioration réelle sur l'utilisation directement SQL.

Re votre commentaire: Ce n'est pas fixe et les objets sont incompatibles. Un ensemble peut être un objet (Java a même des cours pour la collecte et Set). Mais le paradigme OO suppose des opérations s'appliquent à une instance d'objet, alors que les opérateurs relationnels appliquent toujours à des ensembles (un ensemble d'une ligne est encore un ensemble). Et en réalité, les paquets ORM qui existent aujourd'hui font la même hypothèse, que l' on peut changer une seule instance d'une ligne à la fois, et vous devez avoir récupéré cette ligne avant de pouvoir le changer.

Il est peut - être en théorie pour développer les capacités d'un ORM à travailler sur des jeux - mais autant que je sache , personne n'a essayé de le faire. Ma demande est qu'un ORM qui pourrait faire tout ce que les opérateurs relationnels peuvent faire serait bien pire à utiliser que SQL.

* J'excluais pseudolanguages de type SQL comme HQL, qui arrivent à faire partie d'un ensemble ORM (Hibernate dans le cas de HQL) , mais que pseudolanguage lui - même ne constitue pas un ORM.

Créé 26/08/2009 à 23:18
source utilisateur

voix
1

Le but fondamental de l'ORM est de convertir les données d'une représentation à l'autre; le ton de votre citation est que SQL est mieux adapté pour le travail par lots, ce qui est vrai - depuis le ORM convertirait les tables de données relationnelles pour objet graphiques puis de nouveau aux tables.

Une analogie (très lâche) est d'avoir une cuve de pâte que vous voulez colorant rouge. Si la cuve représente la base de données SQL que vous souhaitez simplement vider le colorant et lui donner un émoi. L'utilisation d'un ORM serait comme la conversion de la pâte en papier, en train de mourir les feuilles individuelles, puis repulpage le papier (maintenant de couleur) de remettre dans la cuve.

Créé 26/08/2009 à 23:15
source utilisateur

voix
1

Carte de ORM l'état des objets à un état équivalent dans la base de données. Donc, si vous voulez changer l'état de quelque chose dans la base de données en utilisant ORM , le seul mécanisme que vous avez à votre disposition est d'abord manipuler les objets représentés par la base de données, puis enregistrez leur état.

Je ne sais pas ce que vous entendez par:

Je pense à la façon dont vous pouvez sérialiser un objet, puis il les écrit dans un format de fichier stockable. Ne pourriez-vous utiliser un format comme celui de transférer l'objet à une base de données relationnelle?

Voulez-vous dire sérialiser un objet dans une structure que vous pouvez principalement stocker dans un fichier plat (par exemple un format XML), puis stocker ces données dans la base de données? Si oui, oui vous pouvez. Le défi serait quand vous voulez rechercher cette information. Dites que vous vouliez trouver tous les « fermés » bugs, vous auriez à lire chaque bogue, désérialiser et d'examiner son statut pour voir si elle doit être incluse dans la liste.

Créé 26/08/2009 à 23:12
source utilisateur

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