"tu sais la boite a coulé depuis 6 mois... sans blague ? en utilisant oracle ?"
Vous autre linuxien vous avez de bon cotés mais dès fois vous êtes vraiment têtu (pire que moi :) )
C'est vrai c'est rigolo (au second degrès) le coup de la boite qui a coulé après avoir acheté une license Oracle ... mais enfin faut vraiment être de mauvaise foi pour sortir un argument aussi ridicule pour défendre Postgres. Une license Oracle c'est jamais qu'un grain de sable dans le budget d'une boite (sauf si elle est miniscule).
Enfin, pour info, j'ai un peu simplifié la vérité, l'exemple dont je te parle est donc un mélange de plusieurs boites ... et toutes les boites dans laquelles j'ai travaillé existent toujours.
"Tu parlais de 2 tables à ton boulot. 1,5 millions et 150000 milles lignes et d'une requete"
Mais enfin ,tu aurais dû te douter que si les tables était aussi grosses c'est que c'était une grosse appli (pour info : il y en a plusieurs centaines des tables).
"Il y a des statistiques sur les tables, c'est pas par hasard..."
C'est aussi ce que je pensais mais je suis pas DBA Oracle, alors tu m'as fait douter quand tu as dis que "l'ordre des clauses" jouait (d'ailleurs si j'en crois le post plus bas, l'optimiseur avait ses faiblesses pour les vielles version d'Oracle).
je n'ai jamais utilisé Postgres jusqu'à maintenant (mais je compte le faire un jour)
j'ai oublié de te précise que ça sera seulement pour logger mes visiteurs en PHP sur ma page perso, d'ailleurs je pense que pour le PHP MySQL est peut-être plus adapté. Mais je prendrais pas le risque de migrer un serveur Oracle sur SUN Enterprise vers Postgres même si j'en avais le pouvoir.
Du SQL92, ca s'importe n'importe où...
Tu parle beaucoup, mais tu as déja écris une grosse appli métier (pas un petit site web avec 3-4 tables) comprenant des centaines de tables, des millions de ligne de code sans te heurter à un seul problème de portabilité ? Sincérement, je pense que c'est plus ton ignorance qui est en cause ici que l'imcompétence des centaines de développeurs qui ont déja été confrontés au problème.
A propos des normes comme SQL 92
En tant que débutant SQL je ne connais pas bien le niveau de support de la norme mais pour le C, écrire du C standard, ça ne suffit pas car tout les compilateurs ont des bugs et sur des gros programme le portage de code standard vers un autre compilo demande habituellement plusieurs mois de travail, il n'y a que les progs de TP d'info de 20 lignes qui compile du premier coup : j'imagine que pour SQL c'est pareil.
YAKA coder SQL 92
C'est bien gentil de jouer les donneurs de leçons, mais prenons un exemple concret d'un gros projet de plusieurs millions lignes de code: le noyau Linux.
Outre le fait que le code utilise des extensions GCC (donc qu'il n'est absolumment pas conforme au standard C), il m'est arrivé de voir (en lisant kernel traffic) que la compilation de tel noyau n'était garantie que pour telle version de gcc. Comme disait Alan Cox : "le noyau fonctionne grâce aux bugs de GCC", c'était une formule pour faire comprendre que leur code n'avait été testé qu'avec un compilo et donc que si t'en change (par exemple que t'utilise un gcc 2.95 au lieu du 2.7 )tout pète.
C'est bizarre je n'ai jamais entendu personne ici traiter les développeurs de noyau de bande d'imcompétents qui ne savent pas ce qu'est que le standard C. Et les spécialiste du "yaka respecter les standards", on les entends jamais soutenir que l'idée du siècle ça serait de passer deux mois pour virer les extensions GCC, même si après :
- ça diminue de 10 % les perfs du noyau
- le noyau n'est pas plus portable qu'avant vu qu'il n'y a pas une chance sur 10000 que ça compile du premier coup sur un autre compilo que celui utilisé par Linus depuis des années pour tester son code
Tu sais, utiliser des types à la con, des blobs alors que pas necessaires, ne pas utiliser du SQL92, et bien... ca coule une boite..
D'abord la boite n'a pas coulé, ensuite comme expliqué plus haut si tu disais vrai le noyau linux aurait coulé depuis longtemps.
Prends les fonctions de manipulation de date (genre conversion date->entier long, différence entre date), c'est pas absolumment pas portable comme truc, mais si tu en as besoin tu fait comment ?
Et les decode(), ça améliore les perfs, ça rends le code plus lisible : les extensions du C de GCC pour le noyau ne font rien de plus et ça suffit pour qu'ils s'en servent.
blobs alors que pas necessaires
Tu ne connais pas le contexte donc je vois par ce permet d'affirmer qu'ils étaient inutile.
[^] # 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é à 1.
Vous autre linuxien vous avez de bon cotés mais dès fois vous êtes vraiment têtu (pire que moi :) )
C'est vrai c'est rigolo (au second degrès) le coup de la boite qui a coulé après avoir acheté une license Oracle ... mais enfin faut vraiment être de mauvaise foi pour sortir un argument aussi ridicule pour défendre Postgres. Une license Oracle c'est jamais qu'un grain de sable dans le budget d'une boite (sauf si elle est miniscule).
Enfin, pour info, j'ai un peu simplifié la vérité, l'exemple dont je te parle est donc un mélange de plusieurs boites ... et toutes les boites dans laquelles j'ai travaillé existent toujours.
"Tu parlais de 2 tables à ton boulot. 1,5 millions et 150000 milles lignes et d'une requete"
Mais enfin ,tu aurais dû te douter que si les tables était aussi grosses c'est que c'était une grosse appli (pour info : il y en a plusieurs centaines des tables).
"Il y a des statistiques sur les tables, c'est pas par hasard..."
C'est aussi ce que je pensais mais je suis pas DBA Oracle, alors tu m'as fait douter quand tu as dis que "l'ordre des clauses" jouait (d'ailleurs si j'en crois le post plus bas, l'optimiseur avait ses faiblesses pour les vielles version d'Oracle).
je n'ai jamais utilisé Postgres jusqu'à maintenant (mais je compte le faire un jour)
j'ai oublié de te précise que ça sera seulement pour logger mes visiteurs en PHP sur ma page perso, d'ailleurs je pense que pour le PHP MySQL est peut-être plus adapté. Mais je prendrais pas le risque de migrer un serveur Oracle sur SUN Enterprise vers Postgres même si j'en avais le pouvoir.
Du SQL92, ca s'importe n'importe où...
Tu parle beaucoup, mais tu as déja écris une grosse appli métier (pas un petit site web avec 3-4 tables) comprenant des centaines de tables, des millions de ligne de code sans te heurter à un seul problème de portabilité ? Sincérement, je pense que c'est plus ton ignorance qui est en cause ici que l'imcompétence des centaines de développeurs qui ont déja été confrontés au problème.
A propos des normes comme SQL 92
En tant que débutant SQL je ne connais pas bien le niveau de support de la norme mais pour le C, écrire du C standard, ça ne suffit pas car tout les compilateurs ont des bugs et sur des gros programme le portage de code standard vers un autre compilo demande habituellement plusieurs mois de travail, il n'y a que les progs de TP d'info de 20 lignes qui compile du premier coup : j'imagine que pour SQL c'est pareil.
YAKA coder SQL 92
C'est bien gentil de jouer les donneurs de leçons, mais prenons un exemple concret d'un gros projet de plusieurs millions lignes de code: le noyau Linux.
Outre le fait que le code utilise des extensions GCC (donc qu'il n'est absolumment pas conforme au standard C), il m'est arrivé de voir (en lisant kernel traffic) que la compilation de tel noyau n'était garantie que pour telle version de gcc. Comme disait Alan Cox : "le noyau fonctionne grâce aux bugs de GCC", c'était une formule pour faire comprendre que leur code n'avait été testé qu'avec un compilo et donc que si t'en change (par exemple que t'utilise un gcc 2.95 au lieu du 2.7 )tout pète.
C'est bizarre je n'ai jamais entendu personne ici traiter les développeurs de noyau de bande d'imcompétents qui ne savent pas ce qu'est que le standard C. Et les spécialiste du "yaka respecter les standards", on les entends jamais soutenir que l'idée du siècle ça serait de passer deux mois pour virer les extensions GCC, même si après :
- ça diminue de 10 % les perfs du noyau
- le noyau n'est pas plus portable qu'avant vu qu'il n'y a pas une chance sur 10000 que ça compile du premier coup sur un autre compilo que celui utilisé par Linus depuis des années pour tester son code
Tu sais, utiliser des types à la con, des blobs alors que pas necessaires, ne pas utiliser du SQL92, et bien... ca coule une boite..
D'abord la boite n'a pas coulé, ensuite comme expliqué plus haut si tu disais vrai le noyau linux aurait coulé depuis longtemps.
Prends les fonctions de manipulation de date (genre conversion date->entier long, différence entre date), c'est pas absolumment pas portable comme truc, mais si tu en as besoin tu fait comment ?
Et les decode(), ça améliore les perfs, ça rends le code plus lisible : les extensions du C de GCC pour le noyau ne font rien de plus et ça suffit pour qu'ils s'en servent.
blobs alors que pas necessaires
Tu ne connais pas le contexte donc je vois par ce permet d'affirmer qu'ils étaient inutile.