Discussion :

[lsylvain]

Bonjour à tous,

Je travaille depuis 3 mois sur Microsoft Visual Studio et j'aurais besoin de votre aide quant à certains choix qui auront un impact margeur sur mon programme.

Je dois réaliser un programme dont le but final est d'afficher une liste d'employés dans une listbox(c'est un exemple), si je clique sur un des employés je dois afficher dans une autre listbox les détails de ce même employé (email, photo,ect..), en gros ce que l'on appel une MASTER VIEW DETAILS.

Bien évidemment la réaction au clic doit être le plus rapide possible, je me place dans le cas où je récupère des données via une base de données SQL pouvant contenir énormément d'employé (900 000 pour me placer dans le pire des cas ).

Et donc j'aimerais que mon programme dans l'ensemble soit le plus performant possible.

Ma question portera sur la récupération des données.

D'après vous, je dois récupérer l'ensemble des informations concernant les employés (nom, prénom, email, service, ect...) d'un seul coup via une requête SQL, ensuite les insérer dans une list(c'est un exemple) et donc quand je voudrais récupérer les détails je ferais un trie sur cette même list?

OU

Récupérer simplement le nom et prénom de tous les employés via une requête SQL et ensuite renvoyer, quand j'en aurais besoin (donc au clic) une autre requête SQL récupérant les détails concernant l'employé ?

En gros plutôt je dois plutôt faire une requête SQL global et le trie dans le détail sur une list?

Ou alors une requête SQL plus lite et refaire après une requête SQL pour effectuer le trie sur la base de données ?

Excusez-moi pour le paver ci-dessus, mais je préfère clarifier au maximum mon besoin (en espèrants qu'il soit claire ).

Merci d'avance pour votre aide et en espérant que ce topic pourra aider d'autres personnes !

PS: Si vous avez des bouts de programmes en exemple cela me conviendrais également merci

[ctxnop]

Salut,

Personnellement, je ne suis pas expert DBA, j'ai même tendance à détester les bases de données à cause du langage SQL beaucoup trop limité et manquant cruellement de standard.

Par contre, généralement les machines hébergeant les bases de données ne sont pas des petites machine cliente. Les algos de tri, recherche, insertion, etc... sont le fruit de recherches scientifiques qui se chiffrent souvent en décennies.

Faire une requête globale pour tout ramener côté client c'est faire le boulot à la place du serveur de base de données. Tu penses faire mieux en 3 lignes de codes sur la machine cliente sous dimensionnée ?

[lsylvain]

Non effectivement pour le moment (un jour peut être) je ne pense pas pouvoir faire de tels prodiges.

Pour ma culture personnel quand tu dit :

Personnellement, je ne suis pas expert DBA, j'ai même tendance à détester les bases de données à cause du langage SQL beaucoup trop limité et manquant cruellement de standard.

Pourrai tu me citer des exemples d'outils plus puissants et plus standardisés ?

Je te remercie.

[ctxnop]

Il n'y en a pas, a ma connaissance. De mon point de vue le SQL c'est de la daube, mais on doit faire avec.

Ce que je reproche au SQL :
- Syntaxe difficile à "parser" (et donc manipuler) car trop "permissive" (tu peux mettres des quotes ou non sur les identifiers, le ; final est pas toujours obligatoire, la 'AS' des alias est optionnel, plusieurs syntaxes pour écrire une même jointure, etc...). Mais ca c'est pas bien grave.

- Le standard est trop léger. Globalement le standard impose SELECT, INSERT, UPDATE et DELETE. A peu près tout le reste c'est comme le sente les éditeurs. Résultat y'a pas un seul SGBDR qui a les mêmes fonctionnalités, les mêmes procédures stockées, les mêmes syntaxes d'appel. Ne serait-ce que le quote d'identifier, c'est différent chez tout le monde. Genre SqlServer utiliser [schema].[table] alors que mysql utilise `schema`.`table` (je ne suis pas sur que mysql gère les schémas mais bon, c'est pour l'exemple).
Pour couronner le tout les façon d'optimiser ne sont pas les mêmes (du notamment au fait qu'ils n'ont pas les mêmes fonctionnalités).

Tout ce bordel fait qu'il n'est pas réellement possible de faire un code qui puisse fonctionner avec n'importe quel SGBDR sans modification, alors que ça devrait être le cas car c'est l'un des plus gros avantages d'une archi 3-tiers.
Résultat, pour rendre possible le truc on est obliger d'écrire de grosses usines comme NHibernate ou Entity Framework, qui génère les requêtes à notre place. Ca marche plutot pas mal, mais si la norme SQL était réellement complète comme elle le devrait, on aurait pas besoin de tout ça (ou du moins dans une version beaucoup plus light). En plus ces frameworks sont obligé de faire avec le tronc communs a tous les SGBDR, c'est à dire pas grand chose. Résultat on a peu de maitrise sur la base de donnée en elle même et on ne peut pas vraiment faire des optimisations et on a des limites sur les possibilités. Du genre, ne t'attends pas a faire un cross apply avec nhibernate, ou un merge (toutes deux des commandes de SqlServer, je ne sais pas quels autres SGBRS les implémentent). Un pro NHibernate va peut être venir dire que c'est un mauvais exemple parce que bla bla bla, mais ça ne change pas le fond du problème.

On commence à voir apparaitre des bases de données d'un autre genre, par exemple les bases orientées document. On les regroupe sous l'appellation de base "nosql".
Je suis bien content de l'initiative, mais elles souffrent du même problème : aucune norme. Donc les éditeurs font ce qu'ils veulent et on ne peut pas échanger 2 bases nosql (qui utilisent le même concept j'entends)

Et au vu de l'inertie dans le milieu des bases de données, je doute qu'on puisse s'attendre à un changement avant quelques décennies.

Enfin voila, tout ça pour dire que c'est bien de la daube. Mais pour autant, y'a pas mieux à l'heure actuelle. C'est très puissant, performant, scalable, configurable, supporté. Il y a énormément d'outils, de framework, etc... qui tournent autour. Bref, pas mieux.

[DotNetMatt]

Personnellement, je ne suis pas expert DBA

On l'avait bien remarqué vu les inepties que tu sors. NoSQL et SGBDR ne répondent pas aux mêmes besoins, ils sont en général utilisés de manière complémentaire.

Comparer MySQL à SQL Server/Oracle, c'est n'importe quoi. MySQL, même s'il s'est largement amélioré ces dernières années, n'est pas taillé pour une utilisation professionnelle. Youtube a fait le choix de ce SGBDR, et aujourd'hui ils se retrouvent avec une archi totalement démente. Bref ce n'est pas là le débat.

La norme SQL est claire et si tu développes en la respectant, tu peux transposer ton code d'un SGBDR à l'autre. Là où ça ne fonctionne pas, c'est si tu utilises des fonctions spécifiques (par exemple FIRST_VALUE en PL/SQL n'existe pas en T-SQL). Mais bon ça, c'est un peu normal. Les délimiteurs de colonne ( [ en T-SQL, ` sous MySQL, etc.) ne sont pas obligatoires et ne font pas partie de la norme. Donc à partir du moment où tu dévies de cette norme SQL 2, ben forcément la portabilité n'est pas au rendez-vous !

Par contre, généralement les machines hébergeant les bases de données ne sont pas des petites machine cliente. Les algos de tri, recherche, insertion, etc... sont le fruit de recherches scientifiques qui se chiffrent souvent en décennies.

Tu peux faire tourner n'importe quel SGBDR sur une machine standard, pas besoin d'avoir un mastodonte.

Faire une requête globale pour tout ramener côté client c'est faire le boulot à la place du serveur de base de données. Tu penses faire mieux en 3 lignes de codes sur la machine cliente sous dimensionnée ?

D'après vous, je dois récupérer l'ensemble des informations concernant les employés (nom, prénom, email, service, ect...) d'un seul coup via une requête SQL, ensuite les insérer dans une list(c'est un exemple) et donc quand je voudrais récupérer les détails je ferais un trie sur cette même list?

OU

Récupérer simplement le nom et prénom de tous les employés via une requête SQL et ensuite renvoyer, quand j'en aurais besoin (donc au clic) une autre requête SQL récupérant les détails concernant l'employé ?

Bien évidemment tu dois choisir la seconde option ! Même si tu arrivais à rapatrier 900 000 employés de manière rapide, quel en serait l'intérêt du point de vue fonctionnel ? Aucun. Ton utilisateur va en regarder 25, peut-être 50... Rarement 100...

Donc il faut appliquer les principes de pagination : on récupère des petits morceaux et quand on a besoin de détail, on va le chercher de manière spécifique. Ca améliore les performances, et ça permet d'avoir une UI pas trop chargée pour le confort de l'utilisateur.

[ctxnop]

Voila pourquoi j'évite de m'exprimer sur le sujet... Il y a toujours quelqu'un qui vient dire que je raconte que de la merde en ne lisant que la moitié de ce que je dis, en étant un peu de mauvaise fois et en prenant tout au pied de la lettre, le tout en se montrant agressif et insultant gratuitement sous prétexte que je n'adhère pas a la vision de l'outil qu'il affectionne...

Déjà, je n'ai jamais dis que NOSQL et SGBDR répondaient exactement au même besoin, qu'on ne peut pas les utiliser de concert ou je ne sais quoi.
Cependant tu ne peux pas dire qu'ils ne se marchent pas un minimum sur les pieds. On peut tout à fait tout faire avec l'un ou avec l'autre, et donc on peut être amener à choisir parmi une liste contenant aussi bien du SQL que du NOSQL.

Ensuite, sans parler du fait que je n'ai fais qu'un exemple de différence de syntaxe entre deux choisi au pif mais que ca s'applique entre tous et donc que je ne comparais pas les perfs ou les fonctionnalités, dire que mysql/mariadb n'est pas un sgbdr ou qu'il n'est pas comparable a oracle est juste stupide. Désolé. Le fait est que mysql se traine une mauvaise réputation sur des manques de fonctionnalités, mais elles ont quasiment toutes été comblée depuis fort fort longtemps. Mais surtout, même sans parler de ça, c'est un sgbdr, tout comme sqlite. Ils ne se battent pas sur le même marché qu'oracle, c'est tout. Et donc quand tu crée un produit tu dois te demander quels seront tes besoins et choisir le sgbdr en conséquence. On choisira mysql quand les besoins sont faibles, oracle quand les besoins sont très fort.
Si tu ne peut pas faire ce que tu veux avec mysql, ça ne veut pas dire qu'il est nul ou qu'il n'est pas un sgbdr, ça veut juste dire que tu as mal choisit.

Après tu me reprend sur le fait que je dis qu'on ne peut pas réellement faire de sql portables à travers tous les sgbdr, en disant exactement la même chose que moi... Pas mal comme contre argument, je n'y avais pas songé.
Tu me dis que je peux faire du portable a condition d'utiliser uniquement ce qu'il y a dans la norme, a savoir pas grand chose (tu dis toi même que les délimiteurs de colonne n'en font pas partie), mais que si j'en sort ça marche plus. C'est donc exactement ce que j'ai dit.

Enfin, pour le coup du sgbd qui tourne sur n'importe quelle machine. J'ai dis le contraire ? J'ai juste dis qu'en général la base de donnée tourne sur un serveur dimensionné en conséquence de la BDD. Evidemment qu'on peut faire tourner une base de donnée sur n'importe quel machine, ça ne veut pas dire que c'est une bonne idée, qu'elle sera performante, ou je ne sais quoi. Je fais tourner sql serveur sur mon petit portable au boulot, bah il prend méchamment dans les dents question perf, malgré qu'il n'y ai que très peu de données.

PS: J'ai pas compris pourquoi tu quotes la partie où je lui dis de laisser le boulot au serveur plutot que de faire une requête globale puisque tu lui conseil exactement la même chose...

En tous les cas, j'ai vraiment pas envie de perdre mon temps dans une discussion stérile avec toi. Vu comment tu réagis ce serais une pure perte de temps, je te laisse à tes rêves érotiques avec la boite d'oracle, je vais aller me flageller pour avoir osé penser autrement...
Au passage je me désinscris de ce topic, les futures réponses ne m'intéressent pas, pure perte de temps. La question à été répondue de toute façon. Et soit assuré que, malgré le ton utilisé dans mon message, aucune rancune de ma part.

[Kikuts]

Je me demande comment certains peuvent encore créer des requêtes sans inclure directement la pagination

Toujours faire du chargement déporté : on charge une liste d'Id et libellé, et au clic : à la demande de l'utilisateur, on charge l'élément complet qu'il a demandé !

Sinon, c'est pas très écologique car tu vas consommer beaucoup de CPU pour rien car si tu as 1000 x la requête de récupération de tes 900k lignes, ton serveur, tu pourras t'en servir comme bouillotte dans ton lit l'hiver

Plaisanteries mises de côtés, je te conseil de systématiquement limiter le nombre de résultat de tes requêtes et également de toujours les trier (ça t'évitera bien des blagues futures).

Tu peux aussi prendre en compte que si ton cahier des charges ne te demande pas d'offrir la possibilité à l'utilisateur de pouvoir choisir l'ordre du tri, sur quelle colonne trier, ton CDC évoluera surement par la suite (ex : 60% des utilisateurs ont donné un feedback sur le manque de tri).

C'est nécessaire et indispensable de trier côté serveur. Je m'explique avec un exemple : soit liste de user par ex :
nom ; nombre connexions
a ; 5
t ; 9
e ; 15
z ; 7
g ; 7
w ; 10

Ta requête fait de la pagination sur 3 éléments par page (pour l'exemple).
Tu récupères les 3 premier : a t e. Si l'utilisateur fait un tri côté client sans recharger la liste : il aura a-e-t et non pas a-e-g. C'est pour cela que tes requêtes doivent être triées en fonction des choix/paramètres utilisateur et retourner x éléments (à partir de y où y = numPageEnCours * nbElemParPages)


Espérant t'avoir aidé, Nicolas

[lsylvain]

Franchement merci pour vos réponses détaillées et vos petits conseils en plus !

[Kikuts]

N'oubli pas de mettre résolu ! merci et bon weekend à toi !