Reprise du message précédent :

Postgres a longtemps été merdique à installer sur Windows

Pour la complexité des requêtes je parlais pas de moi en particulier hein    
C'est connu que les applis web ont en général des requêtes peu complexes (enfin après faut définir ce qu'on entends par complexe ).
 
On parlait des transactions pas des tables qui pètent toutes seules hein    C'est pas parce que c'est en MyISAM que ça pète tout seul non plus. Et si ta table des produits pète, normalement t'as un backup que tu peux remonter dans l'heure ou alors tu sais pas gérer ton site
 

Comment on peut insérer dans une vue ?   (je parle pas de la syntaxe SQL hein )

 
L'unique condition sous Oracle c'est que ta vue conserve la clef primaire de la (les) table(s) dans laquelle tu veux insérer les données, c'est un peu particulier comme concept, puisque ça demande de connaitre la structure sous-jacente de la base pour pouvoir en  utiliser une abstraction !
 
En norme SQL2, je crois que ce n'est pas possible sur une vue composée de plus d'une table.

Il est vrai

Pour MySQL
1. Parce qu'il y a encore pas si longtemps, c'était pas performant. Là où mysql est parti du principe que la performance était le premier but et que la cohérence ou la sécurité n'avait aucun intérêt (et tente maintenant d'inverser la vapeur), postgres est parti du raisonnement inverse (d'abord un truc correct, complet et qui fonctionne, et ensuite un truc qui va tellement vite que le souffle t'arrache ton calbute) et le "push" pour les performances n'a commencé que sur Postgres 7 et (surtout) Postgres 8 (8.4 configuré un minimum est maintenant notablement plus performant que mysql + innodb, et scale beaucoup mieux avec le nombre de cores)

2. Parce que les hébergeurs de mutualisés ou gratuit fournissent tous sans exception du mysql, que tous les tutos php et autres se basent sur mysql, ... donc les gens sont d'abord exposés à mysql et ont tendance à ne pas aller chercher ailleurs. Sans compter qu'il faut taper du dédié pour avoir une chance d'utiliser du postgres

Pour Oracle:
Parce que c'est "le standard", parce que les gens ont de la formation et de l'expérience dessus, parce qu'il y a des zillions de bouquins sur le sujet, parce qu'il est trivial de trouver du consulting ou du dba oracle.

Donc un mix de simplicité, de "ça a marché pour mon prédécesseur donc ça marchera pour moi" et de sécurité de l'emploi ("si le projet a échoué ça peut pas être à cause de mes choix: j'ai sélectionné les standards de l'industrie que tout le monde utilise" )

Chaque touche a un mini-écran, mobile.  
 

tu peux insérer sur des colonnes qui sont pas trop compliquées, évidement, tu peux pas insérer n'importe quoi n'importe où, mais pour un bon paquets de cas, c'est pratique, ça te permet de couper entre ce qui est visible par l'appli, ce que tu gères en stockage, et ce que tu laisses le SGBD gérer en stockage.
 
Typiquement, dans un forum, tu vas mettre le nombre de message de l'utilisateur dans une colonne de la vue user_detail, mais tu l'insèreras jamais toi-même, elle est définie comme le count(...), par contre, tu vas pouvoir updater la vue pour changer la signature.

 
Je me coucherai moins con  

 
prenons l'exemple d'hier soir : une table topic (qui contient le titre, et l'id du premier message), une table message (qui reference l'id du topic, et contient l'utilisateur, la date, et le contenu).
 
la procédure de création de topic :
 
begin transaction;
1. créer topic avec message_id = null => l'id topic est généré a l'insertion
2. créer message avec topic_id = le topic créé avant => l'id message est généré a l'insertion
3. mettre a jour le topic en mettant le message_id correct
commit;
 
ici, mysql petait une erreur au 2, a cause de contenu trop grand (alors que l'erreur etait due a l'unicode...)
si les transactions ne marchent pas, on se retrouve avec un topic sans message => boom.

non, justement, il est pas mobile de ce que je lis, il est fixe et la touche est transparente.

 
Mobile de bas en haut, quand on appuie dessus
 

sans doute pour les mêmes raisons que, OpenOffice étant gratuit et performant, tout le monde utilise Word.
 

il l'est toujours ; et surtout, il manque d'une interface de configuration claire et compréhensible sans se taper 5 pavés de doc.

 
Le jour ou OOo arrivera à gérer les styles, je le considérerai performant. En attendant je trouve qu'il s'agit juste d'un (mauvais) paliatif à Microsoft Office. [/troll]

Vous me faites rire avec vos bases de données de mickey.  
 
Moi j'utilise 1 serveur Sybase IQ  et 2 serveurs Sybase ASE. Et comme ça allait pas assez vite, j'ai planqué une lib entre mes applis et l'api Sybase, qui fout tout en cache dans memcached: j'ai fait l'équivalent du query-cache de MySql: chaque requête SQL est hashée, et son résultat est stocké dans memcached, et dans un mini-cache local. Comme on intercepte tous les appels à l'API (via LD_PRELOAD), si on retrouve la même requête, on simule la BDD et tout.  
 
Bah même avec tout ça, ça va pas assez vite. J'crois qu'il va falloir viser les E25K.

Non.

Cela dit, sur la vue de profil on voit que la course n'est pas phénoménale, donc que la capot n'est jamais très loin de l'écran...

Spèce de furieux

la bonne méthode c'est pas de changer la conf ou la base complète plutôt que de bidouiller ?

Il y a quelque milliards de requêtes à jouer chaque nuit (le plupart étant torchée entre 500 et 1500 µs), et on a extrèmement peu de latitude sur les usages des bases et sur le hardware dispo...

vous tapez beaucoup plus en lecture qu'en écriture ?

 
En fait c'est pas pleins de petits écrans, c'est juste un seul gros machin

On réplique les bases le soir (en fait, on les réplique plusieurs fois), et les traitements de la nuit ne se font donc qu'en lecture ou presque.  
 
Bah figure-toi qu'il n'y a que mySql qui a prévu le cas où une table ou une bdd ne serait accédée qu'en lecture seule, et que donc ça valait le coup de mettre le résultat de la requête en cache côté serveur ou même côté API.
 
Le truc, c'est que 1ms, c'est pas beaucoup comme temps de requête. Mais quand tu as une horde de machines qui le font en même temps (exemple typique: les caisses d'un supermarché), bah ça finit vite par chiffrer.
 

et au niveau applicatif, y'avait pas moyen de faire mieux pour pas répéter les lectures et saturer le réseau ? à coup de multicasts et autres push ?

C'est des millions et des millions de lignes de code, délicieusement organisées sous forme de strates. Et si une classe à un endroit à décidé qu'il lui fallait la donnée X, elle ira la chercher et puis c'est tout. Donc les 4 seules options sont:
- modifier la classe en question (pas possible rapidement)
- modifier le code appellant, pour faire moins appel à la classe en question (pas possible rapidement)
- modifier l'api BDD utilisée (pas possible rapidement)
- faire croire à tout ce beau monde qu'il discute réellement avec une BDD alors qu'en fait c'est memcached qui fournit les résultats (3 jours de dév intensifs pendant les fêtes).
 
En fait, j'avais déjà utilisé ce type de bidouille pour faire marcher nos APIs BDD avec Sybase IQ (intercepter certaines options de connexion, etc.).

certes, y'avait pas d'autre solution rapide, mais en contournant le pb, je suis pas sûr qu'à long terme tu gagnes.

Je m'en fous du long terme. Moi je veux que le chèque du client il tombe, si je veux pouvoir me payer une robinetterie de qualité (ça coûte cher une bonne robinetterie)...
 
Une fois qu'on aura passé le feu, on pourra voir comment déployer des milliers d'hommes-jours pour résoudre cet épineux problème.

je vois pas pourquoi tu déploierais des milliers d'homme-jour vu que ça marche ...

Ah mais je te fais confiance hein  

Pour se faire des sous en le faisant marcher sur le long terme?

Parce qu'une roue de secours ne dure jamais beaucoup de kilomètres, et parce que si on corrigeait le comportement simpliste de certaines portions historiques de l'appli, on gagnerait encore plus en perf (et donc on pourrait vendre à des clients encore plus gros).

 
Faut bien vivre, un jour tu es payé pour programmer en environnement hostile, le lendemain tu es payé pour abattre le monstre que tu as contribué à créer

"nos problèmes d'aujourd'hui sont les solutions d'hier"
 
nan, mais j'avais envie de challenger Lam's un peu ...

bon, struts2 ça me saoule, c'est définitif.
 
Je passe ma vie à me cogner à ces putain de ThreadLocal et j'en ai marre, c'est pas comme ça qu'on bosse chez les Raynaud
 
Le ThreadLocal ça vaut autant qu'une variable globale en C

jsf

tiens ça fera plaisir à programming.reddit.com

http://www.maxivista.com/  

Possède les fonctions de Synergy (un clavier souris et pleins de PC)
mais a aussi une fonction en plus, le PC supplémentaire peut aussi servir de nouvel écran pour le PC principal
Bon c'est pas gratos, mais on s'en fout un peu quoi

http://smackinthecrack.com/post/20 [...] e-Guy.aspx

 
Ouaip, c'est ce qu'on a fait aussi, passer en E25K (j'parle pas de tes interceptions bidules là )
 
Par contre, j'ai appris hier que dans la version 15 de Sybase (y a pas de versions 13 et 14 on passe de la 12.5 à la 15 ), tous les moteurs d'optimisation ont été réécrits. Donc va falloir tester tout ça intensément lors de notre migration, mais ça promet d'être intéressant.

JMeter c'est marrant

Ptetre que c'est ça qu'il faut à nraynaud: passer à une E25K ?
 
(sinon, je note que l'optimisation pour Sybase c'est très coton. Entre l'ordre des champs et des tables qui influe, la syntaxe qui permet de taper plus ou moins sur les indexes, et les 17 types d'indexes justement de Sybase IQ, sans parler du partionnement, des filesystems et du striping...)

"from $1 023 047,00 (US)"  
tiens, c'est marrant, ils se sont trompé dans le placement de la virgule

Your server doen't answer to our ICMP Ping request
 

Yo. Dormir dans le même lit avec son ex, c'est pas une bonne idée

Ca a fini en sexe ?