Discussion :

[strat0]

Bonjour,

Je vous explique. Mon chef - qui a une bonne expérience du SQL mais qui n'est en aucun cas DBA administrator - m'a lancé sur un projet. Tout part d'une table qui contient les logs d'un serveur web (pas les logs W3C, quelque chose d'un peu plus évolué).

Mon chef souhaite que je créé une autre table (totalement indépendante du reste de la base) qui traite ces logs pour en tirer des statistiques, chaque ligne représentant un mois, et chaque colonne un "type de média" (CD, vidéo..., mais ça n'a pas grande importance).

Je lui ai proposé de faire plutôt une vue, puisque les données contenues dans cette table de statistiques sont redondantes, et que la table n'est reliée à rien. En effet, on m'a appris qu'une base de données ne devaient pas contenir de données "calculées", et théoriquement si la base est cohérente, il ne devrait pas y avoir ce genre de table indépendante.

Mais mon chef redoute la charge que créerait cette vue à chaque appel, alors qu'une table fixe ne nécessiterait que le calcul d'une nouvelle ligne chaque fin de mois. Moi je pensais que les vues étaient faites pour ça.

Alors qui a raison?

[qi130]

LEs 2 discours se tiennent

Quel sera la fréquence d'accès à cette table/vue ?

Quel est le SGBD utilisé ?

[strat0]

Quel sera la fréquence d'accès à cette table/vue ?

Très faible. C'est une table ou vue qu'on consulte une fois de temps en temps pour voir l'évolution de l'utilisation de notre site web. Justement je me demandes : est-ce qu'une vue est recalculée à chaque nouvelle ligne entrée dans la table de départ (c'est-à-dire très très souvent) ou juste quand on fait un SELECT dessus?

Quel est le SGBD utilisé ?

SQL Server 2000.

[Antoun]

Justement je me demandes : est-ce qu'une vue est recalculée à chaque nouvelle ligne entrée dans la table de départ (c'est-à-dire très très souvent) ou juste quand on fait un SELECT dessus?

Une vue ne contient pas de données. Elle est calculée à chaque fois qu'on fait un SELECT dessus, et seulement pour la partie interrogée.

[qi130]

Il me semble que les vues matérialisées d'Oracle n'obéissent pas à cette règle...

Mais bon, puisqu'Oracle n'est pas dans la course.... et vu le cahier des charges, une vue est à privilégier.

[Antoun]

Il me semble que les vues matérialisées d'Oracle n'obéissent pas à cette règle...

Yep. C'est pourquoi ce ne sont pas des vues, mais des tables avec diverses conditions de rafraîchissement.

[Philippe Robert]

Les vues matérialisées en Oracle existent aussi en SQL Server (à partir de la version 2000 je crois). Mais en MS SQL, on les nommes vues indexées.

[Antoun]

Tout à fait juste !

[strat0]

Est-ce que dans mon cas il y a un quelconque intérêt à faire une vue indexée, sachant que la plupart des lignes, celles des mois précédents, ne bougeront pas, et que seule celle du mois en cours évoluera parallèlement aux requêtes sur le serveur web?

En tout cas merci à tous, c'est diablement intéressant.

[SQLpro]

oui, les vues indexées permettent d'éviter tous les recalculs.

Attention cependant aux restrictions de construction des vues indexées :
1) déterminismes
2) calculs exacts
et un certains nombre d'autres choses.

Bref, il faut trouver le bon compromis.

A +

[strat0]

Bonjour,

je relance ce sujet parce que j'envisage éventuellement de mettre à exécution cette solution de vue indexée, mais je me demande de plus en plus s'il n'y a pas eu un malentendu sur ce que je cherche à faire.

Voilà ce que la vue devrait afficher :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
---------------------------------------------------------
| Période        | TypeMedia1 | TypeMedia2 | TypeMedia3 |
---------------------------------------------------------
| Janvier 2007   | 320        | 589        | 141        |
---------------------------------------------------------
| Février 2007   | 117        | 879        | 23         |
---------------------------------------------------------
| Mars 2007      | 228        | 322        | 454        |
---------------------------------------------------------
| Mois en cours  | 37         | 22         | 114        |
---------------------------------------------------------

Seule la ligne 'Mois en cours' serait effectivement calculée, les autres mois étant révolus, leurs données ne changeraient plus.

Or un index, qu'on le pose sur une vue ou sur une table, se pose sur une colonne, pas une ligne. C'est là que j'ai un peu de mal.

Sans compter que la requête de la vue serait sans doute à rallonge, puisqu'elle tire ses informations d'une table ressemblant à ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
-------------------------------------------
| id    | DateRecord          | NomMedia   |
-------------------------------------------
| 12345 | 03/03/2008 14:22:54 | TypeMedia1 |
-------------------------------------------
| 12346 | 03/03/2008 14:23:05 | TypeMedia3 |
-------------------------------------------
| 12347 | 03/03/2008 14:23:25 | TypeMedia1 |
-------------------------------------------
| 12348 | 03/03/2008 24:23:53 | TypeMedia2 |
-------------------------------------------

Ça suppose donc que je calcule comment se nomme le mois pour chaque mois que je vais effectivement isoler (en remontant jusqu'à novembre 2005).

(C'est le log de visionnage de "médias" sur un serveur web pour info)

Alors est-ce qu'avec ces nouvelles informations vous pensez toujours qu'une vue indexée soit une solution envisageable?

Merci d'avance pour vos lumières.

[serge0934]

pour ma part je ferais une table finale

---------------------------------------------------------
| Période | TypeMedia1 | TypeMedia2 | TypeMedia3 |
---------------------------------------------------------
| Janvier 2008 | 320 | 589 | 141 |
---------------------------------------------------------
| Février 2008 | 117 | 879 | 23 |
---------------------------------------------------------
| Mars 2008 | 228 | 322 | 454 |
---------------------------------------------------------
| Avril 2008 | 37 | 22 | 114 |
---------------------------------------------------------

avec un trigger sur la table générique

-------------------------------------------
| id | DateRecord | NomMedia |
-------------------------------------------
| 12345 | 03/03/2008 14:22:54 | TypeMedia1 |
-------------------------------------------
| 12346 | 03/03/2008 14:23:05 | TypeMedia3 |
-------------------------------------------
| 12347 | 03/03/2008 14:23:25 | TypeMedia1 |
-------------------------------------------
| 12348 | 03/03/2008 24:23:53 | TypeMedia2 |
-------------------------------------------

du type

create trigger ttt on table_generique for insert as
begin
declare @nommedia varchar(50)

if not exists (select 1 from table_finale where Période=convert(varchar,getdate(),102) ) -- le format n'est pas le bon a vérifier
insert into table_finale select convert(varchar,getdate(),102),0,0,0

select @nommedia = NomMedia from inserted

if @nommedia =TypeMedia1
update table_finale set TypeMedia1=TypeMedia1+1
where Période=convert(varchar,getdate(),102)

if @nommedia =TypeMedia2
update table_finale set TypeMedia2=TypeMedia2+1
where Période=convert(varchar,getdate(),102)


...

end

[strat0]

Sans vouloir t'offenser je crois que c'est la pire solution qu'on m'ait proposée. Il y a énormément d'enregistrements qui sont faits dans la table qui logue les médias visionnés. Utiliser un tel trigger serait donc probablement une très lourde charge pour la base.

[serge0934]

pour ton info
j'ai une appli industrielle de logistique où je récupère grace a des lecteurs codes barres le déplacement de colis sur un tapis de transitique.
250 lecteurs sur le chemin, une centaine de colis en permanence sur le tapis.
Au résultat, une centaine de lectures par seconde => vu les données de ta table tu en a au max 5/secondes.
J'enregistre le CB,l'heure,l'ID du lecteur dans une table comme toi.
J'ai un trigger qui vient remplir une autre table pour dire où est un colis a l'instant T( je résume).
Cela fait 4ans que cela tourne a 8 000 000 d'enregistrements/jours
Ca se saurait si ca ralentissait la base

[strat0]

OK, merci. Je note que c'est une autre solution envisageable.

Mais je voudrais vraiment savoir si une vue indexée serait possible dans mon cas.

[ylarvor]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
OK, merci. Je note que c'est une autre solution envisageable.
 
Mais je voudrais vraiment savoir si une vue indexée serait possible dans mon cas.

Je pense que tu devrais écouter serge.

On me contredira si je me trompe, mais la vue indexée, est une technique possible uniquement sur sql server 2000 enterprise ( ou developer ).

[strat0]

Ça tombe bien j'utilise SQL Server 2000 Entreprise.

Je ne suis pas certain de mettre en place au final la méthode des vues indexées, mais je souhaite vraiment savoir si elle est possible ou non dans ce cas précis. C'est pour un rapport de stage.

[SQLpro]

On me contredira si je me trompe, mais la vue indexée, est une technique possible uniquement sur sql server 2000 enterprise ( ou developer ).

NON ylarvor...

Les vues indexées sont disponibles dans toutes les versions sauf peut être MSDE/Express.

La seule différence c'est l'automatisation de la substitution de la requête à la vue qui n'est disponible que dans la version Entreprise.

Lisez l'article que j'ai écrit sur l'indexation. la méthode la plus pointue en matière de perf est la vue indexées.
http://www.sqlspot.com/INDEXATION-un...l-exemple.html

Alors est-ce qu'avec ces nouvelles informations vous pensez toujours qu'une vue indexée soit une solution envisageable?

OUI strat0...

En effet la vue indexée sera beaucoup plus performante que la solution à base de trigger.

Mais attention, vos données numériques doivent être de type DECIMAL et non FLOAT, sinon vous risquez des erreurs d'écarts d'arrondis. En effet plutôt que de recalculer tous les agrégats, la vue indexées procède par replâtrage... tant est si bien qu'en cas d'usage d'un réel imprécis, il se peut que le calcul dévie de la réalité. C'est aussi pourquoi les vues indexées sont beaucoup plus rapide que la solution avec trigger !

A +

[strat0]

Mais attention, vos données numériques doivent être de type DECIMAL et non FLOAT, sinon vous risquez des erreurs d'écarts d'arrondis.(...)

Les données calculées sont de type INT. Il n'y a pas de pourcentages calculés.

Merci pour ta réponse mais le point que j'aimerais vraiment que tu éclaircisses pour moi, c'est comment "fixer" des lignes d'une vue avec des index puisque par définition des index se posent sur des colonnes. Ou alors je pose justement l'index clusterisé sur toutes les colonnes?

Il y a là un concept qui m'échappe vraiment...

[ylarvor]

strat0 :
-il y a un exemple d'index cluster pour une vue dans le tutorial de sql pro.


sql pro : Pour ma défense, la doc microsoft semble préciser que les vues indexées sont une fonctionnalité de entreprise.

exemple :

Résumé : Ce document décrit une nouvelle fonctionnalité de SQL Server 2000 Enterprise Edition, les vues indexées. Outre une explication de ces vues, vous y trouverez des scénarios illustrant les améliorations qu'elles peuvent apporter aux performances.

document de référence : http://msdn2.microsoft.com/fr-fr/lib...edviews_topic1

Christian Robert, est d'accord avec vous, sur le fait que la vue indexée est possible sur toute les versions [ y compris express ] sous certaines conditions.

Apres lecture de cet article, je comprend mieux ce que vous vouliez dire... il semble quand même que sur une version non Enterprise, pour appeler une vue indexée, il faut ajouter à la requête la commande WITH(NOEXPAND).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
SELECT*FROM v1 WITH(NOEXPAND)

Yann.