Alex Kochis, chef de produit senior pour le « programme à valeur ajoutée Windows authentique » de Microsoft, a écrit dans un blog qu'une erreur humaine a conduit à l'erreur. Alex a déclaré que le nouveau logiciel avait été accidentellement chargé sur le serveur exécutant WGA. fonctionnent normalement et les applications raisonnables provenant d’utilisateurs de logiciels authentiques ne peuvent pas être traitées correctement. La base de données utilisée par les clients est MySQL et les produits développés prennent en charge Oracle Pour que les clients paient, nous devons changer l'environnement de base de données d'Oracle à MySQL. Nous avons rencontré les problèmes suivants au cours du processus de conversion et nous espérons fournir des références aux collègues qui ont rencontré le même problème. Si nous prêtons attention à la portabilité de la base de données lors du processus initial de conception et de codage, aucun travail supplémentaire n’est nécessaire dans ce cas.
1. Problèmes rencontrés lorsque l'environnement de base de données passe d'Oracle à MySQL.
Parce que la logique reste inchangée, le principe n'est pas de changer le code de l'application, seulement le sql de création/initialisation de la table de la base de données. Vous trouverez ci-dessous les problèmes que nous avons rencontrés et leurs solutions.
1. Différences sensibles à la casse (si le système d'exploitation du serveur est Linux).
Oracle n'est généralement pas sensible à la casse. Parfois, nous ne prêtons pas attention au problème de casse lors de l'utilisation d'Oracle. Les noms de tables et de champs ne sont pas sensibles à la casse sans guillemets doubles. Comme ceci : insert into tableName et insert into TABLENAME ont le même effet. Lors de l'initialisation des données, les résultats obtenus sont généralement convertis en noms de tables et de champs en majuscules.
Mais dans MySQL, la sensibilité à la casse du système d'exploitation utilisé détermine la sensibilité à la casse du nom de la base de données et du nom de la table. La base de données correspond à un répertoire du répertoire de données, et chaque table de la base de données correspond à au moins un fichier du répertoire de la base de données (ou plusieurs, selon le moteur de stockage). Par conséquent, utiliser une base de données ou une table revient en fait à manipuler ces fichiers (dossiers), de sorte que la sensibilité à la casse du système d'exploitation détermine la sensibilité à la casse du nom de la base de données et du nom de la table. Il est sensible à la casse dans les systèmes d'exploitation avec Linux comme noyau.
La solution consiste à conserver le nom de la base de données MySQL cohérent avec le cas d'Oracle et le nom de la table cohérent avec le nom de la table dans la chaîne SQL de l'application. Si le nom du champ dans l'application utilise des guillemets doubles, veuillez modifier le nom du champ. en SQL La casse du nom doit être cohérente avec les caractères placés entre guillemets doubles. Si les noms de tables et les champs référencés par votre application n'ont pas une casse uniforme, vous aurez de gros problèmes.
2. La différence entre les mots réservés.
Les noms de fonctions en langage SQL (tels que inteval, show) sont des mots réservés. Les mots réservés dans Oracle peuvent être utilisés comme noms de tables et de champs et n'affectent pas leur utilisation. Cependant, les mots réservés dans MySQL ne peuvent pas être utilisés comme noms de tables et de champs. S'ils sont utilisés, une erreur de syntaxe sera signalée.
La solution est de citer les mots réservés dans l'instruction SQL avec le symbole '`', qui se trouve au-dessus de la touche de tabulation du clavier ; s'il s'agit d'un nom de champ, il existe une autre méthode nom de table.nom de champ. Comme ceci : insérer dans tablename (id, `interval`) value(….. ou insérer dans tablename (id, tablename.inteval) value(….. .
3. Différences dans les types de données.
Dans MySQL, il n'y a pas de varchar2 et de nombre comme dans Oracle. Mysql a un varchar et un numérique correspondants. Bien sûr, il n'y a pas de type d'heure mysql dans Oracle.
La solution est le remplacement.
4. La différence entre les types de croissance automatique.
Oracle a une séquence, mais pas MySQL, mais il a l'attribut auto_increment.
La solution consiste à convertir la séquence dans Oracle pour utiliser l'attribut auto_increment. Dans certains cas, il peut exister un moyen de résoudre le problème. Créez une nouvelle table indépendante pour enregistrer les données de croissance automatique.
5. La différence dans les limites de longueur d'index.
À partir de MySQL 4.1.2, la longueur d'index des tables MyISAM et InnoDB prend en charge 1000 octets, ce qui signifie que la longueur du champ d'index ne peut pas dépasser 1000 octets. Si elle dépasse, l'erreur suivante sera signalée : ERREUR 1071 (42000) : La clé spécifiée était trop longue ; la longueur maximale de la clé est de 1 000 octets. S'il s'agit d'un encodage UTF-8, cela équivaut à une longueur de 333 caractères (car un caractère UTF8 occupe 3 octets). La limite de longueur d'index d'Oracle est beaucoup plus souple que celle de MySQL.
Il n'est pas nécessaire d'élaborer la solution, ni de modifier la définition de l'index, ni de modifier la longueur de définition du champ.
2. À quoi devons-nous faire attention pour la compatibilité des bases de données ?
La compatibilité des bases de données doit être un problème auquel il convient de prêter attention lors de la conception des bases de données, car parfois les clients ont des bases de données déjà utilisées et ne souhaitent pas gérer deux bases de données en même temps. Dans ce cas, la compatibilité avec plusieurs bases de données peut également devenir. un argument de vente du produit.
La clé pour assurer la compatibilité des bases de données est de respecter une utilisation standard.
1. Suivez l'utilisation standard et essayez de ne pas utiliser certaines utilisations spécifiques à la base de données.
Comme l'utilisation du symbole « » de msyql,
Pour un autre exemple, de nombreuses personnes utilisent Oracle pour créer une séquence, SELECT seq.nextval FROM DUAL; avant d'insérer des données dans la table, puis insérez la valeur obtenue à partir de la requête dans la table en tant que valeur. ne fonctionne pas. Il ne convient pas aux bases de données sans séquence. Chaque base de données a une utilisation de croissance automatique. Si vous avez besoin de l'utiliser, vous devez l'utiliser complètement.
Pour un autre exemple, différentes bases de données ont des requêtes de pagination étendues. Postgresql a un décalage et une limite, mais pas Oracle.
2. Évitez les problèmes de sensibilité à la casse dans la base de données.
Choisissez si les noms des tables et des champs de la base de données doivent être en majuscules ou en minuscules, et être complètement unifiés lors de la conception et du codage de la base de données.
3. Mots réservés.
Les concepteurs de bases de données doivent essayer de ne pas utiliser de mots réservés pour les noms de tables et de champs. De nombreuses personnes utilisent également cette méthode, en ajoutant '_' avant le nom de la table et le nom du champ, comme ceci : créer une table _tablename (_id entier). De cette façon, vous n'aurez jamais de problèmes causés par des mots réservés.