Discussion :

[zooffy]

Bonjour à tous.

Je suis confronté à une sorte de dilemme, disons que je suis un peu rouillé et que je refais ma programmation une quatrième fois parce que je ne suis pas satisfait. Alors je viens prendre audience auprès de la communauté.

Voici l’énoncé du problème : je fais des articles sur la rotation hebdomadaire de Heroes of the Storm (pour ceux qui connaissent, pour les autres c'est un jeu vidéo de chez Blizzard), donc chaque semaine il y a 14 personnages qui sont mis en avant. J'enregistre dans une table de la BDD l’information de la semaine concernée avec la date du Mardi (puisque c'est le jour de la mise en place de la chose) et dans une autre table je mets l'identifiant des 14 personnages avec l'identifiant de la rotation et le positionnement dans la liste de la rotation (qui a son importance).
Ensuite je fais une extraction des données pour présenter la rotation sous forme de tableau avec l'image du personnage et des données statistiques sur le personnage concerné : nombre de sorties dans la rotation, date de la dernière sortie, patch modifiant le personnage, .. Bref, pas mal de chose. Les infos des personnages sont dans une autre table et j'ai aussi une table pour les patchs.

Voici maintenant ma question : quelle est la meilleure façon de faire :
- je fais une grosse requête qui prend toutes les informations et retourner une table à 14 lignes, puis je programme en VB.NET la mise en forme de mon tableau sur ma page.
- je fais une requête basique avec la liste des 14 personnage et pour chaque personnage je fabrique une classe qui va retourner dans la BDD pour prendre les infos sur chacun des personnages.

Je me pose cette question tout à la fois pour des raisons de performance mais aussi de maintenance et d'évolution.
Par exemple, au début du jeu la rotation était de 7 personnages, puis elle est passé à 10 et là, depuis deux semaines elle est passée à 14. Egalement, je sors de temps en temps de nouvelles statistiques, par exemple, au début je ne donnais que le nombre de sorties dans la rotation avec le nom et le rôle du personnage, puis j'ai rajouté la date de dernière sortie et ensuite la date du dernier patch concernant le personnage. Bref, je peux rajouter des infos à tout moment, en fonction de l'évolution du jeu.

Voilà, j'espère avoir été clair dans mon exposé. Je ne viens pas forcément chercher une réponse technique mais plutôt une réponse algorithmique, si ce terme convient. Je me pose des questions sur l'opportunité de faire un maximum d'objet, mais où et comment.

Pour avoir une meilleure vision de la chose vous pouvez aller là : http://statheroes.ozouf.com/
Vous trouverez facilement le bouton Rotations dans le menu, pour le reste les explications sont normalement claires. Sachant que la date de dernière rotation enregistrée est le Mardi 14 Mars 2017, les autres ne fonctionnent plus depuis que j'ai fait des modifs pour passer à 14. Mais vous verrez le genre d’information que je traite.
Et vous pouvez voir l'un des résultats de ce site en allant sur mon blog : http://esport.ozouf.com/

Si ça vous branche de participer au projets, la porte est ouverte.
Merci d'avance pour vos avis et éclaircissements.

Une très bonne journée à vous.

[Dokho1000]

Tu as plusieurs possibilités. Si tu veux manipuler des objets ce qui est préferable ce serait d'utiliser entity framework (pas la peine de réinventer la route)
Tu pourrais aussi faire plutot une store proc coté SQL afin de récuper toutes les données souhaitées et ta page n'aurais plus qu'a les traiter...

Point de vue performance il vaut mieux faire un query qui ramène tes 14 records que faire 15 fois un query...

[zooffy]

Merci pour ton aide.

Finalement, c'est toujours mieux de faire une seule Query, donc comme il y a 20 ans !
En fait, parce qu'il y a un point que je n'ai volontairement pas développé, je me posais cette question parce que je suis repassé en mode recherche de boulot active et j'ai vu plein de nouveautés (huit ans "d'absence") et je me disais que peut-être les choses avaient changé et donc qu'il serait plus performant de passer à une autre méthode.

Maintenant Entity Framework, j'ai mis le nez dedans il y a deux semaines et j'ai vu que ça pouvait être assez performant. toutefois, j'ai pas encore bien compris le principe de l'interface avec la BDD et je me demande si je fais des objets sur chacun des personnages est ce que cela ne va pas faire pas mal d'aller retour avec la BDD, donc 15 Query, voir plus.

Encore merci pour ton aide.

[Pol63]

en même temps se poser la question des performances pour 14 lignes ...
y a des gens qu'ont des bases de données avec des centaines de Go, et on peut récupérer et afficher des milliers de lignes dans un tableau en moins d'une seconde (en web je suis moins sûr certes)

entity framework va se connecter sur ta base de données depuis VS, et générer du code en fonction de la structure de celle ci (une classe par table, des propriétés qui pointent vers les sous tables ... très pratique donc)
après ca s'utilise comme du linq, en fonction de ce que tu demandes ca génère la requete de select qui va avec, et ca remplit les instances
y a une méthode SaveChanges qui s'occupe d'écrire les requetes insert/update/delete en fonction de ce que tu fais
potentiellement ca peut etre moins performant qu'écrire les requetes soit même, mais c'est pas courant, et là encore sur tes 15 lignes osef
et si tu l'utilises mal ca va faire plein de requetes au lieu d'une aussi

[zooffy]

Merci our ton aide.

Je te l'accorde, pour 14 lignes, c'est peut-être du pinaillage. Mais je me dis que si mon site a de la notoriété, ça va faire 14 lignes multiplié par le nombre de visiteurs et là, d'un coup ça pourrait prendre des proportions plus importantes.
Merci pour l'exposé sur Entity framework, je me rend compte qu'il faut vraiment que j’approfondisse la chose. Dans le cas précis qui m'occupe je ne sais pas trop par quel bout prendre la chose.
Par exemple, dans les données que je remonte pour chaque perso, je vais chercher le dernier patch qui a modifié le personnage. Dans mon codage actuel j'ai fait une Fonction Table dans SQL server pour aller chercher cette info et ça me remonte le numéro du Patch et sa date. Du coup, je colle cette fonction dans mon Select de ma Proc Stock. Traduire ça dans Identity Framework me parait super compliqué mais vu que je maîtrise pas là chose, c'est peut-être tout bête au bout du compte.

Ah, j'oubliais : mon système actuel repose sur l'utilisation des Contrôle Utilisateur (ASCX) et j'ai pas réussi à mettre de l'Entity Framework dedans.
Ou alors je reste classique et je fais un objet par personnage qui va se fabriquer avec plein de paramètres que j'envoi avec ma grosse Proc Stock, un peu comme le disait Dokho si j'ai bien compris ce qu'il me dis dans son post.

Merci pour tout et bon Dimanche.

[Dokho1000]

Merci our ton aide.

Je te l'accorde, pour 14 lignes, c'est peut-être du pinaillage. Mais je me dis que si mon site a de la notoriété, ça va faire 14 lignes multiplié par le nombre de visiteurs et là, d'un coup ça pourrait prendre des proportions plus importantes.
Merci pour l'exposé sur Entity framework, je me rend compte qu'il faut vraiment que j’approfondisse la chose. Dans le cas précis qui m'occupe je ne sais pas trop par quel bout prendre la chose.
Par exemple, dans les données que je remonte pour chaque perso, je vais chercher le dernier patch qui a modifié le personnage. Dans mon codage actuel j'ai fait une Fonction Table dans SQL server pour aller chercher cette info et ça me remonte le numéro du Patch et sa date. Du coup, je colle cette fonction dans mon Select de ma Proc Stock. Traduire ça dans Identity Framework me parait super compliqué mais vu que je maîtrise pas là chose, c'est peut-être tout bête au bout du compte.

Ah, j'oubliais : mon système actuel repose sur l'utilisation des Contrôle Utilisateur (ASCX) et j'ai pas réussi à mettre de l'Entity Framework dedans.
Ou alors je reste classique et je fais un objet par personnage qui va se fabriquer avec plein de paramètres que j'envoi avec ma grosse Proc Stock, un peu comme le disait Dokho si j'ai bien compris ce qu'il me dis dans son post.

Merci pour tout et bon Dimanche.

tu peux tout a fait importer facilement ta store proc dans l'entity framework.
Le problème n'est pas lié au 14 ligne évidement dit comme ca on pourrait se dire qu'il n'y aura jamais de problème de performances. Le but est de savoir sur combien de table tu fais de jointure et combien de colonne sont récupérées ainsi que la clause where et les fonctions scalaire utillisé par ton query. Tout ca combiné pourrait meme pour 14 records généré un problème de performance. Il y aussi la problématique de ta page web qui si le site est très utilisé pourrait se voir executer des milliers de fois alors même si ca ne prend qu' une demi seconde. mille fois 1/2 seconde c'est presque 10minutes de charge sur ton serveur.

Pour répondre à POL63, les BDD de 100Go qui te remontes des query en quelque ms coutent des centaine de milliers d'euro, je doute qu'il ai le budget...

[zooffy]

Merci Dokho.

Tu as mis le doigt sur mon questionnement. Ma proc stock interroge pas mal de table en fait. Je vais tenter de présenter la chose :
- une rotation est répartie en deux tables : la rotation par elle même avec un champ date et un champ texte et une table qui contient l'ID de la rotation, l'ID du personnage, un champ pour indiquer sa position dans la rotation. Cette deuxième table va donc contenir 14 lignes pour chaque rotation (7 pour les premières rotations et 10 pour celle qui ont suivi la modification)
- les informations remontées pour chaque personnage :
- les infos du personnage contenues dans un table "personnage" : nom, rôle, univers sachant que pour le multilingue j'ai géré le nom du personnage dans une table de dépendance avec le nom dans la langue et la langue dans un autre champ.
- le nombre de sortie du personnage : je réinterroge la table de dépendance (je crois que c'est le bon terme) de la rotation et je compte le nombre d'ID du personnage qu'il y a dedans.
- la dernière sortie du personnage : je cherche dans la table de rotation la dernière date où on a vu le personnage sortir.
- le dernier patch modifiant le personnage : même système, une table pour les patchs avec le numéro et la date de sortie du patch et une table de dépendance avec l'ID du patch et l'ID du personnage concerné.

Voilà, je crois être complet. Cela doit faire 5 jointures si je compte bien.

En plus de tout cela, je dois tenir compte que l'on peut appeler une rotation plus ancienne, donc ma proc stock prend en compte tous les calculs à partir d'une date donnée. Illustration : si on va chercher une rotation en 2016, il faut compter le nombre de sortie jusqu’à la date de la rotation concernée, d'où l'utilisation de Fonction Scalaire ou Table pour le patch, le nombre de sortie et la date de dernière sortie.

Et du coup, avec Entity Framework, je ne sais pas trop comment faire une table de dépendance ou une jointure entre deux tables. Je débute avec cette chose là. Je sais que c'est important et qu'il faudrait que je le maîtrise, mais c'est un peu touffu à ingurgiter, d'autant que mon vieux cerveau n'est pas aussi alerte que celui d'une jeune étudiant qui débarque dans le domaine !!!

Et pour donner un peu plus d'information : je suis à la recherche d'un job, donc il faut que je me remette à la page sur les nouveautés (j'ai arrêté le dev Web pendant 8 ans) et donc je profite de ce projet perso qui me tient à cœur pour apprendre les nouvelles technologies. Donc Entity Framework et MVC, c'est comme si je faisais du HTML 4 en 1996 !

Merci pour votre aide et une bonne journée à vous.

[Dokho1000]

Que ce soit EF (Entity Framework) ou autre chose, toute opération qui peut être directement réalisée dans la BDD doit se faire à ce niveau là. Tu dois donc garder ta store proc et c'est donc ta store proc qui doit être performante.
Dans EF tu pourras l'importer sans problème et elle générera un objet que tu pourras manipuler.

Je te conseil de suivre des tutoriaux.

Le revers de la medaille, comme le disait POL63, c'est que le query linq (EF) pourrait générer une requête moins performante. (Pour ma part, je fais des Store Proc lorsqu'une requête n'est pas performante)

[zooffy]

Tu aurais quelques liens vers des tutos que tu trouves bons ?
Je rame un peu pour trouver des choses pertinentes, soit c'est ultra basique, soit je capte même pas les premières lignes.

Merci.

[Dokho1000]

Non désolé, il te faudra chercher.

[micka132]

14 lignes c'est vraiment rien, et il vaut donc largement faire qu'une seule requette, d'autant plus si ton nombre d'utilisateur va augmenter, il vaut toujours mieux 1 requette que plusieurs.
Maintenant je ne partirai pas sur EF dans ton cas parceque tu ne vas pas utiliser 20% des fonctionnalités (lazyloading, tracking...), d'autant que si ce sont des questions de performances pur qui t'interresse EF ne fera qu'alourdir (bien que franchement négligeable pour ton cas).
Ado.net classique étant un peu "chiant" tu peux te diriger vers des micro orm du style dapper : http://tlevesque.developpez.com/tuto...s-avec-dapper/ , mais le coté chiant d'ado.net c'est quand tu as une appli métier avec des dizaines voire centaines de tables...pour ton projet ce n'est pas le cas et de ce que je comprends tu as déjà fait le "sale boulot".
Donc à moins d'avoir une envie d'apprendre, ca ne t'apporteras absolument rien de partir sur autre chose qu'Ado.Net.

[zooffy]

Merci pour vos réponses.

Je jette un œil à Drapper et je trouve que c'est pas trop mal. Mais j'ai l’impression d'avoir fait un peu la même chose (en moins approfondi) il y a huit ans. J'ai fais une classe pour gérer mes accès aux données avec deux fonctions qui me retourne soit un Scalaire (donc pour une valeur ou faire des Insert, des Update ou des Delete), soit une DataTable pour lire un recordset complet. J'envoi un SqlParameter et le texte de le requête en dur avec les variables. Du coup je me blinde contre les SQL Injection et je me facilite la vie pour gérer mon accès aux données.

Bref, je m'étale un peu. Mais surtout je regarde tous ces nouveaux trucs qui sont sortis depuis huit ans et je me demande si vraiment ça sert. En gros, les entreprises ont besoins le plus souvent de choses simple et les EF ou autre MVC ont l'air de rendre le codage plus complexe qu'autre chose si on reste dans des "petits" sites. Faut vraiment que je trouve un boulot dans une boite qui fait des "petits" sites ou alors un boulot transverse où je code pas, mais là, j'ai du mal à trouver. Après tout, j'étais bon pour gérer les projets chez LVMH.

Encore merci à tous, ça m'a fait très plaisir d'échanger avec vous. Je vais clôturer ce topic pour ne pas encombrer le forums, j'ai mes réponses.
Je reste ouvert à la discussion, si vous voulez.

[Pol63]

tout est en effet une question de compromis (perf, temps de développement, lisibilité du code, cout processeur, ram utilisée, temps de réponse ... il faut faire des choix mais on peut rarement tout avoir ^^)
MVC et certains autres pattern ca devient vite indispensable sur des gros projets, ca permet d'avoir une maintenabilité, mais ca peut rester flou pour des débutants avec un petit projet
EF c'est encore autre chose, ca simplifie réellement le code, et ce n'est pas compliqué à comprendre, par contre ca peut perdre en perf et parfois en nombre de lignes de code
mais bon le but d'un projet n'est pas forcément d'avoir des développeurs débutants qui comprennent du code simple, ca dépend des projets, mais parfois il faut du code complexe que seuls certains peuvent appréhender rapidement

avec les trucs de base (qui sont la base du développement qu'un développeur devrait connaitre, comme écrire une requete performante) on peut encore développer de nos jours
mais si on part sur les performances il y a plein de chose qui entrent en compte, comme les indexes sur ta base de données par exemple, ou encore les reconstructions d'indexes
en bref on arrive vite à comprendre qu'une seule personne peut rarement maitriser toute la chaine de perte de performance possible

après le principe c'est de le faire, puis de faire en sorte que ca marche et enfin de faire en sorte que ca marche vite
donc commence déjà par y faire (marcher) et après tu te poseras les questions sur les perfs
en entreprise on ne s'attarde pas forcément sur les perfs de tout, là aussi c'est une question de compromis, et le temps de développement est un facteur à prendre en compte
donc quand ca rame on cherche ou ca rame le plus pour n'optimiser que ca
(après oui avec l'expérience on peut écrire du code qui marche rapidement directement)