Discussion :

[nikles007]

Bonjour,

Pour un projet dans une architecture PHP+MySQL, j'aimerais savoir le plus pertinent:

- Créer une/des couches logicielles en PHP pour coder les règle métiers.
Par exemple, pour un site de e-commerce, j'imagine avoir des données des clients et leur coordonnées bancaire.
J'imagine avoir un service bancaire et un service client, de tel sorte que lorsque je supprime un client, ses coordonnées bancaires sont également supprimée.
Le tout bien géré en PHP, avec la gestion des transactions.

OU ALORS,

-déléguer au maximum ces règles métier dans le SGBD lui même sous la forme de contraintes. (delete en cascade, ...)


- Peut on vraiement tout faire avec des contraintes SQL ?
- Que ce passe t'il si je dois changer de SGBD ?

Quels pourraient être les avantages et les inconvénient d'une telle approche ?

AU final, la question est: le SGBD est le meilleur placé pour gérer les transactions (ACID) métiers ?

[SQLpro]

Première chose, si PHP est un excellent langage pour le développement de site web, c'est loin d'être un foudre de guerre en matière de traitement. Son but est de faire de la présentation, pas du calcul... Il y a d'autres langages pour cela.
Secundo, MySQL n'est pas ls SGBDR le mieux placé pour gérer des transactions et s'avère médiocre à catastrophique en terme de performance dès que la concurrence se fait sentir. En sus c'est un outil payant (en code ou en numéraire) et pas "libre". Enfin, il est farci de bugs... Bref, c'est le plus mauvais de tous les SGBD et il n'est même pas réellement relationnel !
A lire sur cet ersatz de SGBDR qu'est MySQL : http://blog.developpez.com/sqlpro/p9...oudre_aux_yeux

Ensuite il faut savoir ce que vous voulez :

• faciliter le développement;
• assurer une bonne montée en charge et des performances.

Les deux critères étant généralement très opposés.

Si vous voulez des performances et une bonne montée en charge, alors oui, placez tout le code de traitement des données dans le SGBR est la meilleure des solutions... Figurer vous qu'un SGBDR a été spécialement conçu pour traiter le plus rapidement les données, en volume et en concurrence !
A lire sur le sujet : http://sqlpro.developpez.com/cours/b...s-epaisses.pdf

Mais préférez un outil qui tienne la route... Au minimum PostGreSQL (réellement libre et gratuit), MS SQL Server (version gratuite Express, ou version "ligh" Web...), voire Oracle (lourd, cher...). Utilisez les contraintes, les déclencheurs, les procédures... et faite du CRUD dans le SGBDR à l'aide de vue, de déclencheurs INSTEAD OF branché sur les vues et de procédures stockées...
Exemple : http://blog.developpez.com/sqlpro/p9...apping_ro_dire

Et si vous voulez d'extrêmes performances, faite du traitement de données "in memory"... A lire : http://en.wikipedia.org/wiki/In-memory_database

Enfin sachez qu'on change rarement de SGBDR, beaucoup moins fréquemment que de code applicatif ! En effet, l'inertie des données, fait que de passer d'un SGBDR à l'autre est un coût gigantesques qui croit de manière exponentielle en fonction du volume ! De toutes façon, aucune requête SQL même si simple soit-elle (à part faire SELECT * FROM Matable) n'est compatible d'un SGBDR à l'autre...

Sachez que les gros sites web comme fnac.com, cdiscount, carrefour ou vente privées (les plus gros en france...), utilisent MS SQL Server, avec un maximum de procédures stockées et manient plusieurs dizaines de To...

A +