En théorie, tout devrait bien se passer, mais il existe toujours des scénarios dans lesquels votre code peut échouer.
Par exemple :
a) blind insert :
INSERT INTO tab_name
VALUES (1, 'b', 'c');
Une insertion aveugle se produit lorsqu'une requête INSERT ne spécifie pas quelles colonnes reçoivent les données insérées.
Pourquoi est-ce une mauvaise chose ?
Parce que le schéma de la base de données peut changer. Les colonnes peuvent être déplacées, renommées, ajoutées ou supprimées. Et lorsqu'ils le sont, l'une des trois choses suivantes peut se produire :
La requête échoue. C'est le meilleur scénario. Quelqu'un a supprimé une colonne de la table cible, et maintenant il n'y a plus assez de colonnes pour l'insertion, ou quelqu'un a changé un type de données et le type inséré n'est pas compatible, etc. Mais au moins vos données ne sont pas corrompues, et vous savez peut-être même que le problème existe à cause d'un message d'erreur.
La requête continue de fonctionner et rien ne va pas. Il s'agit d'un scénario moyen-pire des cas. Vos données ne sont pas corrompues, mais le monstre se cache toujours sous le lit.
- La requête continue de fonctionner, mais certaines données sont désormais insérées à un endroit auquel elles n'appartiennent pas. Vos données sont corrompues.
b) ORDER BY oridinal
SELECT *
FROM tab
ORDER BY 1;
