Tag Archives

6 Articles
Authentification sous MongoDB

Authentification sous MongoDB

Aujourd’hui, changement complet de technologie. Depuis quelques semaines au travail, nous migrons notre projet PHP/MySQL/JS vers du NodeJS/MongoDB avec une API REST. Je vais donc partager avec vous un point avec lequel j’ai eu un peu de mal : L’authentification avec MongoDB.

Je tiens à préciser que cet article ne remplace pas la documentation officielle et qu’ici, il ne s’agit que d’une mise en application à travers ce que j’ai compris. Si j’ai fait une erreur, merci de me le préciser en commentaires.

Précisions

Je ne m’attarderai pas sur qu’est-ce que MongoDB et quelles sont les différences avec une base de donnée relationnelle. Si vous voulez savoir ceci, je vous renvoie pour le moment vers cet article donnant la plupart des différences avec MySQL, CouchDB et MongoDB.

Mise en place

Si vous avez mongoDB installé sur votre serveur, vous savez aussi que vous avez, à l’instar de MySQL, un client disponible en ligne de commande, à savoir pour MongoDB : mongo. C’est avec cet outil que nous allons créer notre utilisateur.

Ensuite, il faut savoir que pour l’authentification, et ce peu importe la base de donnée cible, MongoDB s’appuie sur la liste des utilisateurs présents dans la base admin. Nous allons donc créer notre utilisateur simplement en faisant ceci :

use admin
db.addUser("nomduuser", "password")

Normalement, après avoir rentré ceci, mongo devrait vous retourner ce résultat :

{
    "user" : "test",
    "readOnly" : false,
    "pwd" : "a6de521abefc2fed4f5876855a3484f5",
    "_id" : ObjectId("517c027488495859945639e6")
} 

Votre user a été correctement créé. Au cas où, nous allons le vérifier grâce à la commande db.system.users.find() et elle devrait vous retourner la même chose que plus haut.

Bien, votre utilisateur a été créé mais vous pouvez vous connecter à votre serveur sans vous authentifier et effectuer toutes les actions que vous voulez. C’est normal car de base, MongoDB a désactivé la couche d’authentification.

Pour activer l’authentification, nous devrons modifier la configuration de mongoDB à partir du fichier mongod.conf en rajoutant simplement cette ligne :

auth = true

Ensuite, relancez simplement le processus mongod.

Pour tester l’authentification, vous avez plusieurs choix. Soit en lançant mongo, soit avec la commande mongo db.auth("login","password"), soit via votre application connectée au serveur ou soit via un logiciel d’administration pour MongoDB.

Personnellement, je les test grâce à l’application GenghisApp mais nous allons voir le cas avec la commande db.auth(). Relancez donc le client mongo et essayez d’ajouter un nouvel utilisateur. Vous devriez normalement avoir l’erreur suivante :

Sat Apr 27 19:09:58.263 JavaScript execution failed: error: 
{ "$err" : "not authorized for query on admin.system.users", "code" : 16550 } 
at src/mongo/shell/query.js:L128

C’est bon, le système d’authentification est en marche. Pour palier à ceci, faites juste la commande suivante :

db.auth("votrelogin","votremotdepasse")

Et mongoDB devrait vous laisser passer en retournant simplement 1. Si vous essayez de vous authentifier avec un login/password invalide, vous devriez avoir l’erreur suivante :

Error: 18 { ok: 0.0, errmsg: "auth fails" }
Lors des tests sur mon poste, la commande mongo me retournait une erreur d’authentification alors que GenghisApp arrivait bien à se connecter avec mon utilisateur. Apres plusieurs redémarrages de MongoDB, l’authentification s’est mise à marcher avec mongo.

Voilà, votre base MongoDB utilise maintenant l’authentification. Vous pouvez aller plus loin avec les différents droits existants au seins de MongoDB à l’instar de MySQL. Mais pour ça, je vous renvoie vers la Documentation officielle

Edition du 13 Mai :

Il semblerait qu’en plus de la base admin, si vous voulez accéder directement à votre application, vous devrez créer ce même utilisateur dans la base cible.

Introduction au ZF – Partie 5 : Doctrine

Introduction au ZF – Partie 5 : Doctrine

Pour les Models, je pensais vous montrer l’exemple concret de l’usine à gaz présentée par Zend. Mais vu que le Zend Framework 2.0 va le changer pour doctrine, j’ai décidé de passer dessus. Doctrine a plusieurs points positifs :

  • Il utilise PDO donc il y a toujours une couche d’abstraction
  • Il génère automatiquement les models (si on utilise l’utilitaire)
  • Il est plus performant que Zend_Db
  • Tout est objet
  • Conforme au pattern MVC

Pour ces raisons, Doctrine semble être le choix le plus judicieux. Maintenant il ne reste plus qu’à l’intégrer à notre projet. Pour informations, j’utilise la version 1.2.2 de Doctrine qui est la dernière version stable en date. Vous pouvez la récupérer à cette adresse.

Je vous conseil aussi d’avoir la documentation officielle sous le bras pour bien comprendre tout ce qu’il va se dire ici. Avant de continuer, voici la base de donnée finale que nous allons utiliser tout au long de ce tutoriel. Je mets le contenu final ici pour que l’on génère les Models complets dès le début.

C’est avec une application bien pensée qu’on arrive à un bon résultat.

Et voici maintenant le script avec un utilisateur par défaut. Le mot de passe décrypté est azerty.

SET SQL_MODE="NO_AUTO_VALUE_ON_ZERO";

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;

--
-- Base de données: `tutosite`
--
CREATE DATABASE `tutosite` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
USE `tutosite`;

-- --------------------------------------------------------
--
-- Structure de la table `article`
--

CREATE TABLE IF NOT EXISTS `article` (
  `idArticle` int(11) NOT NULL AUTO_INCREMENT,
  `idUtilisateur` int(11) NOT NULL,
  `idRubrique` int(11) NOT NULL,
  `titre` varchar(45) NOT NULL,
  `corps` text NOT NULL,
  `date` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`idArticle`),
  KEY `fk_Article_Utilisateurs` (`idUtilisateur`),
  KEY `fk_Article_Rubrique` (`idRubrique`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;

--
-- Contenu de la table `article`
--
-- --------------------------------------------------------
--
-- Structure de la table `commentaire`
--

CREATE TABLE IF NOT EXISTS `commentaire` (
  `idCommentaire` int(11) NOT NULL AUTO_INCREMENT,
  `idArticle` int(11) NOT NULL,
  `pseudo` varchar(45) NOT NULL,
  `email` varchar(45) DEFAULT NULL,
  `message` text NOT NULL,
  `date` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`idCommentaire`),
  KEY `fk_Commentaire_Article` (`idArticle`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;

--
-- Contenu de la table `commentaire`
--
-- --------------------------------------------------------
--
-- Structure de la table `rubrique`
--

CREATE TABLE IF NOT EXISTS `rubrique` (
  `idRubrique` int(11) NOT NULL,
  `Nom` varchar(45) NOT NULL,
  PRIMARY KEY (`idRubrique`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

--
-- Contenu de la table `rubrique`
--
-- --------------------------------------------------------
--
-- Structure de la table `tag`
--

CREATE TABLE IF NOT EXISTS `tag` (
  `idTag` int(11) NOT NULL,
  `Nom` varchar(45) NOT NULL,
  `Couleur` varchar(7) NOT NULL DEFAULT '#000000',
  `Hicolor` varchar(7) NOT NULL DEFAULT '#000000',
  PRIMARY KEY (`idTag`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

--
-- Contenu de la table `tag`
--
-- --------------------------------------------------------
--
-- Structure de la table `tagarticle`
--

CREATE TABLE IF NOT EXISTS `tagarticle` (
  `idTag` int(11) NOT NULL,
  `idArticle` int(11) NOT NULL,
  PRIMARY KEY (`idTag`,`idArticle`),
  KEY `fk_Tag_has_Article_Tag` (`idTag`),
  KEY `fk_Tag_has_Article_Article` (`idArticle`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

--
-- Contenu de la table `tagarticle`
--
-- --------------------------------------------------------
--
-- Structure de la table `utilisateurs`
--

CREATE TABLE IF NOT EXISTS `utilisateurs` (
  `idutilisateur` int(11) NOT NULL AUTO_INCREMENT,
  `login` varchar(50) NOT NULL,
  `passwd` varchar(100) NOT NULL,
  PRIMARY KEY (`idutilisateur`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 AUTO_INCREMENT=2 ;

--
-- Contenu de la table `utilisateurs`
--

INSERT INTO `utilisateurs` (`idutilisateur`, `login`, `passwd`) VALUES
(1, 'admin', 'ab4f63f9ac65152575886860dde480a1 ');

--
-- Contraintes pour les tables exportées
--
--
-- Contraintes pour la table `article`
--
ALTER TABLE `article`
  ADD CONSTRAINT `fk_Article_Rubrique` FOREIGN KEY (`idRubrique`) REFERENCES `rubrique` (`idRubrique`) ON DELETE NO ACTION ON UPDATE NO ACTION,
  ADD CONSTRAINT `fk_Article_Utilisateurs` FOREIGN KEY (`idUtilisateur`) REFERENCES `utilisateurs` (`idutilisateur`) ON DELETE NO ACTION ON UPDATE NO ACTION;
--
-- Contraintes pour la table `commentaire`
--
ALTER TABLE `commentaire`
  ADD CONSTRAINT `fk_Commentaire_Article` FOREIGN KEY (`idArticle`) REFERENCES `article` (`idArticle`) ON DELETE NO ACTION ON UPDATE NO ACTION;

Voilà pour la partie base de données SQL. Maintenant nous allons nous attaquer à la configuration. Nous allons tout d’abord créer les répertoires suivants :

  • Dossier contenant les données des tables en script YAML générés par Doctrine /application/configurations/data/fixtures
  • Dossier contenant les scripts SQL générés par Doctrine /application/configurations/data/sql
  • Dossier de migration de la base de données /application/configurations/migration
  • Dossier contenant le script de génération des cmodels /application/scripts
  • Dossier contenant nos models générés /library/App/Models

Quand la création des dossiers est faite, vous allez télécharger Doctrine 1.2.2. La version sandbox est inutile ici vu que les scripts donnés pour la génération doivent être complètement refait pour Zend.

Lorsque vous avez téléchargé Doctrine, vous allez extraire son contenu dans /library. Vous devriez alors avoir le dossier /library comme la capture sur votre droite. Le dossier vendor permet d’utiliser les scripts YAML quand au dossier Doctrine, il contient tout le cœur de Doctrine.

Maintenant que Doctrine a été correctement ajouté au dossier Library, Que la base de donnée a bien été ajoutée au SGBD, nous pouvons passer à la suite qui va consister à configurer proprement Zend.

Tout d’abord, nous allons rajouter les lignes suivantes au fichier /application/configurations/app.ini

; ---
; Doctrine
; ---

; configuration de base
; Le dsn correspond aux infos de connexion. Ici nous appelons une base mysql
; SGBD : MySqL
; Login : Root
; Password : azerty //si aucun password mettre juste root@localhost/bdd
; Serveur : localhost
; BDD : tutosite
doctrine.dsn                = "mysql://root:azerty@localhost/tutosite"
doctrine.data_fixtures_path = APPLICATION_PATH "/configurations/data/fixtures"
doctrine.sql_path           = APPLICATION_PATH "/configurations/data/sql"
doctrine.migrations_path    = APPLICATION_PATH "/configurations/migrations"
doctrine.yaml_schema_path   = APPLICATION_PATH "/configurations/schema.yml"
doctrine.models_path = APPLICATION_PATH "/../library/App/Models"

; règles lors de la génération des classes
; on utilise la convention de nommage PEAR
doctrine.generate_models_options.pearStyle  = true
; on génère les classes de table
doctrine.generate_models_options.generateTableClasses  = true
; on génère les classes de base. Ces classes contiennent les définitions de nos tables
doctrine.generate_models_options.generateBaseClasses  = true
; on définit un préfixe pour les classes de base
doctrine.generate_models_options.baseClassPrefix  = "Base_"
; on ne pet rien ici, avec la convention pear, ils seront ajoutés dans le sous dossier Base
doctrine.generate_models_options.baseClassesDirectory  =
; on ne met pas le préfixe au nom de fichier
doctrine.generate_models_options.classPrefixFiles  = false
; toutes les classes commenceront par ce préfixe
doctrine.generate_models_options.classPrefix = "App_Models_"

Ensuite, nous allons nous intéresser au /application/Bootstrap.php et nous allons ajouter la fonction d’initialisation de Doctrine :

protected function _initDoctrine() 
{
    //on met Doctrine en autoload
    $this->getApplication()
         ->getAutoloader()
         ->pushAutoloader ( array ('Doctrine', 'autoload' ) );
    spl_autoload_register(array('Doctrine', 'modelsAutoload'));

    //on récupère une instance de Doctrine
    $manager = Doctrine_Manager::getInstance ();

    //permet de valider automatiquement l'intégrité des données
    //ce qui veut dire que l'on ne peut pas mettre une variable de type string
    //dans une variable de type int.
    $manager->setAttribute (Doctrine::ATTR_VALIDATE, Doctrine::VALIDATE_ALL);
    //l’AUTO_ACCESSOR_OVERRIDE va nous permettre de personnaliser l’assignation de données.
    $manager->setAttribute ( Doctrine::ATTR_AUTO_ACCESSOR_OVERRIDE, true );
    //Doctrine permet de personnaliser également les classes de table en permettant 
    //de créer des méthodes propres à une table. 
    //Ce paramètre permet de charger le fichier contenant nos méthodes personnalisées.
    $manager->setAttribute (
     Doctrine::ATTR_MODEL_LOADING, 
     Doctrine::MODEL_LOADING_CONSERVATIVE
    );
    //on permet le chargement des classes table
    $manager->setAttribute ( Doctrine::ATTR_AUTOLOAD_TABLE_CLASSES, true );

    //on récupère toutes les options doctrine du fichier app.ini
    $doctrineConfig = $this->getOption('doctrine');

    //on récupère la variable doctrine.models_path du fichier app.ini
    //afin d'avoir le répertoire des models
    //pour que Doctrine les charge
    Doctrine::loadModels($doctrineConfig['models_path']);

    //on récupère la connexion à mysql et on la nomme doctrine
    $conn = Doctrine_Manager::connection($doctrineConfig['dsn'],'doctrine');
    //je sais plus ce que sa veut dire, mais il le faut
    $conn->setAttribute(Doctrine::ATTR_USE_NATIVE_ENUM,true);

    //on définit la sortie encodée en UTF-8
    $conn->setCharset('utf8');
    $conn->setCollate('utf8_general_ci');

    //on retourne la connexion
    return $conn;
}

Et pour que tout soit chargé directement, il suffit d’ajouter ces lignes dans la fonction _initNamSpaces() :

$autoloader->registerNamespace('Doctrine_');
$autoloader->registerNamespace('Doctrine');

Bien, maintenant Doctrine est correctement intégré à notre framework. Il ne reste plus qu’à générer les classes. Pour ce faire, il nous fait le fichier script suivant /application/scripts/Doctrine.php :

// Define path to application directory
defined('APPLICATION_PATH')
    || define('APPLICATION_PATH',
              realpath(dirname(__FILE__) . '/..'));

// Define application environment
defined('APPLICATION_ENV')
    || define('APPLICATION_ENV',
              (getenv('APPLICATION_ENV') ? getenv('APPLICATION_ENV')
                                         : 'production'));

// Typically, you will also want to add your library/ directory
// to the include_path, particularly if it contains your ZF install
set_include_path(implode(PATH_SEPARATOR, array(
    realpath(APPLICATION_PATH . '/../library'),
    get_include_path(),
)));

require_once 'Doctrine.php';

/** Zend_Application */
require_once 'Zend/Application.php';

// Create application, bootstrap, and run
$application = new Zend_Application(
    APPLICATION_ENV,
    APPLICATION_PATH . '/configurations/app.ini'
);

$application->getBootstrap()->bootstrap('doctrine');
$config = $application->getOption('doctrine');

$cli = new Doctrine_Cli($config);
$cli->run($_SERVER['argv']);

Vous l’aurez sans doute deviné, il s’agit du fichier /public/index.php avec à la fin l’instanciation de Doctrine. Cette instanciation nous permet d’utiliser, par le biais de la ligne de commande, Doctrine et, ainsi, générer nos classes.

Pour ce faire, allez dans votre invite de commande et rendez vous dans le dossier qui contient le script. Tapez juste la commande suivante :

php Doctrine.php

Elle devrait vous retourner le résultat suivant :

Il ne nous reste plus qu’à taper la commande :

php doctrine.php generate-models-db
php doctrine.php generate-yaml-db

Dans le dossier /application/configurations/ nous trouverons le dossier schema.yml contenant le script YAML de notre base de données. Et maintenant, si nous regardons dans le dossier /library/App/Models, nous avons pleins de classes de créées.

Prenons par exemple la table Utilisateurs. Elle aura 3 classes dédiées :

  • App_Models_Utilisateurs : permet de définir des fonction sur un objet utilisateur
  • App_Models_UtilisateursTable : permet de définir les différentes requêtes à faire sur notre table
  • App_Models_Base_Utilisateurs : contient la définition de la table Utilisateurs.

Justement, afin de tester et de bien comprendre ces classes, nous allons ajouter une fonction à la classe App_Models_UtilisateursTable. La fonction en question n’est rien d’autre qu’un fetchAll permettant de faire un Select de base.

/**
 * Select de base
 * 
 * @param string $where
 * @param string $order
 * @param int $limit
 * @param int $offset
 * @return Collection
 */
 public function fetchAll($where=null, $order=null, $limit=null, $offset=null)
 {
     $select = Doctrine_Query::create()->select('*')
         //dans le from on met le nom de la classe
         //Doctrine s'occupe du reste
         ->from('App_Models_Utilisateurs');

     if(isset($where)){ $select->where($where); }
     if(isset($order)){ $select->orderBy($order); }
     if(isset($limit)){ $select->limit($limit); }
     if(isset($offset)){ $select->offset($offset); }

     return $select->execute();
 }

Ensuite pour utiliser cette requête, nous allons éditier le controller Admin_AccueilController. Dans d’action d’index ajoutez les lignes suivantes :

//on récupère la classe table de App_Models_Utilisateurs
$table = Doctrine_Core::getTable('App_Models_Utilisateurs');
//on liste tout le monde
$liste = $table->fetchAll();
//on traite le résultat
foreach($liste as $unuser)
{
    print_r($unuser->login);
    print_r($unuser->passwd);
}

Normalement, si vous vous rendez sur la page concernée, vous devriez voir afficher le login et le mot de passe des utilisateurs. Voilà, maintenant vous pouvez utiliser Doctrine au sein du Framework Zend. La prochaine fois, nous verrons la création des premiers articles de notre Blog.

Installation de PHP 5.2 dotdeb sur Ubuntu

Installation de PHP 5.2 dotdeb sur Ubuntu

by Throrïn 0 Comments

Aujourd’hui je vais vous faire résoudre un problème récurent que j’ai eu sur mes serveurs. L’installation de PHP 5.2.13 sur Ubuntu en utilisant les paquets dotdeb.

Pourquoi passer par ces paquets ? Et bien c’est plus simple que de compiler soit même PHP et ça évite d’oublier des dépendances. Le problème des paquets dotdeb c’est qu’ils sont prévus pour Debian or, Ubuntu utilise des Library avec quelquefois des noms différents. Je vais donc vous expliquer pas à pas l’installation de cette version.

Cette procédure ne marche plus à partir d’Ubuntu 10.04 LTS. D’un car les dépendances ne sont plus disponibles, de deux car une version plus récente de PHP est disponible.

Tout d’abord, il vous faut ajouter les sources APT pour installer tout un serveur LAMP @dotdeb dans le fichier /etc/apt/sources.list:

deb http://packages.dotdeb.org stable all 
deb-src http://packages.dotdeb.org stable all

Ensuite, il vous faudra installer apache :

sudo aptitude install apache2 apache2-mpm-prefork apache2-prefork-dev apache2-utils apache2.2-common

Ensuite, si nécessaire, installez le serveur MySQL qui va bien:

sudo aptitude install mysql-client mysql-client-5.1 mysql-common mysql-server mysql-server-5.1 mysql-server-core-5.1

Pour finir nous allons installer toutes les Library requises pour l’installation de PHP.

sudo aptitude install libtidy-dev curl libcurl4-openssl-dev libcurl3 libcurl3-gnutls zlib1g zlib1g-dev libxslt1-dev libzip-dev libzip1 libxml2 libsnmp-base libsnmp15 libxml2-dev libsnmp-dev libjpeg62 libjpeg62-dev libpng12-0 libpng12-dev zlib1g zlib1g-dev libfreetype6 libfreetype6-dev libbz2-dev libxpm4-dev libmcrypt-dev libmcrypt4

Voilà. Malgré tout, il nous faut installer 3 Library introuvables par aptitude mais nécessaires à l’installation des paquets dotdeb. Nous récupérons les fichiers nécessaires avec l’utilitaire wget.

32bits:

wget http://us.archive.ubuntu.com/ubuntu/pool/main/k/krb5/libkrb53_1.6.dfsg.4~beta1-5ubuntu2_i386.deb
wget http://us.archive.ubuntu.com/ubuntu/pool/main/i/icu/libicu38_3.8-6ubuntu0.2_i386.deb
wget http://mirrors.kernel.org/ubuntu/pool/main/libt/libtool/libltdl3_1.5.26-1ubuntu1_i386.deb

64bits:

wget http://us.archive.ubuntu.com/ubuntu/pool/main/k/krb5/libkrb53_1.6.dfsg.4~beta1-5ubuntu2_amd64.deb
wget us.archive.ubuntu.com/ubuntu/pool/main/i/icu/libicu38_3.8-6ubuntu0.2_amd64.deb
wget http://mirrors.kernel.org/ubuntu/pool/main/libt/libtool/libltdl3_1.5.26-1ubuntu1_amd64.deb

Et nous installons les différents fichiers :

32bits:

sudo dpkg -i libkrb53_1.6.dfsg.4~beta1-5ubuntu2_i386.deb
sudo dpkg -i libicu38_3.8-6ubuntu0.2_i386.deb
sudo dpkg -i libltdl3_1.5.26-1ubuntu1_i386.deb

64bits:

sudo dpkg -i libkrb53_1.6.dfsg.4~beta1-5ubuntu2_amd64.deb
sudo dpkg -i libicu38_3.8-6ubuntu0.2_amd64.deb
sudo dpkg -i libltdl3_1.5.26-1ubuntu1_amd64.deb

Et voilà, il n’y a plus qu’à installer PHP :

sudo apt-get update
sudo apt-get install php5

Rajoutez les extensions utiles :

sudo apt-get install php5-apc php5-curl php5-gd php5-mcrypt php5-mhash php-pear php5-mysql

Voilà, maintenant vous avez un serveur LAMP fonctionnel avec PHP 5.2.13.

Introduction aux ETL

Introduction aux ETL

Dans ce sujet, je vais vous faire une introduction des ETL, leur fonctionnement global et leur utilité. Tout d’abord, ETL veut dire « Extracting, Transformation Loading ».

Cette technologie est surtout utilisée pour la création et l’alimentation de bases de données décisionnelles. En effet, pour concevoir une telle base de données, nous devons récupérer des données de différentes sources (bases SQL Serveur, Oracle, fichiers CSV, fichiers Excel, fichiers texte, …) se trouvant sur différents lieux (succursale commercial, direction, ..). Tout faire à la main se révèlerait très contraignant et très long, surtout s’il s’ait de plusieurs milliers de fichiers contenants chacun des milliards de lignes.

L’ETL va nous permettre d’automatiser tout ceci. Par contre, il en existe de nombreux en fonction de votre base de donnée, si vous en avez développé un, … Personnellement, ayant réalisé une maquette de base décisionnelle sous SQL Server 2005, j’ai donc testé l’ETL de Microsoft, il s’agit de SSIS et il faut avouer qu’avec les extensions Visual studio, son utilisation se révèle extrêmement simplifiée.

En quelques clics on peut définir nos sources de données, l’ordre d’exécution, quelles étapes on effectue en cas de succès ou d’échec. Vraiment un bon ETL.

Revenons donc à nos moutons. L’ETL va donc récupérer les données que vous voulez, les convertir au format souhaité (pour les rendre conforme à votre base) et les insérer dans la table. Vous pouvez ajouter des étapes supplémentaires comme la suppression des doublons, le regroupement de différentes sources pour les injecter dans une seule base cible, sélectionner seulement certains champs, … En bref, vous pouvez quasiment tout faire.

Pour vous illustrer un peu mieux, voici un petit schéma tout con permettant de bien comprendre que l’ETL peut récupérer de n’importe quelle source (ou presque) les données que vous voulez pour les envoyer vers votre base cible.

Enfin, j’espère que cette petite mise en bouche vous aura donné envie de tester ces petits ETL. Il en existe plus d’une dizaine pour MySQL mais chacun est spécialisé pour un certain nombre de données donc essayez de bien vous renseigner. Sinon avec SQL Server (sauf version express) vous avez automatiquement l’ETL SSIS de disponible.

Je vais peut être vous faire un exemple d’utilisation dans les semaines à venir. L’importation de données à partir d’un fichier texte et Excel sur une base de données.

Sensibilation sur les Index

Dans l’article du jour, j’aimerai vous parler des Index dans une base de données.

Comme leur nom l’indique, les index permettent d’indexer des colonnes d’une table. Mais quelle colonne à indexer et pourquoi ? Et bien c’est là la question. Si sur votre application vous avez plusieurs fois des requêtes qui ressortent avec une clause ‘WHERE’ ou ‘INNER JOIN’ faisant référence au même champ, plusieurs fois, il est conseillé de l’indexer.

Pourquoi ? Et bien tout simplement pour une raison d’optimisation. Votre base de données va stoker en mémoire des tables d’index contenant tous ces index. Au lieu d’aller gratter sur le disque-dur du serveur et ainsi le mettre à genoux si on se retrouve avec 1000 clients au même moment, la base de données va regarder en mémoire la table d’index et ressortir votre résultat directement.

Attention tout de même, d’une part, vos select seront optimisés (après les premières requêtes) mais en contrepartie, les enregistrements seront beaucoup plus long car au lieu d’inscrire votre enregistrement sur une table, il sera inscrit sur votre table ciblée mais aussi sur les différentes tables index. Donc réfléchissez bien à cela.

L’astuce consiste à droper les index de la table avant l’enregistrement et à les rajouter après. Ca ne modifiera rien du côté de votre table. Mais vous gagnerez quelques secondes voir quelques heures, selon le nombre d’index que contient votre table, lors de l’enregistrement.

Attention aussi, les clés étrangères ne sont pas indexées, donc cherchez-les bien et indexez-les. C’est l’une des premières causes de ralentissement d’un serveur de bases de données.

Tout ceci je l’ai appris en cours durant la semaine et j’avais envi de vous sensibiliser sur les indexes. C’est l’une des premières causes de ralentissement d’une base de données car la plupart des personnes oublient leur utilité.