Discussion :

[ctxnop]

Bonjour à tous,
Désolé pour le titre pas du tout clair, mais je ne vois vraiment pas comment exprimer ce que je recherche en 2/3 mots.

Je me doute bien de la réponse, mais j'aimerai confirmation.
Sous SQL Server 2008 R2, je fais un select [...] FROM [... avec tout plein de jointures]

Ca me donne un résultat du genre :

|colonne1 |colonne2 |.....|NomDeTable     |
+---------+---------+-----+---------------+
|bla bla  +bla bla  +.....+dbo.AutreTable1|
+---------+---------+-----+---------------+
|bla bla  +bla bla  +.....+dbo.AutreTable2|

J'aimerai inclure, dans la même requête, une colonne qui ramènerai le nombre de lignes présentes dans les tables données dans la colonne "NomDeTable", en gros :

|colonne1 |colonne2 |.....|NomDeTable     |NbLignes|
+---------+---------+-----+---------------+--------|
|bla bla  +bla bla  +.....+dbo.AutreTable1|12      |
+---------+---------+-----+---------------+--------|
|bla bla  +bla bla  +.....+dbo.AutreTable2|0       |

Je ne peux en aucun cas passer par un sp_execute ou je ne sais quelle autre fourberie, la requête dois être faite en une fois.
Si ce n'est pas possible, comme je le pense, j'obtiendrai ces valeurs par code.

Du coup je ne vois pas du tout comment je peux faire ca. Faut dire que je suis pas bien doué en SQL.

Il y peut être moyen en faisant des jointures sur les tables système non ? Enfin, je suis pas bien fan de cette solution (a supposé que ce soit possible)

EDIT: Ah oui, j'ai oublié de préciser un détail qui change peut être la donne. En fait je m'en fout complètement du nombre exacte d'enregistrements dans les tables, ce que je voudrais c'est savoir si il y a ou non des enregistrements, leurs nombre n'a pas d'intérêt.

[SQLpro]

En utilisant les tables système, vous pouvez obtenir une bonne approximation avec :

Code :

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

1
2
3
4
5
6
SELECT   SUM(p.rows) AS NOMBRE_LIGNE
FROM     sys.partitions p
         INNER JOIN sys.objects O
           ON p.object_ID = O.object_id
WHERE    p.index_id IN (0, 1)
  AND    p.object_id = OBJECT_ID('???')

Ou ??? est le nom de votre table (avec son préfixe de schéma).

A +

[ctxnop]

Merci bien de la réponse, je garde ca sous le coude, je testerai lundi.
Et sinon, quid de l'impacte sur les perfs de faire des jointures sur les tables system pour ca ?

Je veux dire, qu'est-ce qui serait le plus performant ? faire tout en une requête via des jointures sur les tables système, ou bien exécuter la requêtes "principale", puis exécuter un count(*) sur chaque table ?
Ca me semble bien lourd d'attaquer les tables système extrêmement volumineuses uniquement pour savoir si 3 ou 4 tables son vides ou non.

[elsuket]

Bonjour,

Je veux dire, qu'est-ce qui serait le plus performant ? faire tout en une requête via des jointures sur les tables système, ou bien exécuter la requêtes "principale", puis exécuter un count(*) sur chaque table ?
Ca me semble bien lourd d'attaquer les tables système extrêmement volumineuses uniquement pour savoir si 3 ou 4 tables son vides ou non.

Dans tous les cas faire des jointures ne pose aucun problème, pourvu que vos tables soient bien indexées.

A l'évidence rechercher le nombre de lignes d'une table dans les vues système est bien plus rapide est moins coûteux en termes de performances, que de compter toutes les lignes de chacune des tables de votre base de données.

J'avais publié comment trouver le nombre de lignes de toutes les tables ici

@++

[SQLpro]

Mais tu as oublié un SUM sur le nombre de lignes car s'il y a deux partitions tu va avoir 2 résultats !

A +

[ctxnop]

Voila qui est fort intéressant. Je pensais qu'inclure les tables système était fort couteux. Merci bien pour ces infos, Je teste ca dès que je suis de retour au boulot.

@SQLpro: La précision est d'importance, on a effectivement fait plusieurs partitions

[ctxnop]

Bien le bonjour !
J'ai testé et ca fonctionne très bien. Cependant, une modification des specs remet tout en cause ...
Avant j'avais besoin de savoir si la table avait ou non des lignes. Maintenant il faut savoir si elle a ou non des lignes qui correspondent à un critère.

Petit exemple pour mieux me faire comprendre

Le résultat de la requête :

colonne1|colonne2|...|colonneN|Condition|TableName     |Count
--------+--------+---+--------+---------+--------------+-----
bla bla |bla bla |...|bla bla | 12345   |dbo.AutreTable|2

Le contenu de la table dbo.AutreTable :

col1|col2|...|colN|Condition
----+----+---+----+---------
bla |bla |...|bla | 12345   
----+----+---+----+---------
bla |bla |...|bla | 12345   
----+----+---+----+---------
bla |bla |...|bla | 29      

La requête retourne donc 2 car il y a deux lignes dans la table dbo.AutreTable qui ont la même condition.

Cette nouvelle contrainte ne me semble pas possible via les tables systèmes. Une idée ?
Sinon tant pis, je ferai ca par code. En tout cas merci pour la solution d'avant, ca pourra me servir ailleurs

[elsuket]

Dans ce cas vous ne pouvez plus effectivement utiliser les tables système, et vous êtes obligé d'effectuer un COUNT(*) avec un WHERE.

Le mieux serait de stocker dans une table :
- le nom de la table
- le texte du filtre WHERE
- le nombre de lignes qui vérifient le WHERE la dernière fois que la table a été scannée
- un bit qui indique si la table a été traitée

Ensuite il suffit de faire une boucle WHILE en utilisant sp_executeSQL pour récupérer le résultat, et procéder à l'UPDATE de cette table.

Considérez néanmoins la taille des tables que vous traitez, car un COUNT(*) sur une colonne non indexée d'une table de plusieurs millions de lignes peut prendre du temps

@++

[ctxnop]

Bon bah j'ai traité ca par code. Je tag donc en résolut.
C'est un sacré manque du sql je trouve de ne pas pouvoir faire des "jointures dynamiques", parce qu'en l'occurrence j'aurais trouvé ca naturel de pouvoir faire un champs calculé par une sous-requête effectuant un count sur le champs clé primaire de la table liée.

Enfin bon, je vais pas refaire le monde des SGBD aujourd'hui, j'ai pas encore ma dose de caféine pour être assez motiver pour ca

Merci pour toutes les réponses

[mikedavem]

La requête dynamique est possible ici mais ne peut évidement pas être exécutée en une seule fois. N'hésitez pas à utiliser l'indicateur NOLOCK dans votre cas pour éviter des verrous excessifs qui pourraient porter préjudice à votre production (à moins que vous exécutiez cette requête en dehors de votre activité de production bien entendu)

++

[ctxnop]

Je ne peux décemment pas appeler ca une requête dynamique si je dois la faire en plusieurs fois sous prétexte qu'une partie de la requête est déterminée par une ou deux valeurs de cellule.
C'est pour ce genre de détail que je n'aime pas le sql, je me sens beaucoup trop enfermé/limité par le langage.

Je prend note du coup de l'indicateur NOLOCK, ca peut effectivement être très utile. Merci

[mikedavem]

Disons qu'il faut commencer par construire la requête avant de pouvoir l'utiliser avec un EXEC ou sp_executesql. Donc cela se fait en 2 fois

Par curiosité et intérêt pour la discussion pourriez vous quand même nous poster le code que vous utilisez pour récupérer ces informations ? Et pourquoi vous ne pouvez pas utiliser le SQL dynamique dans votre cas ?

++

[ctxnop]

Ca va être dur à poster ce code
Le fait est que l'on a dev tout un ORM qui effectue énormément de traitement de mise en cache en tout genre (selon les types d'objets on ne met pas tout en cache de la même manière, il y a de la sérialisation xml, sérialisation binaire, certains objets sont mis en caches pour toute l'appli, d'autre selon le user, etc...) tout mon code est basé dessus, il faudrait que je poste l'ORM avec pour qu'il ai le moindre sens.
Sans compter que je n'en ai tout simplement pas le droit.

Je peux y faire appel sans trop de perte de perf dans la mesure où tous les objets dont j'ai besoins ont déjà étés mis en cache pour une raison ou une autre.

Donc si je suis pour générer une requête, autant le faire par code compilé, c'est tout autant efficace.

Je rappel également que les tables que je consultes sont légères en nombre de lignes, ca dépassera pas le petit millier. Le but étant de remplir une TreeList, je souhaitait avoir une requête qui remonte toutes les infos d'un coup, mais au final je requête pour avoir seulement les infos de ce qui est visible dans la treelist (donc je requête a nouveau sur ouverture d'un noeud pour avoir les infos enfants).
C'est pas spécialement efficace, mais il s'agit d'une interface où les noeuds seront très rarement dépliés et où la rapidité n'est pas une nécessite (bon faut pas non plus que ca prenne 12 secondes pour afficher 3 noeuds ... mais on en est très loin).

[iberserk]

pour en revenir au table système,si vous connaissez vos critères à l'avance, créer une vue indexée filtrée.

Une fois indexée elle devrait se retrouver dans vos tables systèmes (pas testé...).

Je rappel également que les tables que je consultes sont légères en nombre de lignes, ca dépassera pas le petit millier. Le but étant de remplir une TreeList, je souhaitait avoir une requête qui remonte toutes les infos d'un coup, mais au final je requête pour avoir seulement les infos de ce qui est visible dans la treelist (donc je requête a nouveau sur ouverture d'un noeud pour avoir les infos enfants).
C'est pas spécialement efficace, mais il s'agit d'une interface où les noeuds seront très rarement dépliés et où la rapidité n'est pas une nécessite (bon faut pas non plus que ca prenne 12 secondes pour afficher 3 noeuds ... mais on en est très loin).

Pourquoi ne pas mettre cela en cache également?
Beaucoup de personne peuvent accéder à ce treelist? si oui c'est beaucoup de requêtes qui transite pour pas grand chose...

[ctxnop]

Aucun intérêt de mettre ca en cache car les valeurs changes souvent. En mettant en cache, il faudrait invalider le cache a chaque fois, refaire la requête et remettre en cache.

[iberserk]

les valeurs changes souvent

OK

[ctxnop]

Tien, ca me fait pensé que j'ai oublier de mettre le tag résolut, je fais ca de suite.
EDIT: ah ba non en fait, je l'avais déjà fait... on voit que je suis encore super réveillé ...