KB-LJW-DB-105
Articles et ressources connexes
- KB-LJW-DB-101 : Impact des types de curseurs ADO sur un driver ODBC en ASP
- KB-LJW-DB-104 : Gestion des données de type "DATE" avec MySQL et MariaDB
Drivers MariaDB installés sur nos serveurs ASP Classic
Pour des raisons de fiabilité et de pérennité de licence, le moteur de bases de données MariaDB est installé sur nos hébergements mutualisés ASP Classic. Le moteur de bases de données MySQL est quant à lui toujours disponible et installé sur demande sur nos serveurs dédiés, en version 8.x ou 5.x.
Le moteur MariaDB sait importer et exécuter vos bases MySQL. Les Drivers ODBC disponibles sur nos serveurs mutualisés pour accéder à vos bases MariaDB sont les suivants :
- {MariaDB ODBC 3.2 Driver}
- {MySQL ODBC 5.3 Unicode Driver}
- {MySQL ODBC 3.51 Driver}
Qu'est-ce que MariaDB
MariaDB est un système de gestion de base de données relationnelle open source, compatible avec MySQL dont il est un dérivé. Ce moteur est conçu pour stocker, interroger et manipuler des données structurées à l'aide du langage SQL. Étant né d'un fork (bifurcation du code source) de MySQL en avril 2009, MariaDB vise à offrir une continuité technique : il utilise mêmes concepts fondamentaux (tables, index, moteurs de stockage, transactions), les mêmes protocoles réseau, et une très forte compatibilité au niveau des requêtes et des schémas.
MySQL était détenu et sponsorisé par la société suédoise MySQL AB, qui a été rachetée en février 2008 par Sun Microsystems, devenu aujourd'hui Oracle Corporation. En 2009-2010, lorsque Oracle a acquis Sun, un fork (une branche séparée) issue du projet open source MySQL a été créée : MariaDB. Cette branche séparée a été créée en raison d'inquiétudes concernant la gestion de produits d'Oracle et sa politique commerciale et tarifaire susceptible d'évoluer de manière arbitraire et de menacer la gratuité voire la disponibilité même de MySQL à moyen terme.
Tous deux partagent le même moteur et une très forte compatibilité technique, du fait que les bases MySQL et MariaDB peuvent être converties d'un moteur à l'autre et fonctionner de la même manière, avec parfois des ajustements mineurs. De ce fait, MariaDB est considéré comme un remplacement direct pour MySQL.
MariaDB s'est imposé comme le projet le plus dynamique et le plus régulièrement mis à jour. MariaDB a été adopté par de plus en plus de sociétés et produits, comme Google, Mozilla, ou encore Plesk qui l'a désormais intégré en standard depuis 2022 en remplacement de MySQL, ce dernier n'étant plus installé par Plesk par défaut. Les principaux avantages de MariaDB sont son caractère libre et gratuit, ainsi que le dynamisme et la régularité dans sa production de mises à jour, d'innovations et d'optimisations.
MariaDB constitue une alternative solide et mature largement adoptée en production par de nombreuses entreprises et acteurs. Son développement communautaire, sa gouvernance ouverte et son rythme d'innovation en font un choix pertinent permettant d'utiliser un équivalent de MySQL, mais sans dépendance à un éditeur unique (Oracle).
Importation de bases de données MySQL vers MariaDB
Du fait de la racine commune aux moteurs MySQL et MariaDB, l'importation de données est en général très simple. Assurez-vous de disposer d'un backup natif de votre base MySQL, à savoir un backup réalisé par le moteur MySQL lui-même, ou un outil fiable comme les DUMP Plesk, NaviCat, ou phpMyAdmin. Des sauvegardes de votre base MySQL réalisées avec des logiciels moins fiables (ex. EMS SQL Manager for MySQL) ou d'anciennes versions peuvent s'avérer moins compatibles, et s'avérer plus complexes à importer dans MariaDB.
Nos clients effectuent par exemple fréquemment des importations de ce type :
- Depuis : MySQL 5.x (moteur de stockage MyISAM) avec encodage "utf8_general_ci"
- Vers : MariaDB 11.4 (moteur de stockage InnoDB) avec encodage "utf8mb4_unicode_ci"
Une fois votre base de données convertie vers le moteur MariaDB, nous vous déconseillons de restaurer ou importer d'anciens backups MySQL de votre base sous peine de provoquer une corruption de données. Une telle importation est possible avec des précautions et vérifications préalables des données. Nous pouvons vous assister si vous souhaitez importer des données depuis MySQL vers MariaDB.
Comment gérer et administrer les bases MariaDB
Les bases de données MariaDB disponibles dans vos hébergements fournis sur nos serveurs sont accessibles de la même manière que vos bases MySQL, à savoir depuis l'interface PHPMyAdmin fournie depuis Plesk, et depuis tout autre logiciel de gestion à distance de bases de données compatible.
Concernant cette compatibilité, les logiciels clients de gestion de bases de données que vous utilisez pour gérer vos bases doivent être en mesure de prendre en charge de manière fiable des connections à un serveur MariaDB 11.4+, au moteur de stockage InnoDB, et à l'encodage/collation utf8mb4_unicode_ci. Nous recommandons à titre d'exemple HeidiSQL (gratuit), Navicat (payant), ou DbVisualizer (payant), cette liste étant non exhaustive. D'autres programmes existent selon vos besoins et vos préférences, mais assurez-vous de leur fiabilité et privilégiez les versions récentes et à jour.
Comment accéder aux bases MariaDB depuis ASP Classic
La connexion à vos bases de données MariaDB depuis votre site ASP Classic s'effectue de la même manière que vous le faites avec MySQL. Seul le nom du Driver ODBC change, et éventuellement les OPTION (Flags) que vous indiquez dans votre chaîne de connexion.
L'accès à vos bases de données MariaDB depuis vos pages ASP via ADO doit se faire à l'aide du Driver {MariaDB ODBC 3.2 Driver} ou {MariaDB ODBC 3.1 Driver} en fonction de celui installé sur le serveur Windows.
Les moteurs de MariaDB et de MySQL étant proches, vous pouvez même accéder à vos bases MariaDB via le Driver {MySQL ODBC 3.51 Driver} ou bien {MySQL ODBC 5.3 Unicode Driver}. Toutefois, ce procédé n'est à utiliser que dans des cas très spécifiques et si vous maîtrisez parfaitement ce que vous faites. D'une manière générale il est recommandé d'utiliser le Driver ODBC fourni et prévu à cet effet {MariaDB ODBC 3.2 Driver}.
L'établissement de connexions à d'autres sources de données, comme par exemple Microsoft Access ou Excel peuvent faire figurer le paramètre Provider= dans la chaîne de connexion. En l'absence de ce paramètre, ADO utilise le provider par défaut pour les Drivers ODBC, à savoir MSDASQL (Microsoft OLE DB provider for ODBC).
Lorsque vous établissez une connexion à votre base MariaDB via un Driver ODBC depuis votre code ASP, vous établissez une connexion dite "DSN-Less". Vous n'avez dans ce cas pas besoin de spécifier Provider=MSDASQL dans votre chaîne de connexion : il est implicitement utilisé par ADO. Consultez à cet effet notre article relatif à l'impact des types de curseurs ADO sur l'accès à vos bases MariaDB.
Une exception à noter : vous devrez probablement ajouter Provider=MSDASQL; DSN=MonDSN; à votre chaîne de connexion si vous établissez votre connexion via un DSN.
L'utilisation d'un Driver conçu pour MySQL peut vous permettre dans certains cas d'éviter certains bugs qui peuvent survenir si vous accédez à vos Recordset de manière trop permissive. À l'inverse, l'utilisation d'un Driver conçu pour MySQL ne devrait pas vous être nécessaire si vous avez codé votre ASP Classic en suivant les bonnes pratiques liées à la déclaration explicite du type de curseur via la propriété rs.CursorType.
Le code suivant vous montre comment établir une connection DSN-Less à votre base de données MariaDB, et à spécifier certains Flags dans le paramètre OPTION.
<%
'Déclarer les Options/Flags de connexion MariaDB possiblement utiles avec ADO + ASP Classic (liste non-exhaustive)
'Références & Listes (incomplètes) :
'https://mariadb.com/docs/connectors/mariadb-connector-odbc/mariadb-connector-odbc-guide#general-connection-parameters
'https://docs.skysql.com/Connecting%20to%20SkySQL%20DBs/Connect%20using%20ODBC/#options-bitmask
'Certaines Options/Flags de connexion existent et sont héritées du moteur MySQL :
'https://dev.mysql.com/doc/connector-odbc/en/connector-odbc-configuration-connection-parameters.html#codbc-dsn-option-flags
Dim CONST_DB_MARIADB__FOUND_ROWS : CONST_DB_MARIADB__FOUND_ROWS = 2
Dim CONST_DB_MARIADB__NO_PROMPT : CONST_DB_MARIADB__NO_PROMPT = 16
Dim CONST_DB_MARIADB__DYNAMIC_CURSOR : CONST_DB_MARIADB__DYNAMIC_CURSOR = 32
Dim CONST_DB_MARIADB__NO_SCHEMA : CONST_DB_MARIADB__NO_SCHEMA = 64
Dim CONST_DB_MARIADB__COMPRESSED_PROTO : CONST_DB_MARIADB__COMPRESSED_PROTO = 2048
Dim CONST_DB_MARIADB__NO_CACHE : CONST_DB_MARIADB__NO_CACHE = 1048576
Dim CONST_DB_MARIADB__FORWARD_CURSOR : CONST_DB_MARIADB__FORWARD_CURSOR = 2097152
Dim CONST_DB_MARIADB__MULTI_STATEMENTS : CONST_DB_MARIADB__MULTI_STATEMENTS = 67108864
'Déclarer la valeur (somme) des options à fournir au Driver ODBC MariaDB
'(liste recommandée, à personnaliser selon vos besoins)
Dim dbConnOptions
dbConnOptions = CONST_DB_MARIADB__FOUND_ROWS + CONST_DB_MARIADB__NO_PROMPT
'Déclarer la chaine de connexion à la base via le Driver MariaDB
Dim dbConnString : dbConnString = "Driver={MariaDB ODBC 3.2 Driver}; Server=127.0.0.1; Charset=utf8; Port=3306; Database=dbName_abcdef; User=dbUser_test_abc123; Password=dbPw_abcdef12345; Option=" & dbConnOptions & ";"
'Si vous utilisez des tables encodées en utf8mb4, ajoutez ceci à votre chaine de connexion :
dbConnString = dbConnString & "InitStmt={SET NAMES 'utf8mb4';}"
''ALTERNATIVE : Le type de collation est normalement déjà inclus dans la définition de la table.
''Vous pouvez toutefois le forcer pour cette connexion si vous le souhaitez :
'dbConnString = dbConnString & "InitStmt={SET NAMES 'utf8mb4' COLLATE utf8mb4_unicode_ci;}"
'Ouvrir la connexion à la base de données
Set dbConn = Server.CreateObject("ADODB.Connection")
dbConn.Open dbConnString
%>Vous disposez également du paramètre INITSTMT qui permet d'exécuter des instructions SQL au démarrage de la connexion. Si vous souhaitez exécuter plusieurs instructions SQL au démarrage de votre connexion, vous devez impérativement protéger ces différentes instructions SQL par des accolades {} afin de les regrouper. Dans le cas contraire les point-virgule qui séparent chaque instruction SQL seront à tort interpétés par le parseur ODBC. C'est une nuance importance du fait que le point-virgule est utilisé comme séparateur à la fois par le parseur SQL et par le parseur ODBC ! La forme correcte est donc : InitStmt={SET SESSION sql_mode='STRICT_TRANS_TABLES,NO_ZERO_DATE,NO_ZERO_IN_DATE'; SET time_zone='+00:00'; SET NAMES utf8;}. Vous devrez avoir ajouté la valeur du Flag MULTI_STATEMENTS (67108864) pour pouvoir exécuter plusieurs instructions. Notez enfin que certains Drivers ODBC n'exécutent que la première instruction SQL et ignorent les suivantes.
Moteurs de stockage MyISAM et InnoDB
Les serveurs de bases de données MySQL et MariaDB prennent en charge les deux types de moteurs principaux que sont MyISAM et InnoDB. Toutefois, pour les raisons évoquées plus bas dans les paragraphes à venir, nous vous recommandons de privilégier le moteur de stockage InnoDB, et de migrer les tables de votre base de données depuis le moteur MyISAM vers le moteur InnoDB. Vous pouvez effectuer cette conversion progressivement, table après table. Nous sommes à votre disposition pour vous assister dans cette opération si vous le souhaitez.
Le moteur de stockage MyISAM est ancien et était historiquement utilisé par défaut par MySQL. Il est encore supporté par MySQL et MariaDB. Depuis plusieurs années désormais, le moteur de stockage InnoDB est devenu le standard, en raison de sa plus grande fiabilité et de ses meilleures performances générales tant en lecture qu'en écriture. Le moteur InnoDB supporte bien mieux la montée en charge en termes de volume de données et de trafic que le moteur MyISAM, qui peut provoquer des ralentissements lorsque des volumes à grande échelle sont atteints. L'une des principales raisons d'utiliser InnoDB plutôt que MyISAM est l'absence de verrouillage complet au niveau de la table, ce qui permet d'accélérer le traitement des requêtes.
Les principales différences entre InnoDB et MyISAM sont les suivantes :
- InnoDB est doté d'un verrouillage granulaire. MyISAM ne dispose que d'un verrouillage complet au niveau de la table entière.
- InnoDB possède ce qu'on appelle l'intégrité référentielle qui implique la prise en charge des clés étrangères (SGBDR) et des contraintes relationnelles, ce que MyISAM ne fait pas (DMBS).
- InnoDB supporte les transactions, ce qui signifie que vous pouvez les valider ou les annuler. Ce n'est pas le cas de MyISAM, qui applique de facto toute requête.
- InnoDB est plus fiable car il utilise les logs de transactions pour la récupération automatique, ce qui n'est pas implémenté dans MyISAM.
Encodage et collation
Encodage des caractères (charset)
Dans le moteur MariaDB, l'encodage (charset / jeu de caractères) définit comment les caractères sont représentés en mémoire et stockés sur disque. L'encodage répond à la question : « quels symboles puis-je stocker et comment sont-ils codés en octets ? ». Par exemple, l'encodage utf8mb4 permet de représenter l'ensemble du jeu de caractères Unicode (y compris les émojis), tandis que l'encodage latin1 sait stocker un nombre de caractères beaucoup plus limité.
Collation des caractères
La collation ne concerne pas le stockage des caractères en lui-même, mais la manière de comparer et trier les chaînes de caractères. Elle définit les règles linguistiques : sensibilité à la casse, aux accents, ordre alphabétique, et équivalences entre caractères. En résumé, l'encodage décrit ce qui peut être stocké, et la collation indique comment ces données stockées sont comparées. La collation de référence pour l'encodage utf8mb4 est la collation utf8mb4_unicode_ci.
Plusieurs collations existent pour un seul et même encodage (par exemple utf8mb4_general_ci, utf8mb4_unicode_ci, utf8mb4_bin), et son choix impactera la manière de comparer, trier et classer vos données. En cas de nécessité, le type de collation peut être forcé lors de l'exécution de votre requête SQL via COLLATE, comme le présente cet exemple :
SELECT * FROM myTable ORDER BY myTable.champ COLLATE utf8mb4_unicode_ci;Relations entre encodage et collation
Encodage et collation sont intimement liés, car chaque collation est définie pour un encodage donné. Vous ne pouvez donc pas appliquer une collation utf8mb4_* à une colonne dont le jeu de caractères est défini en latin1. MariaDB utilise donc toujours le couple encodage–collation pour manipuler du texte. En pratique, cela a des conséquences directes : une clause ORDER BY, un GROUP BY ou une comparaison (= , LIKE) dépendra de la collation, tandis que les problèmes de caractères corrompus (symboles �) relèvent presque toujours d'un mauvais encodage.
Il peut parfois être tentant de modifier la collation pour « corriger » un problème d'affichage, mais cela ne fonctionne très rarement. La règle saine est simple : choisissez un encodage moderne et universel (nous recommandons utf8mb4), puis sélectionner une collation adaptée au comportement métier attendu (comparaison stricte, insensible à la casse, respect linguistique, etc.) (nous recommandons utf8mb4_unicode_ci).
Documentation officielle de MariaDB relative aux charsets et collations disponibles :
- Présentation et généralités sur les charsets et les collations sur MariaDB
- Liste des charsets et collations disponibles sur MariaDB
Conversion de l'encodage vers "utf8mb4_unicode_ci"
Cette section vous présente les avantages d'effectuer une migration des tables avec un encodage utf8_general_ci ou latin1_swedish_ci vers utf8mb4_unicode_ci.
Sachez avant toute chose que MariaDB prend en charge tous les charsets et collations historiquement utilisés par MySQL. Vous n'avez donc aucune obligation à effectuer cette migration. Toutefois, si vos tables sont destinées à contenir des données avec des caractères accentués, des informations saisies par les utilisateurs, ou des caractères avancés (tels que les Emojis), alors la lecture de cette section sera probablement la meilleure décision que vous aurez prise aujourd'hui !
UTF-8 est une méthode d'encodage qui traduit tout caractère basé sur Unicode en une chaîne. UTF-8 est l'un des systèmes d'encodage les plus fréquemment utilisés pour Unicode. UTF signifie « Unicode Translation Format » : son rôle est de traduire les caractères Unicode en chaînes binaires correspondantes et vice versa.
L'encodage utf8mb4 offre un support Unicode complet et prend en charge une gamme plus large de caractères, ce qui permet d'utiliser des symboles nécessitant jusque 4 octets par caractère. Cette plage de caractères inclut les nouveaux Emojis, les smileys comme ☺, 😍, 😐, etc.
Or, contrairement à sa dénomination, l'encodage utf8 dans MySQL n'est pas conforme à la norme UTF-8, du fait qu'il ne prend pas en charge le bon nombre d'octets par caractère. MySQL a corrigé cette erreur à partir de MySQL 8 seulement, utilisant désormais par défaut le jeu de caractères utf8mb4 au lieu du utf8 incomplet, utilisé jusqu'alors dans les précédentes versions, et en particulier MySQL 5.x. De ce fait, afin d'assurer une prise en charge complète et correcte du standard UTF-8, il convient d'utiliser l'encodage de caractère utf8mb4.
L'encodage latin1_swedish_ci était pour sa part le collationnement par défaut de MySQL 5.x (avant MySQL 8) pour l'encodage latin1 (ISO-8859-1), historiquement choisi pour des raisons de simplicité et de performances, sans lien réel avec la langue suédoise. Il a longtemps été accepté et utilisé par inertie, mais il gère mal les langues non occidentales, les caractères accentués complexes, et toute compatibilité Unicode moderne, ce qui a causé d'innombrables erreurs d'encodage silencieuses. Des données corrompues et stockées avec le mauvais encodage dans vos tables sont très difficilement récupérables. À son époque, il était rapide, léger et suffisant pour des applications occidentales simples. Il est aujourd'hui déprécié et déconseillé, à la faveur d'une migration vers utf8mb4.
MariaDB pour sa part est plus respectueux des normes car plus récent. Il gère nativement l'encodage utf8mb4 de manière fiable. La gestion incomplète de l'UTF-8 dans MySQL 5.x rend impossible le stockage de caractères nécessitant 3 ou 4 octets compris dans la norme UTF-8, comme les Emojis, désormais couramment utilisés. Tenter d'insérer de tels caractères dans une table en utf8 (n'étant pas en utf8mb4) provoque des erreurs d'exécution du type : Valeur de chaîne incorrecte : « \x77\xD0 » pour la colonne "column_name" à la ligne 1. Cela est la principale raison pour laquelle certaines données s'affichent de manière incorrecte pour certains utilisateurs de MySQL utilisant cet encodage utf8 historique.
Il est utile de noter que deux types d'encodage sont disponibles pour le utf8mb4 :
- utf8mb4_unicode_ci, qui est parfaitement aligné avec la norme réelle UTF-8, et est donc recommandé et utilisé par défaut par MariaDB et les versions récentes de MySQL (8.x)
- utf8mb4_general_ci, qui est destiné aux cas d'utilisation généraux. Bien que ce jeu de caractères s'appelle utf8mb4, il est lui-aussi implémenté de manière incomplète dans MySQL. Il s'agit d'une version parcellaire de utf8mb4 conçue pour prendre des raccourcis afin d'améliorer les performances de la base de données.
Cas particuliers avec MariaDB
Du fait que MariaDB est plus récent que MySQL, il respecte davantage la norme ODBC 3.8, et s'avère moins permissif dans certains cas très spécifiques.
Dans l'immense majorité des cas, l'importation de vos bases de données existantes MySQL fonctionnera immédiatement sur le moteur MariaDB, avec souvent des gains de performances.
Certains cas très particuliers peuvent survenir : consultez notre base de connaissances, ou prenez contact avec notre équipe pour vous assister si vous rencontrez une quelconque difficulté.
Gestion des données de type DATE
Il se peut que vous rencontriez quelques cas particuliers concernant la gestion des champs de type Date, notamment avec des valeurs vides, ou si vous souhaitez les stocker dans un format différent du standard ISO YYYY-MM-DD HH:MM:SS.
Référez-vous aux conseils et bonnes pratiques dans notre article KB-LJW-DB-104 à ce sujet.
Curseur par défaut
Le Driver {MariaDB ODBC 3.2 Driver} utilise par défaut un curseur Forward-Only (SQL_CURSOR_FORWARD_ONLY) si le type de curseur n'est pas fourni dans les OPTION de votre chaîne de connexion. Cela diffère du comportement précédemment observé avec le Driver {MariaDB ODBC 3.1 Driver}, qui utilisait un curseur statique (SQL_CURSOR_STATIC) comme curseur par défaut.
ADO ne laisse jamais la main au curseur par défaut du Driver ODBC, et spécifie à-minima 0=adOpenForwardOnly. Par conséquent, ce changement au niveau du Driver ODBC ne devrait en pratique avoir aucun impact sur votre code ASP.
Référez-vous à notre article KB-LJW-DB-101 à ce sujet.
Nous vous assistons avec IIS et votre code ASP Classic.
Prenez contact avec notre équipe.
