Slt à tous,

je vous explique :

Je suis entrain de creer un site de rencontre (ben oui je commence par un truc balaise mais bon)
Et donc je galere un peu (beaucoup)

En fait je galere pour creer tout ça et je me demandais a quoi sert l'interclassement et quel type de base innodb ou mysam etc... qui peux me rencarder la dessus

Très sommairement :
l'interclassement, c'est l'encodage dans lequel tu vas stocker tes données. Si ton site a une vocation internationale incluant des langues aux alphabets non latins (chinois ou arabe par exemple), il serait avisé d'utiliser un encodage utf-8. Mais si ça doit se limiter à du français ou encore à quelques langues européennes, le latin-1 suffira très bien.

Le choix du moteur MyISAM ou InnoDB dépend un peu du type de traitement et des contraintes techniques de ton application. InnoDB permet les transactions et les contraintes d'intégrité référentielles. MyISAM ne permet pas ces deux points qu'il faudrait donc traiter par programmation, en revanche il est beaucoup plus rapide.

Et sur un plan plus global : si ce sont tes premiers pas en création de site avec base de données, je te suggère vivement de commencer avec un projet un peu moins ambitieux histoire de bien te familiariser avec tout ça dans un premier temps. Surtout qu'un site de rencontre, ça implique des données personnelles : il est donc impératif que tu apprennes à maîtriser un tout petit minimum les problèmes de sécurité qui vont avec.

Le choix du moteur MyISAM ou InnoDB dépend un peu du type de traitement et des contraintes techniques de ton application. InnoDB permet les transactions et les contraintes d'intégrité référentielles. MyISAM ne permet pas ces deux points qu'il faudrait donc traiter par programmation, en revanche il est beaucoup plus rapide.

Ce passage me laisse pensif, comment fais-tu par programmation pour simuler des transactions, où des tests d'intégrité ? Les tests d'intégrité peut-être avec des LOCK TABLE, mais côté perfs , sinon les transactions sincèrement je ne vois pas...

MyISAM est parfait pour des sites axés publication (encore que, sans rollback ??!!), 1 administrateur, n lecteurs. Dès lors qu'on n'est plus dans ce modèle, y'a pas à réfléchir aux perfs, on passe en InnoDB.


Tracker.

Je n'ai pas dit que c'était simple. Encore que pour l'intégrité référentielle par programmation, ce n'est pas vraiment sorcier : il faut maîtriser son modèle et veiller à procéder aux vérifications soi-même avant de modifier ou supprimer une donnée.

Pour les transactions, c'est effectivement une autre paire de manches. Pas impossible mais techniquement faisable : un des intérêts de la transaction, c'est le "commit/rollback" : par programmation, ça voudrait dire enregistrer chacune des requêtes effectuées dans la transaction, générer chaque requête inverse et en cas de besoin d'un rollback, exécuter ces requêtes inversant les actions pour remettre la base en l'état.

Je n'ai pas dit que c'était simple. Encore que pour l'intégrité référentielle par programmation, ce n'est pas vraiment sorcier : il faut maîtriser son modèle et veiller à procéder aux vérifications soi-même avant de modifier ou supprimer une donnée.

On est dans un environnement multisession, et donc c'est pas aussi simpliste. Tu as beau faire tous les tests que tu veux, si tu ne lockes pas les structures, tu n'empêcheras personne d'intercaler une modif rendant ta vérification désuette, et donc le traitement en dépendant incohérent.

Pour les transactions, c'est effectivement une autre paire de manches. Pas impossible mais techniquement faisable : un des intérêts de la transaction, c'est le "commit/rollback" : par programmation, ça voudrait dire enregistrer chacune des requêtes effectuées dans la transaction, générer chaque requête inverse et en cas de besoin d'un rollback, exécuter ces requêtes inversant les actions pour remettre la base en l'état.

Pareil, si tu as une erreur lors de l'execution du rollback (comme par exemple recréer un enregistrement pointant vers un autre (FK) qui a entre temps été supprimé par une autre connexion), ta base doit-être dans quel état ? d'autant que, sans lock, d'autres connexions ont pu faire des modifs sur les mêmes données qui seraient purement écrasées par ton rollback, bonjour l'intégrité des infos...

Tu as beau prendre le problème dans tous les sens, de façon programmative il est impossible de gérer la transactionnalité. Le contrôle de références par contre est envisageable mais au prix de verrouillages globaux en mode MyISAM.

[edit]
Les principes de gestion, que tu proposes, sous-entendent, pour être pertinents, qu'une seule connexion modifie les infos. Tu te places implicitement dans une mode de fonctionnement mono-utilisateur en modification et multi-utilisateur en visualisation.


Tracker.

D'où l'intérêt de choisir le moteur approprié au besoin au lieu de se torturer les méninges à essayer de reproduire en PHP un fonctionnement qui existe en natif dans un moteur de SGBD

Au delà de ça, utiliser une base est largement plus complexe qu'il n'y parait. Avant de démarrer tout projet, il est impératif de se former et de comprendre dans le détail les mécanismes de transactionnalité, de lock et de contraintes mis à disposition par les moteurs de bases standards.
Dans le cadre d'un développement MySQL, il faut ensuite examiner si les solutions apportées par les différents engines, sont cohérentes avec ton besoin.


Tracker.