Je vous propose au travers de ce tutoriel de mettre en évidence 3 bonnes pratiques concernant la gestion de base de données sous CodeIgniter et plus particulièrement par rapport à la création de modèles basés sur la classe Active Record.
Je précise avant tout que les points évoqués ci-après sont pleinement compatibles avec ACICRUD, ma librairie d’abstraction de modèles pour CodeIgniter.
Gérer efficacement les préfixes de tables
Afin de débuter cet article, parlons des préfixes de tables pour vos applications. Puisqu’il est admit par le simple fait d’utiliser une librairie d’abstraction de base de données comme Active Record sous CodeIgniter, que votre base de données est abstraite, c’est à dire que l’on ne connaît pas en théorie quel système de gestion de base de données est utilisé en production, je considère également admit que vous ne devriez pas connaître la liste des tables présentes dans la base de données de production (ou du moins qu’il ne faut pas en tenir compte lors de la création du schéma de base de données de votre application).
Ainsi, afin d’éviter toute collision de table avec un autre système utilisant la même base de données, il devient très utile de préfixer l’ensemble des tables de notre application par une chaîne unique mais explicite.
Pour illustrer ceci, nous allons partir du principe que nous concevons une application nommée « Gestion » pour un client donné. Nous ne pouvons pas connaître à l’avance la liste des tables dans la base de données qu’utilise déjà notre client pour ses autres applications.
Aussi, afin d’éviter toute collision sur les noms de tables, nous allons choisir de préfixer nos tables avec la chaîne « gestion_ ».
C’est ainsi que toutes nos tables SQL devront être créées avec ce préfixe, comme par exemple « gestion_user », « gestion_user_acl », etc. De cette manière, si la base de données de production comporte déjà une table nommée « user », cela ne générera aucun conflit.
Ceci est très facilement gérable avec CodeIgniter, en effet il suffit d’indiquer le préfixe de table à utiliser dans le fichier de configuration database.php. Ainsi, Active Record utilisera automatiquement le préfixe de nos tables pour lors de la génération de requêtes SQL.
$db['production']['hostname'] = "localhost";
$db['production']['username'] = "root";
$db['production']['password'] = "password";
$db['production']['database'] = "the_production_database";
$db['production']['dbdriver'] = "mysql";
$db['production']['dbprefix'] = "gestion_";
$db['production']['pconnect'] = FALSE;
$db['production']['db_debug'] = FALSE;
$db['production']['cache_on'] = FALSE;
$db['production']['cachedir'] = "";
$db['production']['char_set'] = "utf8";
$db['production']['dbcollat'] = "utf8_general_ci";
Ne pas coder en dur les noms de table !
Voici une règle simple mais souvent oubliée : éviter de coder en dur. Ceci est particulièrement valable pour les noms de tables !
Voici comment profiter simplement de la programmation orientée objet afin de transformer notre nom de table en attribut de classe de notre modèle.
Ainsi, à chaque fois que nous aurons besoin d’appeler la table utilisée par le modèle, il suffira d’utiliser $this->table, ce qui aura également comme avantage de rendre les méthodes du modèle plus génériques.
Utiliser un préfixe de table avec la classe Database
Il existe certains cas de figures ou les méthodes évoquées ci-dessus ne suffisent pas totalement. C’est notamment le cas lorsqu’une requête SQL doit être effectuée sur plusieurs tables ou lorsque le query builder d’Active Record n’est plus utilisé.
Prenons un exemple concret en sélectionnant des données dans la table gestion_user via la méthode query(). Dans ce cas précis, le préfixe de table ne sera pas automatiquement ajouté par CodeIgniter puisque query() permet justement d’écrire manuellement une requête SQL.
Il faut alors utiliser $this->db->dbprefix() afin de générer le préfixe de table adéquat.
Notez que les deux méthodes produisent un résultat identique.
Conclusion
Il existe de nombreuses méthodes permettant d’améliorer la qualité et la généricité des modèles sous CodeIgniter, et nous n’abordons même pas les notions d’ORM ou de CRUD dans cet article. Quoiqu’il en soit, je suis sûr que chaque développeur CodeIgniter utilise ses propres techniques, aussi n’hésitez pas à partager les vôtres en commentant ce billet 😉
