Demande leurs.
Tu sais la boite a coulé depuis 6 mois, donc c'est plus vraiment possible.
Mais si tu réfléchit un peu, il n'y a que deux solutions possibles : soit ils sont subitement devenus fous (la license Oracle c'est cher, et ils ont eu le temps de tester la BD avant de payer) ou ça marchait mieux qu'avant. Personellement, je pense que la deuxième solution est plus probable, libre à toi de te raccrocher à la première.
Et là encore, ce n'était pas un problème d'ignorance vis à vis du libre, tout les gens de la boite était des "pro-linux", sauf un gars qui préferait développer sous FreeBSD (pour te situer un peu le profil, il contribuait au système du fichier du noyau pendant son temps libre).
Je me souviens aussi, qu'une fois ils ont découvert (et corrigé eux-même) un petit bug du noyau en prod.
Oracle8i max 4gigas
Tu parle de la taille des blobs je suppose, mais est-ce que c'est vraiment utilisé en pratique par des "vrais utilisateurs dans le monde réel" des blobs de plus de 4 Go ?
Dans l'exemple en question c'était pour stocker des pages Webs donc la limite des 4 Go n'était pas un problème pratique.
Hardware .. Postgres compilable sur Unix proprio
bien sûr, je sais bien qu'on a les sources.
"ALTER TABLE DROP COLUMN" pas supporté ... tu me poses cette question en connaissant deja la reponse
tu t'énerve tout seul, là !
Non je ne connaissais par la réponse car je n'ai jamais utilisé Postgres jusqu'à maintenant (mais je compte le faire un jour).
Par contre j'ai été confronté au problème en pratique avec Oracle 8.0 (c'est ok avec 8.1), et quand tu dois recopier une liste de 59 colonnes pour supprimer la 60ème c'est pas pratique.
Et pour le renommage de colonne, ce n'est pas un "troll" comme tu dis - ce mot commence à se vider de son sens à force de l'employer à tort et à travers - c'est vraiment utile lorsque tu en as besoin.
Postgresql est DEJA utiliser pour de gros projets
Je vais te surprendre : Oracle aussi
1) Va donner tes lumières au dev d'oracle et de postgres.
Tu t'énerve tout seul !
Tout SGDB comprends un optimiseur qui doit ecrire un plan d'éxécution pour ta requète.
N'étant pas DBA, je ne connais pas son fonctionnement interne, mais il me paraissait vraissemblable que celui-ci prenne en compte la taille des tables pour ordonner les clauses WHERE.
Suis le conseil que tu lui donnes, et ne prend pas des grands airs si tu ne maitrises pas le sujet.
C'est toi qui t'excite tout seul ici.
tu n'as pas l'air de savoir que SQL n'est pas vraiment portable ... c'est à coup de grep que ca se règle.
Sérieusement, tu as déjà porté une grosse BD avec plus de 100 tables "à coup de grep" en 5 minutes ou bien tu es juste en train de faire travailler ton imagination ?
Et les requêtes qui font appel à des fonctions Oracle genre "decode()", et les triggers en PL/SQL à convertir en P/SQL, les problème lié au partie de la norme SQL non supportée par l'un ou l'autre, le portage du code C des OCI vers la libpostgres, les types de données des colonnes qui changent, tout ça pour toi ça se "règle à coup de grep" en un quart d'heure... je suis sceptique.
[^] # 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é à 0.
Tu sais la boite a coulé depuis 6 mois, donc c'est plus vraiment possible.
Mais si tu réfléchit un peu, il n'y a que deux solutions possibles : soit ils sont subitement devenus fous (la license Oracle c'est cher, et ils ont eu le temps de tester la BD avant de payer) ou ça marchait mieux qu'avant. Personellement, je pense que la deuxième solution est plus probable, libre à toi de te raccrocher à la première.
Et là encore, ce n'était pas un problème d'ignorance vis à vis du libre, tout les gens de la boite était des "pro-linux", sauf un gars qui préferait développer sous FreeBSD (pour te situer un peu le profil, il contribuait au système du fichier du noyau pendant son temps libre).
Je me souviens aussi, qu'une fois ils ont découvert (et corrigé eux-même) un petit bug du noyau en prod.
Oracle8i max 4gigas
Tu parle de la taille des blobs je suppose, mais est-ce que c'est vraiment utilisé en pratique par des "vrais utilisateurs dans le monde réel" des blobs de plus de 4 Go ?
Dans l'exemple en question c'était pour stocker des pages Webs donc la limite des 4 Go n'était pas un problème pratique.
Hardware .. Postgres compilable sur Unix proprio
bien sûr, je sais bien qu'on a les sources.
"ALTER TABLE DROP COLUMN" pas supporté ... tu me poses cette question en connaissant deja la reponse
tu t'énerve tout seul, là !
Non je ne connaissais par la réponse car je n'ai jamais utilisé Postgres jusqu'à maintenant (mais je compte le faire un jour).
Par contre j'ai été confronté au problème en pratique avec Oracle 8.0 (c'est ok avec 8.1), et quand tu dois recopier une liste de 59 colonnes pour supprimer la 60ème c'est pas pratique.
Et pour le renommage de colonne, ce n'est pas un "troll" comme tu dis - ce mot commence à se vider de son sens à force de l'employer à tort et à travers - c'est vraiment utile lorsque tu en as besoin.
Postgresql est DEJA utiliser pour de gros projets
Je vais te surprendre : Oracle aussi
1) Va donner tes lumières au dev d'oracle et de postgres.
Tu t'énerve tout seul !
Tout SGDB comprends un optimiseur qui doit ecrire un plan d'éxécution pour ta requète.
N'étant pas DBA, je ne connais pas son fonctionnement interne, mais il me paraissait vraissemblable que celui-ci prenne en compte la taille des tables pour ordonner les clauses WHERE.
Une rapide recherche sur le net (http://wwwsi.supelec.fr/~yb/poly_bd/node23.html(...)) semble d'ailleurs le confimer.
Suis le conseil que tu lui donnes, et ne prend pas des grands airs si tu ne maitrises pas le sujet.
C'est toi qui t'excite tout seul ici.
tu n'as pas l'air de savoir que SQL n'est pas vraiment portable ... c'est à coup de grep que ca se règle.
Sérieusement, tu as déjà porté une grosse BD avec plus de 100 tables "à coup de grep" en 5 minutes ou bien tu es juste en train de faire travailler ton imagination ?
Et les requêtes qui font appel à des fonctions Oracle genre "decode()", et les triggers en PL/SQL à convertir en P/SQL, les problème lié au partie de la norme SQL non supportée par l'un ou l'autre, le portage du code C des OCI vers la libpostgres, les types de données des colonnes qui changent, tout ça pour toi ça se "règle à coup de grep" en un quart d'heure... je suis sceptique.