De mon coté, une bonne raison de ne pas utiliser Oracle et de préférrer PostgreSQL ou H2, c'est cette dissymétrie sur les VARCHAR:
Tu insères une chaine vide dans une colonne, tu récupères un NULL lors de la lecture. Aucune distinction.
Ce genre de dissymétrie est très problématique dans le contexte d'un ORM, un champ pourtant affecté NON-NULL par le programmeur peut devenir NULL plus loin dans l'application.
Puis, sachant que deux NULL en SQL ne sont pas égaux. je pense qu'un [select * from where name=''] ne retourne jamais rien avec oracle.
C'est probablement très pénible dans d'autres contextes comme avec des contraintes genre VARCHAR2 UNIQUE NOT NULL.
Si mes souvenirs sont corrects, c'est historiquement pour gagner quelques bits d'espace lors du stockage.
VARCHAR ne suivant donc pas le standard SQL (arrivé plus tard), VARCHAR2 a été introduit pour assurer la compatibilité.
Ainsi, un jour peut-être, VARCHAR sera modifié afin de suivre le standard SQL.
Je ne sais pas ce qu'il en est aujourd'hui.
# Vide c'est nul(l) chez oracle.
Posté par petit_bibi . En réponse à la dépêche Migrer de Oracle à PostgreSQL : Ora2Pg. Évalué à 5.
De mon coté, une bonne raison de ne pas utiliser Oracle et de préférrer PostgreSQL ou H2, c'est cette dissymétrie sur les VARCHAR:
Tu insères une chaine vide dans une colonne, tu récupères un NULL lors de la lecture. Aucune distinction.
Ce genre de dissymétrie est très problématique dans le contexte d'un ORM, un champ pourtant affecté NON-NULL par le programmeur peut devenir NULL plus loin dans l'application.
Puis, sachant que deux NULL en SQL ne sont pas égaux. je pense qu'un [select * from where name=''] ne retourne jamais rien avec oracle.
C'est probablement très pénible dans d'autres contextes comme avec des contraintes genre VARCHAR2 UNIQUE NOT NULL.
Si mes souvenirs sont corrects, c'est historiquement pour gagner quelques bits d'espace lors du stockage.
VARCHAR ne suivant donc pas le standard SQL (arrivé plus tard), VARCHAR2 a été introduit pour assurer la compatibilité.
Ainsi, un jour peut-être, VARCHAR sera modifié afin de suivre le standard SQL.
Je ne sais pas ce qu'il en est aujourd'hui.
Je me demande comment ora2pg traite ça d'ailleur.