Jump to content

InnoDb et transaction


Recommended Posts

Bonjour,

 

J'ai une question à l'équipe PrestaShop, depuis les dernières versions de PS ont peut choisir en format de table InnoDB, dans ce cas pourquoi n'avoir pas prévu de pouvoir utiliser les transactions? BEGINS, COMMIT ET ROLLBACK

 

Cdt

Link to comment
Share on other sites

Bonjour,

c'est un débat que nous avons déjà eu il y a longtemps en interne, à l'époque il avait été dit qu'on doit continuer à supporter MyISAM, et qu'on ne peut donc pas se reposer uniquement sur les transactions comme mécanisme de protection de l'intégrité des données. Cela dit effectivement ça n'empêche pas de les ajouter pour ceux qui sont sous innoDB (c'est à dire globalement tout le monde, il faudrait demander à Rémi pour avoir des statistiques précises).

Par contre personnellement je pense qu'on ne peut pas intégrer ce genre de développement aujourd'hui, pour moi cela fait partie des choix d'architecture lors de la conception d'un logiciel, et il est difficile de faire de belles implémentations de telles fonctions, je pense que cela risquerait d'avoir des effets de bords problématiques si on se mettait à mettre des transactions dans tous les sens dans le code actuel.

 

Cordialement

Link to comment
Share on other sites

On utilise pas les transactions et InnoDb au hasard juste pour faire mumuse...

 

Le choix entre MyISAM et InnoDb doit se faire au cas par cas en tenant compte de l'utilisation de telle ou telle table.

 

En gros, on fait :

- MyISAM si la table est plus utilisée en lecture qu'en écriture

- InnoDb dans le cas inverse.

 

En effet, l'une des différences (hors le support des transactions) est également qu'InnoDb ne locke pas toute la table lors des opérations d'écriture, ce qui permet (normalement) d'accélérer ce genre d'opérations.

 

AMHA il n'y a strictement aucun gain à utiliser InnoDb avec PrestaShop.

Link to comment
Share on other sites

Non tu ne dis pas de bêtises

 

Par contre, j'ai jamais vu personne se reposer entièrement sur les clefs étrangères et les transactions pour garantir l'intégrité des données. En tout cas sur du développement web moyennement complexe.

Idem pour les procédures stockées et tout ce genre de grosse machinerie : hors sujet.

 

Peut-être que dans les banque ou les trucs comme ça ça présente un intérêt.

 

Dans la réalité, tu te rends compte que l'intégrité des données est TOUJOURS également assurée par le software et pas le middleware. Cette constatation débouche d'ailleurs sur la tendance Model-Less / NoSQL

Link to comment
Share on other sites

d'un autre côté, deux autres raisons pour laquelle aucun script php open-source (ou si peu) n'utilise plus les triggers :

 

- la portabilité sur d'autres logiciels serveurs sql;

- la facilité de maintenance (allez combien de personnes qui maintiennent un site sous mutu ou un serveur même de base

se rappellent de ça, faites le test ;) )

(maintenance du code global, et zut où tel changement dans la table est répercuté, si on a oublié qu'on le faisait dans mysql

en trigger c'est moins simple)

 

ceux qui ont déjà codé sur as/400 levez la main :D

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...