Au boulot, je suis régulièrement confronté à ce que les développeurs croient être le mieux pour une application, versus ce que je crois qui est le mieux pour le serveur de base de données. Voici donc une petite étude que j’ai fais concernant les Natural ID versus les Generated ID.

Premièrement, il n’y a aucune garantie que les Natural IDs ne changeront jamais, sous aucune circonstance. En fait, il y a très peu de cas où nous pouvons en être 100% sur. Les Generated ID eux ne changent jamais, sous aucune circonstance.

De plus, advenant le cas où le natural ID changerait, il faudra gérer ce changement en cascade pour chaque clé étrangère. Ce changement invalidera tous les enregistrements en cache, pour tous les niveaux de cache, autant pour la table primaire et que les tables “enfants”.

Dans un contexte de faible contrainte d’intégrité, la possibilité que quelqu’un soit tenté d’updater la …

On m’a demandé un jour ce que je recommande pour des designs de databases appelées à être modifiées régulièrement. La personne prévoyait avoir besoin d’ajouter des champs fréquemment pour répondre à ses besoins.

La première interrogation qui m’est venu en tête a été de lui demander pourquoi. Pourquoi a t’il besoin d’ajouter des champs et des tables de manière fréquente ? Pourquoi ne sait-il pas d’avance ce que fera son application ? La réponse est simple: la portion de l’application qui est déjà en ligne est complètement fonctionnelle, étudiée et testée. En fait, l’application est personnalisable et chaque client qui l’achète peut avoir des particularités différentes d’un autre client. D’où le besoin d’ajouter des champs et tables régulièrement.

Il n’y a pas de réponse magique à cette question. Il suffit d’y répondre avec “le gros bon sens”. D’un côté purement …

Je vois régulièrement des diagrammes d’architecture où  les flèches pour la connexion du Slave / Master sont dans le mauvais sens. Il faut savoir qu’avec MySQL, c’est le Slave qui se connecte au Master pour aller chercher le binlog, et non l’inverse. Ça devrait donc donner un diagramme comme ceci:

Un ami me demandait aujourd’hui si une application qu’il utilise à son travail pourrait être plus performante si les tables étaient Innodb plutôt que MyISAM ? Oui. Non. Peut-être. Il n’y a pas de réponse à cette question; il y beaucoup trop de facteurs à considérer.

Peter Zaitsev a publié hier un article sur le sujet. Comme il indique, il faut d’abord s’interroger pour savoir “pourquoi” les tables sont MyISAM à la base. Le sont-ils pour une raison particulière ou parce qu’elles utilisent le storage engine par défaut de MySQL ?

Les 2 storages engines possèdent des avantages différents qui les rendent aussi performant l’un que l’autre, dépendamment de l’utilisation qu’on en fait. Pour répondre adéquatement à mon ami, il aurait fallu que je connaisse quel genre de requêtes son …

Je hais phpMyAdmin. Ironiquement, je m’en sers encore beaucoup et pour me contredire davantage, je vais même avouer que c’est “relativement” un bon outil. Mais je le hais quand même.

PhpMyAdmin est l’outil qui m’a fait découvrir MySQL lorsque j’étais encore à l’école. C’est un outil idéal pour débuter en développement Web puisqu’il est intégré à des logiciels comme easyphp ou est souvent ajouté à LAMP (Linux Apache MySQL PHP). L’outil est convivial et permet de faire beaucoup d’opérations, même pour un utilisateur inexpérimenté en SQL. Plusieurs hébergeurs Web l’offrent dans leurs plans puisqu’il est gratuit, simple à installer et facile à maintenir.

Mais quand on connait bien le SQL, plus précisément MySQL, et qu’on s’en sert régulièrement comme je le fais, on en vient …

Arjen Lentz a écrit un article très intéressant pour trouver les indexes inutilisés. En gros, il explique la règle du 30% pour les indexes. Pour ceux qui ne la connaissent pas, les indexes ne sont pas utilisés si environs 30% des valeurs indexées sont les mêmes. Arjen propose donc une requête qui permet de trouver quel indexes sont inférieurs à 30% grâce à la cardinalité.

Mais attention! Sa technique est un peu controversée. Premièrement, il faut savoir que les 30% sont une approximation. Les indexes peuvent être utilisés si 25% ou 40% des valeurs sont pareil.

J’ai fait mes propres tests sur la base de données avec laquelle je travail au boulot et les résultats m’ont assez étonné. EXPLAIN indiquait qu’un index avec une cardinalité de 4 (la table possédait 3422 000 rows) était utilisé. C’est beaucoup plus que 30%. J’ai …

Est-il mauvais de stocker des fichiers dans MySQL ? Il n’y a pas de bonne ou mauvaise réponse à cette question. Tout dépend de vos besoins. Personnellement, je préfère stocker les fichiers à l’extérieur de la base de données pour les raisons suivantes:

• Le filesystem va mieux cacher les fichiers
• Le serveur MySQL va avoir plus de facilité à cacher les autres données
• Le débit de donnée du serveur va être moins élevé
• Il est plus facile de réorganiser et maintenir les fichiers
• Le tablespace demeure petit (si vous devez utiliser InnoDB)

Une bonne approche est de stocker un pointeur vers les fichiers sur le filesystem plutôt que le binaire du fichier directement dans la BD. Il y a cependant des avantages à les stocker dans la base de données:

• Toutes les données sont centralisées à une place pour les backups
• C’est plus …