Archives par mot-clé : base de données

Documentation et tutoriel Hibernate

Publié dans Java | Un commentaire
02 Août 2010

Hibernate est un framework utilisé en Java EE permettant de gérer ce que l’on appelle la « persistance des objets » dans une base de données.
En français courant : en Java on travaille sur des objets, on réfléchit avec des objets et en général on souhaite pouvoir stocker quelques uns de ces objets quelque part. Pour se faire, on utilise le plus souvent une base de données et celle-ci est rarement une BDD* objet (car trop compliqué, pas performant et patati et patata) mais plutôt une BDD relationnelle (c’est-à-dire : non objet). Hibernate permet de faire le lien entre Java et la BDD en facilitant les accès via HQL (d’habitude on utilise le SQL pour accéder à une BDD relationnelle, HQL utilise une syntaxe similaire mais manipule des objets), et surtout en faisant en sorte que Java n’ai qu’à traiter des objets. Bref, Hibernate fait gagner un temps fou au développeur, tout en lui permettant de se concentrer d’avantage sur l’essentiel.

J’ai découvert des documentations et des cours Hibernate 2 et Hibernate 3 sur le « site Internet » de M. Masssat, un enseignant-chercheur à Marseille. Je les consulte de temps en temps et c’est du tout bon.

Et M. Massat fournit aussi quelques autres liens vers des infos sur Tomcat, JSP, … : Le coin des docs… Merci à lui et bonne lecture !

Au passage, dans mon bouquin sur Java EE 5, l’auteur parle de JPA. JPA est apparu avec Java EE 5 et a le même rôle qu’Hibernate sauf qu’il est intégré nativement à Java. Les développeurs de Sun se sont inspirés du travail effectué sur Hibernate (ainsi que d’autres frameworks faisant la même chose) et ont standardisé la chose. A ma connaissance, JPA commence à être utilisé de plus en plus massivement, donc à mon avis, ça vaut le coup de s’y intéresser. J’écrirai peut-être un de ces quatre sur Hibernate ou JPA. (ou les deux)

* BDD = Base De Données

Comment importer une grosse base de données

Publié dans SQL | Un commentaire
03 Août 2009

Ce billet aurait aussi pu se nommer « Vive la ligne de commandes ! ».
Je pense arriver au bout de mes peines avec ma grosse tables de 3 millions de tuples (qui n’en fait d’ailleurs toujours pas 3 millions, alors j’espère que ça tiendra le coup quand tous les tuples seront là), et j’ai notamment pas mal galéré pour la transférer d’une base de données à une autre. (local -> serveur de développement) Si on utilise PHP, ou PhpMyAdmin, pour transférer sa BDD, on se retrouve vite avec de très long temps d’attente et avec une machine qui rame jusqu’à la mort. Quelques idées pour survivre entier à ce calvaire :
sql

  • Préférer le transfert à l’aide de fichiers. Car le copier/coller de requêtes fonctionnent pour de petites tables, mais ça fait très vite ramer votre machine de course pour de grosses tables. Il suffit d’exporter les tables de son choix via PhpMyAdmin (à l’accueil d’une base > exporter : pour exporter les tables de son choix. A l’accueil d’une table > exporter : pour exporter directement la table en question), puis dans les importer via PhpMyAdmin, ou en ligne de commandes. Il vaut mieux éviter de cocher la case « Insertion Complète » qui créé une seule requête INSERT INTO table (val1, val2) VALUES ('blabla', 'bloublou'), ('blibli', 'bleble'), ..., ('blublu', 'bloblo'); ce qui peut être un peu trop lourd. Mieux vaut créer autant de requêtes qu’il y a d’insertions dans ce cas. (le mieux serait de faire une requête pour une trentaine d’insertions, c’est vraiment plus rapide, mais cela oblige à coder tout ça soit même. Edit: apparemment, il faut choisir « Insertions Etentdues ».)
  • Préférer l’utilisation des lignes de commandes. Pour plusieurs raisons : plus de problèmes avec les timeout de MySQL ou de PHP puisqu’on effectue une commande à la fois. (sauf si on commande est trop lourde. Dans le cas d’une insertion complète par exemple), on contrôle réellement tout ce qui se passe en temps réel et on peut réellement tout arrêter en temps réel. (suffit de fermer le terminal quoi !), on ne passe par aucun intermédiaire et c’est donc vraiment plus rapide.

Continuer la lecture →

Optimiser ses requêtes MySQL

Publié dans SQL | 4 commentaires
10 Juil 2009

Je travaille actuellement sur une table MySQL qui va contenir près de 7 millions de tuples (avec une quinzaine de colonnes chacun bien sûr, ce ne serait pas drôle sinon !), il se trouve qu’elle en contient déjà près de 3 millions, et que je suis obligé de faire une vingtaine de requêtes différentes dans cette table pour chaque page et que, par conséquent, le site qui l’utilise plante à fond. La mémoire utilisable par MySQL est dépassée. Alors certes, on peut modifier la taille de la mémoire utilisable par MySQL (et il faudrait aussi sûrement modifier la durée maximum d’exécution d’un script PHP), mais le but c’est quand même de charger des pages en moins de 30 secondes. J’ai donc cherché des réponses sur le Web et auprès des développeurs de ma boîte. Voici donc quelques points que j’ai pu retenir.

Structure de la table

Il vaut mieux éviter, sauf si c’est nécessaire, l’utilisation de champ NULL par défaut. En effet, comme on peut le voir sur cet article d’Apprendre PHP NULL est une valeur spéciale qui nécessite un traitement spécial, MySQL ne peut pas le tester avec un égal et ne peut le comparer à la chaine vide ou à 0, il est obligé d’utiliser IS ou le symbole équivalent <=>. NULL par défaut est d’autant plus à bannir pour les index. Utiliser des colonnes avec le meilleur type et la meilleure taille possible. Un prénom n’a par exemple par besoin d’être en VARCHAR(255), un VARCHAR(20) suffit plus que largement. Une bonne technique pour optimiser ses tables est d’utiliser PROCEDURE ANALYSE(). On créé ses tables au feeling (je parle juste de la structure, vous ne couperez pas à la normalisation tout ça, héhé), on les remplie avec un contenu à peu près définitif est on utilise une requête du style :

SELECT id, titre, message FROM blog PROCEDURE ANALYSE()

MySQL va nous répondre un joli petit array avec la taille max et min de chaque colonne id, titre et message, quelques autres informations intéressantes et surtout une proposition de type(taille) optimisée à votre table. Encore une fois, c’est l’article d’Apprendre PHP qui en montre un exemple vraiment parlant.
Continuer la lecture →

Une seule et même fonction pour différents systèmes de gestion de base de données

Publié dans PHP objet | 3 commentaires
03 Juin 2009

Je suis depuis longtemps déjà un féru utilisateur de FluxBB (anciennement PunBB), un système de forum bien fichu, valide W3C, très léger et donc configurable à souhait. En ce moment ce projet open source bat un peu de l’aile, mais de nouvelles mises à jours sortent encore assez régulièrement et la nouvelle version (attendue depuis des années) semble de nouveau repartir sur de bonnes bases. Mais bref, je parle de cela car FluxBB gère les bases de données MySQL, PostgreSQL (ou PgSQL) et même SQLite je crois. Pour se faire, au lieu d’avoir un switch ou des if else à chaque requête à effectuer, ils ont créé une class qui regroupe toutes les fonctions utiles (connect, query, fetch_array, …) et dans le code ils y font appelle après avoir instanciée cette class : $db->query, $db->fetch_array. Reste à sélectionner le type de sa base de données dans la partie administration et hop, on change de SGBD sans rien changer au code ! Pratique ! Je n’ai pas encore fini d’apprendre le PHP objet, mais j’avais envi de pratiquer un peu, alors sans regarder ailleurs, j’ai commencé à coder. Et voici une première version. Ma classe oublie surement pas mal de fonctions, et je n’ai pas pu la tester partout, et puis il manque la gestion des erreurs, j’aurai pu ajouter un compteur de requêtes, mais c’est ma première véritable class, alors soyez indulgent ^^

<?php
class Sgbd {
	public $nom;
	public function __construct($nom) {
		$this->nom = $nom;
	}
	public function connect($hote, $port, $nomBdd, $utilisateur, $mdp) {
		switch ($this->nom) {
			case 'pg':
			$requete = 'host='.$hote.' port='.($port == NULL ? '5432' : $port).' dbname='.$nomBdd.' user='.$utilisateur.' password='.$mdp;
			pg_connect($requete);
			break;
			default:
			mysql_connect($hote.($port == NULL ? ':3307' : ':'.$port), $utilisateur, $mdp);
			mysql_select_db($nomBdd);
		}
	}
	public function close() {
		switch ($this->nom) {
			case 'pg':
			pg_close();
			break;
			default:
			mysql_close();
		}
	}
	public function query($requete) {
		switch ($this->nom) {
			case 'pg':
			$result = pg_query($requete);
			break;
			default:
			$result = mysql_query($requete);
		}
		return $result;
	}
	public function fetch_array($result) {
		switch ($this->nom) {
			case 'pg':
			$arr = pg_fetch_array($result);
			break;
			default:
			$arr = mysql_fetch_array($result, MYSQL_BOTH);
		}
		return $arr;
	}
	public function fetch_row($result) {
		switch ($this->nom) {
			case 'pg':
			$row = pg_fetch_row($result);
			break;
			default:
			$row = mysql_fetch_row($result);
		}
		return $row;
	}
	public function num_rows($result) {
		switch ($this->nom) {
			case 'pg':
			$num_rows = pg_num_rows($result);
			break;
			default:
			$num_rows = mysql_num_rows($result);
		}
		return $num_rows;
	}
}
$sgbd = new Sgbd('mysql');
?>