Pour rappel, l’ORM (pour “Object-Relational Mapping“) vise à faire correspondre un objet de la couche applicative aux données qu’il exploite dans la base de données. En quelque sorte, on a donc une “base de données orientée objet” puisque, pour faire très simple, chaque champ de la base peut être une propriété d’un objet. Mais selon Frédéric Brouard, le concept mérite qu’on s’y attarde et qu’on le développe.

Dans un applicatif exploitant une base de données épaisse, ce n’est ni le client ni le serveur web qui doivent réaliser le maximum des opérations nécessaires, mais bel et bien la base de données. Outre le fait qu’on obtient une application plus facilement portable (puisque le PHP ne ferait plus ou moins que de l’affichage), on supprime aussi un goulot d’étranglement important en éliminant les aller/retour incessants entre l’applicatif et la base.

Pour prendre un exemple simple, quand on veut calculer une moyenne, on ne rapatrie pas l’ensemble des lignes à prendre en compte avant de faire un calcul à la main, on utilise plutot la fonction AVG() qui exécute le traitement nécessaire et ne renvoie qu’un résultat final.

Avec une base de données épaisse, en utilisant notamment des requêtes SQL avancées, les procédures stockées, et pourquoi pas des User-Defined Functions (UDF) sous MySQL, on peut arriver au même résultat avec la majorité des traitements que nécessitent une application.

En déportant son code métier vers la base de donnée quand cela est possible, non seulement on décharge les serveurs frontaux, mais on améliore aussi la circulation des données dans l’ensemble de l’architecture, puisqu’on ne rapatrie à aucun moment de gros resultsets uniquement pour les traiter. Les liens entre base de donnée et applicatifs sont ainsi préservés.

La base se retrouve donc avec plus d’opérations à réaliser, mais il faut bien le reconnaître: sur un site à fort trafic, à moins qu’on aie beaucoup d’écritures à réaliser, c’est rarement la base – même avec un certain volume d’informations – qui représente le goulot d’étranglement le plus étroit. C’est souvent plutôt le serveur Web et la couche réseau en général qui saturent (J’ai plus souvent vu 1 BDD + 3 Apache en front que le contraire…).

Du coup, le principe d’ORM peut être tué, mais aussi sublimé: une base de données épaisse pourra ne pas embarquer que la partie “stockage” d’un objet (propriétés) mais aussi sa partie “métier” (méthodes). Et si possible, tout le reste, et en restant basé sur du relationnel, donc sans avoir à quitter son SGBDR favori

Liens

Le Monde Informatique : Les ORM et les frameworks survivront-ils au concept de développement en base de données épaisse ?
Frédéric Brouard, alias SQLPro sur Développez.com

Exports CSV avec MySQL : SELECT INTO OUTFILE

Le principe de SELECT INTO OUTFILE est simple: réaliser un export de données en écrivant un resultset (résultats d’exécution d’une requête) directement dans un fichier CSV sur le serveur. Pour cela, l’utilisateur avec lequel vous vous connectez à MySQL doit avoir le priilège “FILE”. Autre remarque, vous ne pourrez en aucun cas écraser un fichier déjà existant sur le serveur (ceci pour la simple et bonne raison qu’il serait assez dommageable d’écraser, par exemple, votre fichier /etc/passwd).

Voici donc la syntaxe, finalement assez simple, de la fonction SELECT INTO OUTFILE :

Dans le fichier exporté, les champs ne sont pas délimités, sauf si vous utilisez FIELDS ENCLOSED BY. Le OPTIONALLY spécifie que seules les chaînes de caractères doivent être encadrées.
Le délimiteur par défaut est l’espace. Pour en utiliser un autre (virgule, point-virgule, tabulation, …) il faut utiliser la directive FIELDS TERMINATED BY. Evidemment, on peut utiliser des caractères spéciaux comme la tabulation ‘t’ ou le retour à la ligne ‘n’ (éventuellement CR+LF sous Windows, donc ‘rn’). Il existe aussi LINES TERMINATED BY pour contrôler le caractère de fin de ligne.

Du coup, en lançant sur la base de mon blog cette requête :

j’ai pu récupérer un fichier plat qui donnait :

Soit, un joli fichier CSV bien propre, directement exploitable (pourquoi pas par Excel).

Imports de CSV dans MySQL : LOAD DATA INFILE

Le LOAD DATA INFILE, qui permet de faire l’exact inverse du INTO OUTFILE, est tout aussi simple à utiliser. Dans les bonnes conditions, c’est vraiment l’un des outils d’import MySQL les plus puissants.
Déjà, bonne nouvelle, la syntaxe des commandes qui permet à LOAD DATA INFILE de repérer les débuts et fin de champs (et de ligne) est la même que pour SELECT INTO OUTFILE. On retrouve donc sans surprise les FIELDS TERMINATED BY et autres joyeusetés.
Une gestion des doublons est aussi possible grâce aux mots-clefs IGNORE et REPLACE, qui parlent d’eux-même. Déclenchés en cas de doublon dans une clé (primaire ou unique), REPLACE effacera l’ancienne ligne pour la remplacer par la nouvelle. Attention donc, vous perdrez donc la pérennité de vos ID puisque ceux-ci changeront lors de l’import de données. IGNORE permettra simplement de conserver l’ancienne ligne, les nouvelles données n’étant pas écrites: vous conservez vos ID mais perdez le bénéfice de l’import sur cette ligne.
Vous pouvez aussi spécifier la liste des champs dans lesquelles les données doivent être stockées avec la syntaxe classique “(champ1, champ2, champ3)” (sans guillemets) en fin de commande.
Pour prendre un exemple, avec un fichier de la forme :

En imaginant qu’on ne veut garder que l’id (champ 1) et le texte (champ 3), et les insérer dans les champs correspondants de la table SQL “data”, on peut utiliser le paramètre @dummy pour demander au serveur d’ignorer l’un des champs du CSV. Cela nous donne une requête de la forme :

Et si par malheur votre fichier commence par 2 lignes d’entête, pas de souci, vous pouvez présicer IGNORE 2 LINES dans la requête pour que soient ignorées les 2 premières lignes.

Et voila. Deux commandes, finalement pas bien complexes une fois qu’on les a prises en main, qui permettent de gérer efficacement les imports/exports de fichiers CSV sous MySQL. Pour faire suite à cet article, nous verrons bientôt comment optimiser la vitesse de vos INSERT dans MySQL.