J'utilise des rails et cela ne fournit pas de support aux actions spécifiques à la base de données telles que des déclencheurs, des procédures stockées et diverses contraintes (pas toutes).
Je me demande si je devrais mettre la logique de la base de données dans la demande elle-même à la place.
Parce que vous pouvez faire une logique plus complexe que la base de données fournie et il est également indépendant de la base de données (je peux passer de MySQL à PostgreSQL et inversement), et ce ne sera pas si vous mettez ces éléments dans la base de données.
Est-ce la bonne façon d'aller?
merci
9 Réponses :
Généralement, oui, principalement pour les raisons que vous venez de mentionner.
Les déclencheurs sont particulièrement mauvais car il est assez opaque au développeur sur ce qui se passe dans les coulisses lorsqu'une opération est effectuée. J'ai tendance à limiter mon utilisation de déclencheurs à des fonctions d'audit ou de fonctions incroyablement importantes pour protéger l'intégrité des données du système. J'évite presque entièrement d'utiliser des déclencheurs pour la logique d'application.
Même chose avec les procédures stockées. En ce jour et Âge avec des ormes étant si répandis, j'utilise des Procs stockés pour de grandes modifications de données basées sur les performances dont la performance serait indésirablement mauvaise lorsque vous utilisez un orj tel que des rails, ce qui nécessite de lire les données de la base de données et de la maréchal. Retour au calque de base de données une fois que vous avez terminé le traitement.
(Remarque: Ceci est un post central Postgres. J'ai plusieurs années d'expérience avec MySQL et quelques postgres et Oracle. Je préfère postgres par un mile de pays, mais ce n'est pas le point de ce post.)
C'est vraiment une question sur deux écoles de pensée: la base de données devrait-elle être un simple magasin de données ou s'il doit contenir une logique d'application? Il y a des cas pour les deux.
IMHO La réponse était beaucoup plus simple avant que plusieurs DBS (ESP Postgres) obtiennent des très bonnes langues procédurales dans la DB elle-même. Avant ce point, il était logique de frapper toute la logique que vous pourriez dans la demande, car il devait s'agir plutôt de kludgey d'avoir certaines choses faites dans SQL de base.
Dave Markle dans une autre réponse fait un bon point sur les déclencheurs, ils ont tendance à être "magiques" au développeur. Changer d'entrée sur le chemin peut être terriblement déroutant. Si je dis Procédures stockées - Je tiens à un respect beaucoup plus élevé. Le développeur les invoque explicitement et ils sont nommés, il ne devrait donc pas les voir comme une boîte noire. Une bonne procédure stockée peut considérablement augmenter la vitesse en réduisant le nombre de lignes qui doivent être «envoyées sur le fil». Pour une DB telle que Postgres avec un ensemble puissant de PL Langauges, il n'y a vraiment rien qui ne peut être dans un SP (cela ne signifie pas que cela devrait être fait, mais peut être). Jetez un coup d'œil à SimplyCity pour un exemple de la manière dont les procédures stockées peuvent être votre ami. De plus, vous pouvez partager des classes de logique d'application entre votre code d'application et PL / Python, PL / PERL ou PL / PHP, PL / RUBY ou PL / JAVA. Je crois que Oracle peut faire quelque chose de similaire avec Java - ce n'est tout simplement pas quelque chose que l'entreprise que je fais actuellement Oracle Work pour travaille avec.
Si vous envisagez de rester à la base de données agnostique, vous allez sacrifier beaucoup de fonctionnalités, beaucoup de vitesse et beaucoup de votre temps. Les ormes peuvent rendre cela plus facile, mais il est finalement une différence fondamentale dans la plupart des moteurs de bases de données qui ne peuvent tout simplement pas être complètement résumés.
Globalement, vous devez tester, tester, tester (avec des données réelles) et prendre la décision meilleure pour votre application. C'est souvent un acte d'équilibre entre la performance, l'entretien futur, le coût et les ressources dont vous disposez à travailler. souvent les temps (pas à chaque fois), déplacez la logique de la base de données et dans l'application réduit considérablement les performances de l'application.
Même si vous ne décidez pas de mettre la logique de l'application dans la DB - prenez le temps de découvrir vraiment votre DB de choix. Il vous fera un meilleur développeur d'applications à long terme. update foo set x = 3; mais je vais vérifier foo et x est vraiment 4 parce que Certains déclencheurs l'ont intercepté, cela peut être déroutant. Comme Dave, j'ai tendance à promouvoir des déclencheurs pour les fonctions d'audit et autres. L'autre problème avec les déclencheurs est la performance, ils peuvent simplement sucer la vie à partir d'une bonne opération de lot.
Oracle prend en charge les procédures stockées Java, mais personne ne les utilise parce que tout dans le monde Oracle est orienté vers PL / SQL.
+1 pour "Prendre le temps de vraiment apprendre de votre dB". Il me frotte le mauvais moyen lorsque les gens n'apprennent pas la technologie qu'ils choisissent.
Si vous utilisez déjà Ruby sur Rails, vous vous êtes engagé à utiliser des logiciels d'opinion. L'opinion des rails à peu près ou à tort est que la logique passe dans l'application Rails. Cela le prend même en ce qui concerne l'application de l'intégrité référentielle elle-même via Aciverecord et ses associations, bien que vous puissiez bien appliquer cela dans la base de données si vous le souhaitez en ajoutant des contraintes à vos tables. Beaucoup de développeurs de rails ne dérangent pas, ni par l'ignorance ni le choix.
Je dirais que si vous utilisez MySQL, vous vous engagez deux fois à la même école. Je préfère utiliser un SGBD de fonctionnalités complètes, un framework / orm plus flexible (avec une mappeuse de données par exemple) et déplacez la ligne chaque fois que je veux. Mais cela dépend aussi du type d'application.
C'est exact. Avec des rails, vous vous êtes engagé à logiquer dans l'application. Et c'est là que les gains productifs entrent, car vous ne dépensez aucun moment de développement déterminant et évaluez les différentes manières «celles-ci pourraient être mises en œuvre» ou «qui pourraient être mises en œuvre». Rails dit "Faites-le de cette façon", "Séjournez sur les rails prédéfinis" et obtenez la seule chose de la porte ... Commencez à ajouter de la valeur commerciale et arrêtez de vous échapper (jeu de mots) sur ces shenanigans.
Parce que vous pouvez faire une logique plus complexe que la base de données fournie et il est également indépendant de la base de données (je peux passer de MySQL à PostgreSQL et inversement), et ce ne sera pas si vous mettez ces éléments dans la base de données.
La logique dépend de la base de données - MySQL par exemple n'a pas de support de requête récursif, ni de fonctions analytiques. PostgreSQL n'a que Analytics récemment - SQL Server avait les deux depuis V2005; Oracle depuis 9i.
Logique de base de données Dans l'application, c'est plus de voyages entre l'application et la base de données - c'est temps / performance que vous ne récupérerez jamais. Les voyages de base de données coûtent cher et être tenu aussi peu que possible, c'est pourquoi les procédures et fonctions stockées sont vos meilleurs outils pour une couche de persistance performante hautement évolutive.
Orm est connu depuis longtemps pour être idéal pour des requêtes qui ne sont pas complexes et je suis heureux de voir qu'ils ont évolué pour soutenir à l'aide de procédures stockées / etc. ... qui vaincent complètement le but d'utiliser orm - vous revenez maintenant à la rédaction de code spécifique de la base de données pour des performances. C'est comme la blague sur la résolution de quelque chose avec une regex - vous avez maintenant deux problèmes ...
Enfin, des bases de données - Les tables et les types de données - ne portent pas non plus de port à d'autres fournisseurs, il y a des kits de conversion. Même les changements dans la base de données sont une douleur, c'est pourquoi le développement de la conception / modélisation de la base de données ne fonctionne pas bien dans les processus de développement agiles / interamétaires.
Conclusion
La logique de base de données dans l'application est excellente si vous avez des applications super simples, avec de petits jeux de données. Mais il va payer à Spades pour apprendre le développement de la base de données - vos clients bénéficieront d'une application plus évolutive et plus rapide.
Je suis solidement dans le camp de "logique d'application" moi-même.
Pour moi, la question la plus importante a à voir avec la mise à l'échelle de la couche de persistance lorsque votre application augmente. En s'appuyant surtout sur la base de données pour mettre en œuvre votre logique, vous signerez votre application pour la base de données ou la réplication comme solution de mise à l'échelle pour votre couche de persistance lorsque vous grandissez. J'ai trouvé beaucoup plus de succès avec la pléthore de solutions de cache distribuées à la couche d'objet métier.
de performance secondaire est la transparence de la mise en œuvre. La conception moderne des objets axée sur les objets a beaucoup d'avantages à tirer ensemble vos données et votre logique d'entreprise, mais elle désigne largement un désordre une fois que vous comptez sur une couche de logique externe et cachée.
Je vais donner une réponse probablement le contraire de ce que tout le monde dira.
La logique de la base de données appartient aussi près des données que vous pouvez l'implémenter, ce qui signifie dans la base de données. Faire toute autre chose, vous devez au mieux vous demander de vous répéter dans différentes applications et d'avoir un mal de tête à jour. Au pire (et c'est assez probable), vous aurez une logique de base de données incohérente mise en œuvre dans différentes applications.
Vous devez séparer quelle est la "logique de la base de données" et quelle est la "logique d'application". Mon exemple normal définit ce que votre organisation signifie par «nom complet» pour un client. Imaginez que vous écriviez du code dans votre application qui combine les prénoms et les noms de famille dans un champ Nom complet. Plus tard, vous ajoutez une initiale intermédiaire (ou décidez d'inclure une colonne initiale existante existante) dans le nom complet.
Si votre nom de nom complet est implémentée dans une procédure d'affichage ou stockée, vous n'avez besoin que d'une modification unique pour appliquer la nouvelle définition dans toutes les applications (y compris les applications tierces pour lesquelles vous n'avez pas de code source). < / p>
Le problème est quelque peu assoupli dans des situations (comme Ruby) où tous les accès de données sont effectués via un calque Orm partagé où vous pouvez mettre la logique qui sera utilisée par toutes les applications écrites dans la même langue. Dans ma situation, cependant, je travaille rarement dans des situations dans lesquelles seule une seule langue ou un produit sera utilisée pour la programmation contre la base de données d'entreprise.
Pour mon travail de jour, je travaille sur une application J2Ee / Oracle raisonnablement importante qui traite une grande quantité de données et nous suivons vos conseils et tout mettre aussi près que possible des données. Cependant, je pense que cela est atypique pour les applications de rails, dont la plupart ne traitent probablement pas des millions d'enregistrements et sont autonomes en termes de disposition de leur propre base de données.
Je ne sais pas s'il y a une situation "typique" pour tout environnement de développement. J'ai utilisé Django pour ajouter une petite interface Web sur un projet qui a utilisé divers autres environnements pour accéder à la base de données. Mais oui, si l'on est sûr que seul l'ORM sera utilisé pour accéder à la base de données, mes arguments ne s'appliquent pas (bien qu'il existe également des arguments de performance à faire).
+1 pour "Dans ma situation, cependant, je travaille rarement dans des situations dans lesquelles seule une seule langue ou un produit sera utilisé pour la programmation contre la base de données d'entreprise." C'est pourquoi j'aime généralement une API comme une structure de procédure stockée à l'intérieur de la DB.
C'est mon opinion Les SGBMS devraient être stupides et flexibles, utilisés strictement pour la persistance et les applications d'entreprise disparates doivent communiquer à travers des techniques de SOA.
Je crée mes structures de données de manière normalisée et flexible, utilisant généralement uniquement des types de données et des contraintes d'intégrité référentielle. Les données sont gérées par une application (une «mère») qui implémente les règles nécessaires à un domaine cohérent. Si des applications disparates (ou tierces) ont besoin d'un accès à ces données, ils ne doivent pas saper la mère et aller directement au magasin de données, mais utiliser des techniques de SOA pour communiquer avec elle, lui demandant de prendre des mesures et de répondre aux résultats ( y compris les échecs) qu'elle y retourne.
J'y pense de cette façon. Si je veux accéder aux données de messagerie de mon entreprise, je n'en accumulez pas directement où ils résident sur le disque. Ce serait douloureux car je devrais comprendre les structures de données avant de pouvoir faire quoi que ce soit. Au lieu de cela, je communique avec mon application de courrier électronique (Exchange Server, dans mon cas) via des techniques de SOA (WebDAV, CDO, LDAP, etc.). Cette application fournit une couche d'abstraction pour interroger les données de courrier électronique, calendrier ou de contact, à envoyer des courriels ou à créer des contacts ou des rendez-vous, ou gérer des calendriers, etc.
Si ces autres applications (créées par vous) ne sont pas fondamentalement différentes de l'application mère (également créée par vous), vous avez peut-être aussi trop d'applications uniques et une composition de ces applications doit être développée comme courante et commune système d'entreprise intuitif. Ensuite, chacune de ces applications est devenue des cas d'utilisation (ou des modules, comme je les appelant) peut accéder aux données directement exploitant une couche d'accès à des données courante qui implémente les mêmes règles de cohésion définies de manière centralisée dans l'application Composite. Bien entendu, l'application composite doit alors donner accès aux données via des techniques de SOA afin que les applications soient vraiment disparates puissent communiquer avec elle.
Et les RDBMs ne peuvent pas être déchargés, sinon ce ne serait pas un SGBDM. Il doit tout savoir sur vos données pour être rapide et fiable. Il n'a rien à savoir sur votre application, c'est une chose différente.
Je conviens que vos RDBMS ne doivent pas savoir quoi que ce soit sur la demande. Cependant, un SGBDM peut être stupide; Il n'a pas besoin de savoir "tout" sur vos données pour être rapide et fiable; En fait, je pourrais faire valoir qu'il n'a pas besoin de savoir seulement deux choses à propos de chaque morceau de données pour répondre à cette fin - comment le trouver rapidement et comment le relier à d'autres (indices et contraintes d'intégrité référentielle dans les RDBMS Lingo) .
Par exemple, il n'a pas besoin de savoir que mon champ "Prix spécial" ne doit stocker que des valeurs comprises entre 0,00 et 100,00 pour être rapide et fiable; Il doit simplement savoir pour l'indexer dans un arbre basé sur une comparaison numérique et qu'il est associé à ce produit ou à ce produit, et je suis sûr qu'il sera rapide et fiable, quels que soient les chiffres placés dans ce domaine. Et si mon application est uniquement responsable de la validité de cette donnée, cela garantira que la restriction est remplie; au moins jusqu'à ce que l'entreprise change.
Il y a une logique de données et il y a une logique d'application. La base de données doit tout savoir sur la logique de données, l'application sur la logique de l'application. La logique des données peut être stockée dans la base de données dans les procédures, les vues, les règles, etc. Oracle, PostgreSQL, SQL Server, etc. Vous avez des outils très puissants pour supporter cela.
De nombreuses applications peuvent utiliser la même base de données et les mêmes données, et vous devez être sûr que les données sont correctes. Chaque application (dans n'importe quelle langue) peut faire différentes choses avec ces données, à la suite de l'application. Construire la logique de la base de données à l'intérieur de votre application, c'est comme réinventer la roue et demander des problèmes. Les RDBMS ont environ 40 ans d'histoire de développement, vous n'allez pas obtenir un meilleur résultat dans quelques semaines ou quelques mois.
Pour PostgreSQL, jetez un coup d'œil aux différents pls: PL / PGSQL est agréable, PL / PERL et PL / RUBY pourraient être plus intéressants pour les développeurs Perl et Rubis.
Eh, ajout de langues à postgres est si facile que quelqu'un a écrit un PL / lolcode juste parce que.
J'ai recherché sur l'endroit où la gâchette doit être (Côté d'application ou la base de données). Les deux décisions de conception ont des avantages et des inconvénients
Database Trigger
pros:
- Simplifies application logic
- Better performance
cons:
- Maintaince is harder
- Database dependency
- Batch operation performance problems
- If you don't have access to database for prod envoriment, It can be harder to manage
Application Logic:
pros:
- Maintaince can be done in one place. It is good thing.
- Database independent if you use ORM tools or frameworks.
cons:
- Performance may be problem
- Add some complexity to the application logic