Nous avons eu un peu de discussions parmi notre groupe de développement sur la question de savoir si la composition des entités doit piloter la conception de la base de données ou si la base de données conçoit la composition de la composition des entités.
Pour ceux qui ont traité cela, quelle a été votre philosophie? Bien sûr, toutes les cartes d'entité 1: 1 à une table de base de données. Mais pour ceux qui font, comment avez-vous géré cela? Iow, qui vient en premier, la table de base de données, puis une entité correspondante ou une entité, puis une table de base de données pour la persister?
Merci.
3 Réponses :
Je dirais que vous construisez votre modèle de données logique et construisez la base de données et les objets correspondant à cela.
En fait, je voudrais remettre en question l'hypothèse que la table de base de données et les entités correspondantes ne peuvent pas correspondre. Je n'ai rarement jamais vu un cas où ils ne pouvaient vraiment pas (si vous construisez une application à partir de la terre). En outre, je dirais que chaque fois que le modèle d'objet et le schéma de base de données ont divergé, il a introduit de nombreux problèmes.
Je suis revenu à l'idée de ce que tout est plus simple si vous les faites toujours correspondre, mais hérétique qui pourrait être.
Je n'ai pas encore vu une traduction directe d'un lien (plusieurs à plusieurs). Généralement, ils sont mis en œuvre sous forme d'attributs de vecteurs / arraylistes de l'objet principal plutôt que de leur propre classe.
@OMG Poneys: Il n'y a pas de traduction directe d'une table d'association car la table d'association n'est pas une partie de première classe du modèle d'entité. La table Extra Link fait partie d'un piratage standard pour que le modèle relationnel représente des relations d'objet plus sophistiquées.
@ S.Lott: Ils sont appelés bases de données "relationnelles", non "objet orienté". Les tables de liaison ne sont pas des entités commerciales, mais la mappage de vecteur / arraylist / collection / etc. est toujours un objet équivalent objet.
"Entity puis une table de base de données pour la persister"
L'entité est ce que votre programme manipule. C'est l'essence de ce qui est traité.
La représentation de la base de données de cette entité (comme des représentations de fichiers plats ou des représentations d'interface graphique) ne sont que des représentations pratiques de l'entité.
Vous devrez peut-être réfléchir un peu à la représentation de la DB lorsqu'il s'agit de certaines choses que les bases de données relationnelles sont particulièrement mauvaises. Des relations nombreuses à plusieurs, par exemple, nécessitent l'introduction d'une table supplémentaire car la base de données a des limitations que votre modèle d'objet n'a pas. Vous pouvez avoir des considérations de conception de l'entité pour faire face à cela, mais ces quelques-uns et bien compris.
La base de données est moins importante.
Les définitions d'entité sont centrales et essentielles.
Perspective intéressante. Les opinions sur cela semblent être surtout sur la carte. Le père de Orm, le Dr Raymond Chen, sur lequel Llblgen est construit, prend le point de vue direct de la vue. La base de données conduit les entités. Voir: wagnerblog.com/2009/10/...
@Randy Minder: C'est une logique simple. Le programme d'application fait en réalité le travail réel du système actuel. Tout le reste est la présentation ou la persistance. Les références Chen sont très difficiles à suivre. L'entrée de wagnerblog précédente fait référence à Peter Chen. Le blog de Raymond Chen ne mentionne pas beaucoup d'or. Comme une question pratique, les objets importent; La base de données est juste persistante.
Je suis également d'accord avec cette réponse. Un autre aspect important est que le schéma de base de données ne contient que certains aspects liés à l'opération d'entité attendue, c'est-à-dire de toute façon besoin d'annotations supplémentaires décrivant des choses telles que le chargement paresseux, le comportement de l'association, etc. Le fait que la base de données vit généralement plus longtemps que l'application ne signifie pas que vous devez la concevoir en premier, si l'outil permet de le générer simplement. Je regarde donc également la base de données comme sur une représentation de stockage particulière.
La base de données est capable de plus que la persistance. Les règles commerciales peuvent être implémentées, les données peuvent être contraintes ... La prestation signifie le déchargement des frais généraux de l'application, ce qui ne peut pas concurrencer le traitement de la base de données. La centralisation des règles commerciales de la base de données facilite le développement des autres langues - il y a moins de réinventer.
@OMG Ponies: Certaines bases de données peuvent être capables d'avoir une logique d'application poussée dans la base de données elle-même. Certains soutiennent que c'est une bonne chose. Il rend votre application confuse (certaines pièces sont du code réel, certaines pièces sont stockées des procédures). Cela rend également les choses généralement plus lentes. Essayez un repère. Les procédures stockées ne sont pas intrinsèquement rapides; Ils sont généralement un lavage. Faites la conception proprement autour des objets de modèle. Mettre en œuvre SP uniquement lorsque vous pouvez Prouvez qu'ils améliorent les performances.
Certains? DB2, Oracle, SQL Server, MySQL, Postgres ... éventuellement Derby & HSQL - DBS embarqués sont moins probables - SQLite ne ferait pas bien. Procédures stockées sont Code - par votre logique, JavaScript / Ajax n'est pas un "code" non plus parce que ce ne serait pas .net ou java. Ils sont tous composants de code de l'application. En ce qui concerne plus lentement, une DB peut trier une collection beaucoup plus rapide et plus évolutive que toute langue 3ème génération. Et, une requête n'est aussi bonne que les données - si le modèle de données est nul, vous êtes laissé avec de nombreux hacks en raison d'être codé dans un coin. J'ai réitéré - les décisions de conception médiocres vous feront souffrir.
@OMG Ponies: SP est le code - jamais dit autrement - s'il vous plaît lisez attentivement. SP est déroutant parce que le code est réparti. Ajax est le même problème. Le code est réparti. DB ne peut pas trier plus rapidement. S'il vous plaît mesurer cela.
Vos commentaires indiquent: Certaines pièces sont du code réel, certaines pièces sont stockées des procédures . Vous discrivez clairement entre les fonctions de base de données et les procédures stockées vs "code réel". Le code est également "étendu" dans des packages, des API, etc. Le manque de familiarité et / ou de confort ne signifie pas que la base de données a des lacunes. Pour une profession qui est fier de l'apprentissage de nouvelles langues et de tels, je suis surpris par la peur apparente de SQL.
@OMG Poneys: SP est le code. Ils sont codes au mauvais endroit. Ils ne sont pas comme des API de bibliothèque car ils font partie d'une application, ne stockent pas avec le reste du code. Je ne crains pas SQL ou SP. Je déclare les faits comme je les ai vécus. (1) Ils ne sont pas comme par magie plus vite. (2) Ils ne sont pas magiquement plus maintenus. (3) J'ai vu des clients dans des ennuis profonds à cause de SP. (4) J'ai aidé les clients à réécrire les applications car les SP étaient si cassés qu'elle n'a pas pu être maintenue. Ils ne devraient être utilisés que lorsqu'ils peuvent être prouvés pour améliorer les performances.
@OMG Ponies: Après 30 ans dans l'entreprise (dont 8, j'étais un dba Oracle), je pense que mon avis pourrait être basé sur plus que la peur. Il peut s'agir de mauvaises expériences en train de basculer l'échelle vers la conception de l'objet en tant que primaire et de base de données comme des procédures de persistance et stockées telles que (1) une source tangible de problèmes très réels et (2) une solution à très peu de problèmes architecturaux.
Il est temps de jouer la carte d'expérience, plutôt que des problèmes pertinents hein? Avec cette grande expérience (y compris être un DBA), je vous attendrais à ce que vous puissiez reconnaître que le modèle de données est le fondement de ce que vous pouvez faire dans une base de données. S'il n'y a pas de clés principales, aucun index, aucune contrainte relationnelle - vous pouvez également utiliser un fichier plat. Toutes les situations que vous décrivez sont symptomatiques de modèles de données médiocres - une conception médiocre dans l'ensemble. Pour toutes vos années d'expérience, il est évident que ce n'étaient pas des années passées à travailler avec les applications d'échelle d'entreprise.
@OMG Ponies: Le modèle d'objet est la base. Il a plusieurs représentations. Touches principales, aucun index, aucune contrainte relationnelle ne convient à ajouter à la mise en œuvre relationnelle du modèle d'objet. Personne n'a dit de les omettre. Les procédures stockées sont la seule chose qui cause des problèmes. Je déclare les faits comme je les ai vécus. (1) Ils ne sont pas comme par magie plus vite. (2) Ils ne sont pas magiquement plus maintenus. (3) J'ai vu des clients dans des ennuis profonds à cause de SP. (4) J'ai aidé les clients à réécrire les applications car les SP étaient si cassés qu'elle n'a pas pu être maintenue.
Règles commerciales Sont la fondation - les objets apparaissent de leur part. Les objets existent logiquement dans la base de données comme entités, physiquement, elles sont des tables. Je n'ai jamais dit que SPS était une balle d'argent, mais que ce que vous décrivez est symptomatique de la conception fondamentalement médiocre. Seulement examiner les questions relatives à la base de données sur le fait de savoir que les personnes peuvent écrire de mauvaises requêtes - c'est un manque d'expérience et / ou de compréhension, et non une mauvaise performance de la base de données.
@OMG Poneies: Les entités commerciales sont représentées par un modèle d'objet qui inclut le traitement ("Règles commerciales") et des attributs standard ("données pouvant être persistées"). Vous pouvez la mettre en œuvre en le dispersant dans la base de données, les procédures stockées et le code d'application en dehors de la base de données. Ou vous pouvez créer un modèle d'objet qui encapsule tout et est persisté à travers l'ormes. Mon expérience est que le modèle d'objet devrait venir avant la conception ORM.
Votre base de données survivra prob probablement à toute application que vous construisez aujourd'hui. Toutes les performances et l'évolutivité vont être pilotées par votre schéma de base de données. Un modèle de base de données sonore est la base sur laquelle une application est construite et je dirais que vous devez investir la plupart des efforts en matière de conception et de test, car il donnera les avantages les plus importants.
Cela étant dit, bien sûr, votre demande préférera manipuler les entités de domaine et manipulera les entités non naturelles motivées par la théorie relationnelle par opposition aux entités commerciales pour compliquer les choses. Mon point de vue est que le rôle de l'ORM correspond à la correspondance des deux, le mieux possible. Mais chaque fois que des conflits inévitables apparaissent, le droit de passage doit être donné par le facteur de conduite de votre performance et de votre évolutivité: le schéma de base de données.
@Remus - Je pense que c'est une très bonne perspective, et une fois que je n'avais pas vraiment pensé. La base de données et les données de celui-ci surviennent probablement aux applications initiales qui persistent les données. Et cela sera potentiellement utilisé de nombreuses manières autres que l'application qui persiste ses données.
La même question: