1)Ah bon !
Enfin, ce qui m'étonne quand même, c'est que si Oracle ne fait pas mieux que Postgres (au niveau du support des Blobs) alors ça ne m'explique pas pourquoi ils ne sont pas revenus en arrière juste après leur migration.
D'autant plus que c'était vraiment une boite pro-opensource ... en fait je crois qu'Oracle était la seule appli non libre utilisée dans toute la boite.
Même si la dernière version en date de Postgres (sortie depuis) commencer à supporter correctement les blobs, ça doit faire un sacré bail qu'Oracle fait la même chose.
Au passage, tu sais si Postgres gère les "ALTER TABLE DROP COLUMN", sous Oracle il faut attendre la 8.1 pour que ça marche. C'est chiant d'avoir à
copier une table juste pour virer une colonne.
2) tu sais pour faire un import/export entre deux version d'Oracle différentes sur une base de 75 Mo c'est dèja long à cause de la conversion, alors pour une base de cette taille, surtout si tu dis que Postgress rame au niveau des import, il faudrait peut-être un week-end.
D'ailleurs, au niveau hardware ça n'aurait pas de sens d'héberger une telle base sur un PC sous Redhat Linux avec disque IDE, je doutes que les perfs en IO soutiennent la comparaison avec une SUN, son bus à commutation de paquet et les disques SCSI qui vont avec.
En plus, tu n'a pas l'air de savoir que le SQL n'est pas vraiment portable (un peu comme pour les compilo C, va compiler le kernel sous Visual) : tout les SGDB ont des parties de la norme qu'ils n'implémentent pas ou mal et c'est rarement les mêmes.
3) Mais est-ce que c'est vraiment viable en pratique, pour des gens qui font des dumps souvent ?
Si le fichier est beaucoup plus gros (car il contient des requètes en + des données) et si la restauration est significativement plus longue, ça peut être prohibitif à l'usage
4) Enfin, je pense aussi que pour les petits projets, Postgres (ou MySQL) doit largement suffire. D'ailleurs, on trouve même pas mal de base sous Access dans les PME (hé oui il y a un moteur SQL).
Notes :
1) Optimisation spécifique Oracle : tout SGDB qui se respecte à un optimiseur intégré, donc l'ordre dans lequel tu écris les clauses ne devrait pas influencer les perfs.
Par contre, on peut utiliser des "binding variable" pour qu'il puisse cacher la version compilée (et réordonnée) de la requète.
2) Index : Si la table est petite, ça va plus vite en balayant la table.
Par requète "compliquée", j'entendait au niveau des conditions de jointure : si elle porte sur une seule colonne c'est facile de l'indexer, par contre si il y en a beaucoup, créer un index sur des colonnes multiples (et nombreuses de surcroit) peut ne pas servir à grand chose (enfin c'est ce que j'ai compris).
3) "Les blobs c'est sale" : c'est vrai mais quand tu en as besoin, tu peux pas faire autrement
[^] # Re: Oracle moins bien que PostgresSQL (suite)
Posté par Stephane JUTIN . En réponse à la dépêche Red Hat s'éloigne de plus en plus du libre. Évalué à -2.
Enfin, ce qui m'étonne quand même, c'est que si Oracle ne fait pas mieux que Postgres (au niveau du support des Blobs) alors ça ne m'explique pas pourquoi ils ne sont pas revenus en arrière juste après leur migration.
D'autant plus que c'était vraiment une boite pro-opensource ... en fait je crois qu'Oracle était la seule appli non libre utilisée dans toute la boite.
Même si la dernière version en date de Postgres (sortie depuis) commencer à supporter correctement les blobs, ça doit faire un sacré bail qu'Oracle fait la même chose.
Au passage, tu sais si Postgres gère les "ALTER TABLE DROP COLUMN", sous Oracle il faut attendre la 8.1 pour que ça marche. C'est chiant d'avoir à
copier une table juste pour virer une colonne.
2) tu sais pour faire un import/export entre deux version d'Oracle différentes sur une base de 75 Mo c'est dèja long à cause de la conversion, alors pour une base de cette taille, surtout si tu dis que Postgress rame au niveau des import, il faudrait peut-être un week-end.
D'ailleurs, au niveau hardware ça n'aurait pas de sens d'héberger une telle base sur un PC sous Redhat Linux avec disque IDE, je doutes que les perfs en IO soutiennent la comparaison avec une SUN, son bus à commutation de paquet et les disques SCSI qui vont avec.
En plus, tu n'a pas l'air de savoir que le SQL n'est pas vraiment portable (un peu comme pour les compilo C, va compiler le kernel sous Visual) : tout les SGDB ont des parties de la norme qu'ils n'implémentent pas ou mal et c'est rarement les mêmes.
3) Mais est-ce que c'est vraiment viable en pratique, pour des gens qui font des dumps souvent ?
Si le fichier est beaucoup plus gros (car il contient des requètes en + des données) et si la restauration est significativement plus longue, ça peut être prohibitif à l'usage
4) Enfin, je pense aussi que pour les petits projets, Postgres (ou MySQL) doit largement suffire. D'ailleurs, on trouve même pas mal de base sous Access dans les PME (hé oui il y a un moteur SQL).
Notes :
1) Optimisation spécifique Oracle : tout SGDB qui se respecte à un optimiseur intégré, donc l'ordre dans lequel tu écris les clauses ne devrait pas influencer les perfs.
Par contre, on peut utiliser des "binding variable" pour qu'il puisse cacher la version compilée (et réordonnée) de la requète.
2) Index : Si la table est petite, ça va plus vite en balayant la table.
Par requète "compliquée", j'entendait au niveau des conditions de jointure : si elle porte sur une seule colonne c'est facile de l'indexer, par contre si il y en a beaucoup, créer un index sur des colonnes multiples (et nombreuses de surcroit) peut ne pas servir à grand chose (enfin c'est ce que j'ai compris).
3) "Les blobs c'est sale" : c'est vrai mais quand tu en as besoin, tu peux pas faire autrement