Le VARCHAR2 ne gère pas la chaine vide non plus, donc le problème reste le même.
J'aurais tendance à dire 'Do not use VARCHAR and VARCHAR2.. well do not use Oracle'.
J'aime pas Oracle pour ce genre de chose et des outils comme ora2pg sont appréciables.
(Il y a bien d'autres raisons, mais se serait mieux d'attendre Vendredi.)
Mélol, ton argument est: oui on peut utiliser un ORM dans les cas où on n'a pas vraiment besoin de base de données. Mais ce sont aussi les cas où on peut utiliser des fichiers plats, des technos expérimentales ou inadaptées (qui a pensé NoSQL ?), voire de la persistance over pigeons!
Pour la petite histoire,
J'ai utilisé des fichiers plats par le passé et j'ai eu logiquement des problèmes dans une application de monitoring grossissante après avoir stocké des dizaines de GO dans des fichiers similaires au format RRD. Remonter dans l'historique avec des filtres dans un RDBMS est plus efficace que scanner de simples fichiers de logs (ou alors il faut refaire la roue en commençant par indexer ..) Ça tombe bien, un RDBMS fait tout ça en mieux, en plus fiable, avec redondance, et fourni des outils de navigation, sauvegarde etc..
L'ORM permet de fabriquer la DDL, génère les bonnes requêtes INSERT/UPDATE sans que mon code n'ait à ce soucier de la base sous-jacente, de plus il se charge des conversions de types, des transactions, de la gestion propre des connexions et de la fabrication des objets.
Dans mon cas, l'ORM à facilité l'utilisation de l'infra existante chez le client (Oracle habituellement) afin d'y stocker les données collectées, mais surtout il peut générer des rapports PDF ou autre joyeusetés avec ses propres outils (basés la plupart du temps sur des requêtes SQL aussi).
Pour ce genre de situation, stockage et quelques requêtes dans l'historique, l'ORM est parfait et nécessite que très peu de changement dans le code de l'application. (Du coté perf, ce n'est pas une utilisation bien compliquée pour un ORM).
Donc oui, pour moi l'ORM à sa place dans certains contextes utilisants un RDBMS.
[^] # Re: Vide c'est nul(l) chez oracle.
Posté par petit_bibi . En réponse à la dépêche Migrer de Oracle à PostgreSQL : Ora2Pg. Évalué à 2.
Le VARCHAR2 ne gère pas la chaine vide non plus, donc le problème reste le même.
J'aurais tendance à dire 'Do not use VARCHAR and VARCHAR2.. well do not use Oracle'.
J'aime pas Oracle pour ce genre de chose et des outils comme ora2pg sont appréciables.
(Il y a bien d'autres raisons, mais se serait mieux d'attendre Vendredi.)
Pour la petite histoire,
J'ai utilisé des fichiers plats par le passé et j'ai eu logiquement des problèmes dans une application de monitoring grossissante après avoir stocké des dizaines de GO dans des fichiers similaires au format RRD. Remonter dans l'historique avec des filtres dans un RDBMS est plus efficace que scanner de simples fichiers de logs (ou alors il faut refaire la roue en commençant par indexer ..) Ça tombe bien, un RDBMS fait tout ça en mieux, en plus fiable, avec redondance, et fourni des outils de navigation, sauvegarde etc..
L'ORM permet de fabriquer la DDL, génère les bonnes requêtes INSERT/UPDATE sans que mon code n'ait à ce soucier de la base sous-jacente, de plus il se charge des conversions de types, des transactions, de la gestion propre des connexions et de la fabrication des objets.
Dans mon cas, l'ORM à facilité l'utilisation de l'infra existante chez le client (Oracle habituellement) afin d'y stocker les données collectées, mais surtout il peut générer des rapports PDF ou autre joyeusetés avec ses propres outils (basés la plupart du temps sur des requêtes SQL aussi).
Pour ce genre de situation, stockage et quelques requêtes dans l'historique, l'ORM est parfait et nécessite que très peu de changement dans le code de l'application. (Du coté perf, ce n'est pas une utilisation bien compliquée pour un ORM).
Donc oui, pour moi l'ORM à sa place dans certains contextes utilisants un RDBMS.
Ceci dit, les systèmes NOSQL sont intéressants.