Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Est-il préférable que le métier soit coté Db ou language tiers ?
Bonjour,
Je voudrais savoir, quel est le critère pour vous pour décider si le métier sera coté base de données ou langage tiers (.net, java, ruby, php ,...)
A titre personnel étant plus à l'aise coté base de données j'aurais dis Db. Néanmoins, je pense qu'il y a des critères à prendre en compte.
Quels sont les critères pour vous ?
Merci
Quelques réponses ici :
http://www.developpez.net/forums/d12...ures-stockees/
Personnellement j'évite toujours les procédures stockées. Dernier exemple en date : avec mon équipe on refait une appli métier qui utilise une base SQL Server et emploie abondamment des centaines de proc stock... On refait l'appli en PHP en utilisant la même base, mais on code toute la logique métier dans nos classes PHP sans jamais appeler une seule proc stock (et pour info on utilise l'ORM Doctrine 2).
Je pense que la logique métier a sa place dans le code et pas ailleurs. C'est plus souple :
- plus logique dans le cadre d'une approche objet : c'est l'objet qui possède ses méthodes et non la DB qui ne sert "que" de stockage.
- plus facile à débugger (avec les outils du langage applicatif) et à maintenir (il "suffit" d'une personne connaissant le langage applicatif, pas besoin d'un DBA spécialisé sur le moteur de DB utilisé)
- plus puissant (les langages de programmation des DB sont quand même plus limités que les langages classiques)
La DB doit par contre toujours gérer l'intégrité référentielle directement
On peut être d'accord ou pas avec les réponses du lien!
Dans une approche très bases de données avec beaucoup de code en base, on pourra espérer de meilleurs performances, mais il faudra bien documenter son code...
Avec des soluces à la click/click/click/hibernate (avec des dévelopeurs qui ne comprennent pas l'architecture du SGBD employé), on pourra toujours blâmer le dba en cas de problèmes de perf...
Bon ça va si tu géres la collection de vinyls de ta grand-mère ...
Il y a aussi les solutions mixtes, avec beaucoup de logique dans l'appli (java) et des vues et procédures en BD pour améliorer les perfs.
PS: je ne sais pas si ma réponse fait avancer le schmilblik, je pense qu'il faut tout d'abord bien comprendre l'architecture et considérer les besoins de performance et de "scalability" (j'ai pas le mot sur la langue, sorry)
La question, c'est pourquoi avez-vous besoin de re-coder ? Les besoins ont changé ou c'est simplement pour changer.Envoyé par ovh
Quelques réponses ici :
http://www.developpez.net/forums/d12...ures-stockees/
Personnellement j'évite toujours les procédures stockées. Dernier exemple en date : avec mon équipe on refait une appli métier qui utilise une base SQL Server et emploie abondamment des centaines de proc stock... On refait l'appli en PHP en utilisant la même base, mais on code toute la logique métier dans nos classes PHP sans jamais appeler une seule proc stock (et pour info on utilise l'ORM Doctrine 2).
Je pense que la logique métier a sa place dans le code et pas ailleurs. C'est plus souple :
- plus logique dans le cadre d'une approche objet : c'est l'objet qui possède ses méthodes et non la DB qui ne sert "que" de stockage.
- plus facile à débugger (avec les outils du langage applicatif) et à maintenir (il "suffit" d'une personne connaissant le langage applicatif, pas besoin d'un DBA spécialisé sur le moteur de DB utilisé)
- plus puissant (les langages de programmation des DB sont quand même plus limités que les langages classiques)
La DB doit par contre toujours gérer l'intégrité référentielle directement
Maintenant, tu soulèves un os qui pour moi peut être flou pour beaucoup.
Il est logique que cette partie là puisse être géré via des procédures. S'assurer que l'information enregistrée ou retournée puissent être correcte. Du coup, la frontière entre la validation des données et les opérations métier peut être floues ou dépassées.La DB doit par contre toujours gérer l'intégrité référentielle directement
Parce que le client l'a demandé
En fait l'appli actuelle est un vieux brol écrit en PowerBuilder, pas ergonomique pour un sou, qu'ils utilisent tous en terminal server... Bref pas souple du tout, donc ils ont décidé de tout réécrire en mode web. (ce qui nous mène d'ailleurs à un autre débat récenthttp://www.developpez.net/forums/d10...tions-lourdes/
)
Quand je parlais d'intégrité référentielle, je parlais uniquement des contraintes, telles que les clés primaires et étrangères.
Le souci c'est que ça fait très chère le SQLServer juste pour lui demander de faire cela.Parce que le client l'a demandé
En fait l'appli actuelle est un vieux brol écrit en PowerBuilder, pas ergonomique pour un sou, qu'ils utilisent tous en terminal server... Bref pas souple du tout, donc ils ont décidé de tout réécrire en mode web. (ce qui nous mène d'ailleurs à un autre débat récent
Quand je parlais d'intégrité référentielle, je parlais uniquement des contraintes, telles que les clés primaires et étrangères.A titre personnel, j'ai un peut de mal. Après est-ce pas lié au faite de là ou nous nous sentons plus à l'aise sgbd ou language. N'est-ce pas ça l'une de condition ?
Dans ce cas précis, le client utilise aussi d'autres fonctionalités de SQL Server telles que les backups et réplication, et surtout le reporting avec SSRS (que nous interfaçons grâce aux web services dans notre appli, comme j'ai montré dans mon article http://ovanhoof.developpez.com/utili...zend-framework). De plus SQL Server nous a été imposé, car il est utilisé par l'appli actuelle (qui fonctionnait initialement sur du sysbase, dont l'évolution naturelle est SQL Server); si on avait pu choisir, on aurait probablement mis du mysql ou du postgresql
Pourquoi changer un SGDB extrémement riche fonctionnellement pour un extrémement pauvre ?
Je suis d'accord sur ton interrogation mais peut être pour des questions de coût.
Pourquoi changer un SGDB extrémement riche fonctionnellement pour un extrémement pauvre ?
Ben justement.
Quand tu te penches sur le TCO de MySql quand tu veux lui faire faire la même chose que Sql Server ou Oracle, cela devient très vite "gratiné" ....
Concernant la comparaison de TCO entre Sql Server et PostGre en revanche, je ne me prononcerais pas.
Je me poserais les questions suivante
- Que développes-tu?
- Qu'est-ce qui est le plus important pour toi? L'application ou les données?
- Quelles sont tes contraintes de performances et de disponibilité?
- Quelle est ton architecture?
- Quel est ton budget?
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager