>Par contre je ne comprend pas tout à fait ce que tu entends par réécriture automatique des requêtes. C'est propre à Oracle 10g cette utilisation transparente des vues matérialisées? Je ne l'ai jamais rencontré. (pas été plus loin que la v9)

Ca existe au moins en 9i, même si il y a des nouveautés je crois en 10g sur le sujet :
http://www.oracle.com/technology/oramag/oracle/03-sep/o53bus(...)

[ Répondre ]

C'est pas que j'aime pas Mysql ou PostgreSQL, mais ce que tu peux faire avec des triggers n'est pas exactement la même chose : une requête qui rame sous Oracle, si je peux lui demander de s'appuyer sur une vue matérialisée (il y a des choses qu'on ne peut pas faire...), je peux le faire de façon transparente pour le développeur ou l'utilisateur : le moteur réécrira dans son dos la requête pour utiliser la vue matérialisée plutôt que de lire la table. Cela évite de toucher au code de l'application.
Donc c'est faisable sous PostgreSQL ou Mysql avec des procédures stockées, et des triggers pour les mettre à jour, mais sans la réécriture automatique des requêtes, qui est bien extrèmement pratique. Peut être avec des rules PosgreSQL, mais ca peut vite devenir lourd à gérer.
Enfin, de toutes façons, là on parle de grosses bases décisionnelles, c'est pas encore la cible pour Pg ou Mysql à ma connaissance.

[ Répondre ]

Oui, je simplifiais ... par en permanence je voulais dire que le résultat est en permanence présent dans la base, pas recalculé à chaque demande. mais les données peuvent être décalées suivant la facon dont tu déclares la vue matérialisée...

[ Répondre ]

Je ne crois pas que développer un logiciel de façon professionnelle ait voir avec la peur.
Mettre des contraintes, c'est une question de robustesse. Si tu mets une contrainte au niveau de la base, tu es sur que personne ne peut la court-circuiter (sauf en la désactivant, bien sur). Cette contrainte ne change en rien le code qui est derrière, et peut t'économiser pas mal de soucis (comprendre : de travail, pas de peur...) en te protégeant de tes propres erreurs.

[ Répondre ]

Pour les perfs, il y a les vues dites matérialisées (sous Oracle au moins). Ca consiste à fabriquer une table qui contient en permanence exactement le contenu qu'aurait ta vue. C'est surtout utilisé pour les bases sur lesquelles on fait du data mining, afin de préparer les résultats des requêtes les plus complexes (regroupements sur des grands nombres d'enregistrements par exemple).
Ca n'existe pas pour le moment sous PostgreSQL ou Mysql. On peut le faire avec des triggers, mais c'est quand même pas mal de boulot...

Une vue normale n'accélère pas les perfs. Ca ne fait que simplifier le développement.

[ Répondre ]

> Les serveurs applicatifs sont pas non plus dans la DMZ? C'est mal(r).
Mpff ... pas dans la même. C'est CA la vraie paranoïa... :) Ca fait quand même un firewall à traverser.

>> Ca peut aussi permettre de vérifier des contraintes complexes à l'insertion des données (genre si ma colonne A vaut tant et ma colonne B est comprise entre telle et telle valeur, j'empeche telle action).

> C'est pas du traitement fonctionnel ça?

Je pense que c'est à la limite... Ca dépend des raisons de la contrainte.
C'est avant tout de la vérification de cohérence à l'insertion. Ca permet d'être sur que même si tu as un développeur qui veut corriger en urgence une donnée dans une table (qu'il aurait amenée avec un autre programme) et lance un ordre UPDATE à la main (oui, déja vu, malheureusement) ne te vérole pas totalement ta base si il a oublié un petit détail. En théorie, le développeur ne devrait pas avoir accès à la base de prod en direct, mais il y a des environnements ou tout est permis.

Evidemment, tout est dans le savant dosage, et dans la capacité à savoir s'arrêter dans les contraintes d'intégrité. De la à ne pas en mettre du tout parce qu'on est sur de son code ou parce que le PL c'est moche ...

[ Répondre ]

Tu n'es pas obligé de mettre du fonctionnel dans les procédures stockées. Tu peux te limiter à l'accès aux données...
Ca évite tout de même de faire de nombreuses requêtes successives au moteur pour récupérer quand les données à récupérer sont complexes. C'est très utile par exemple quand le réseau entre la BDD et le serveur d'appli peut avoir un impact sur les temps de réponse de requêtes simples (par exemple, serveur BDD dans une DMZ).
Ca peut aussi permettre de vérifier des contraintes complexes à l'insertion des données (genre si ma colonne A vaut tant et ma colonne B est comprise entre telle et telle valeur, j'empeche telle action).
Evidemment, écrire un traitement fonctionnel de plusieurs dizaines de milliers de lignes en PLSQL par exemple, c'est aimer se faire mal... et je présume que c'est plutôt à cela que tu pensais.

[ Répondre ]

Uniquement pour des vues "matérialisées".
Le reste du temps, une vue, c'est a peu près rien d'autre qu'une règle de réécriture de requête.

[ Répondre ]

En théorie, un raid 5 sur trois disque, c'est sensé être environ 2X plus rapide qu'un de ses disques en lecture (parallelisme), mais 2X plus lent qu'un de ses disques en écriture :
Pour écrire un bloc, il faut :
- lire l'ancien contenu du bloc et la parité (parallélisables)
- ecrire le nouveau bloc et la parité (parallélisables)
Ce qui fait 2 lectures et 2 ecritures pour une écriture logique...

Evidemment, ces valeurs dépendent après du controleur raid, de la qualité du driver, du paramétrage raid, etc ...

[ Répondre ]

Il me semble bien qu'avec les noyaux 2.4 'standards' l'extraction audio, par défaut, se fait sans DMA pour les cdroms IDE. Y a meme un patch pour ca ...
Peut être qu'il est dans les derniers 2.4, j'ai pas regardé.
En 2.6, l'extraction audio, ca prend 2 ou 3%.
Ce qui ne change rien au fait qu'un controleur SCSI consomme effectivement un peu moins qu'un controleur SCSI (mais c'est le moindre de ses avantages), ce qui est important sur un serveur.

[ Répondre ]

Probablement parce que la majeure partie d'entre eux sont des utilisateurs de debian convertis (ou de futurs utilisateurs de gentoo reconvertis ) :)

[ Répondre ]

A la poursuite d'Octobre Rouge?

[ Répondre ]

Y parait qu'il y a meme des malades qui testent tous les -mm ... moi en l'occurence ... :)
Je me demande si a partir d'un certain moment c'est pas une forme de dependance ...

[ Répondre ]

... racheté par Sco et devenu unixware depuis je crois bien

[ Répondre ]

En ce qui me concerne (via KT aussi, mais KT133), j'ai du mettre acpi=off ou pci=noacpi pour pouvoir booter ...

[ Répondre ]

Ils ont pas mis la nouvelle version 'révolutionnaire' du configurateur dont ils avaient parlé a un moment (celle qui permettait de faire du MUD...).
Mais l'outil de compil du 2.6 est tout de meme plus sympa. Les make xconfig sont plus joli (pas crucial, mais possibilité de les avoir en qt ou gtk), et surtout il n'y a plus besoin de make dep et make clean ...

[ Répondre ]

Pour info, pour ceux qui (comme moi) ont une souris USB, ca risque de coincer des le boot ... ce probleme est tout neuf dans le 2.6.0-test4 :)

http://bugzilla.kernel.org/show_bug.cgi?id=1123(...)

[ Répondre ]