VB.NET (MVP) manipuler de gros volumes de données

Je suis sur un projet en VB.NET qui suit un framework MVP (Model View Presenter)

J'ai un problème de conscience... :aie:

Je dois construire un objet métier qui détermine des alertes sur données. Mais pour calculer les alertes je dois croiser le résultat de plusieurs tables contenant plus de 10 millions de lignes sous SQL-Server.

Dois-je réaliser les traitements métier en VB.NET dans mon objet métier ?
Si oui je ne risque pas de mettre à genoux le serveur si je manipule des dataTable de 10 millions de lignes ?

Si non, suis obligé de traiter mes données par des procédures stockées, mais alors je ne suis plus indépendant de la base de données. (je ne suis plus 3 tiers ni MVP)

Merci de vos conseils avisés.

Citation:

---

Envoyé par bdmax

Si non, suis obligé de traiter mes données par des procédures stockées, mais alors je ne suis plus indépendant de la base de données. (je ne suis plus 3 tiers ni MVP)

---

ah bon ???

Je n'ai jamais entendu ailleurs que les architectures trois tiers présupposaient de ne pas utiliser de procédures stockées...

Je ne suis pas non plus Martin Fowler, mais je ne vois pas en quoi une procédure stockée va a l'encontre d'une séparation en tiers ;)

Tu vas me dire "oui, mais une sp, c'est un traitement métier sur la base de données"...oui, comme une requête :mouarf:

Ce que ta base de données te retourne, ce sont des données, que tu fasse ta requête sous forme de requete sql ou de procédure stockée...

De toute façon, si tu te trimbales des paquets de 10 000 000 de tuples, tu vas tuer ton serveur, ton réseau, ton dba va brûler ta voiture, ton patron va prendre des arrêts maladie le jour de ton entretien annuel, et quand tu parleras de ton application, on te regardera en disant "ah, oui, cette application la..."

Après, chacun fait ce qu'il veut ;)

Merci pour cette réponse,

C'est très clair, voire sarcastique... :roll:

Tu préconises donc en résumé, de filtrer les données à manipuler directement dans la base de données, puis d'appliquer les règles de gestion métier light sur l'ensemble restant ?

Je pensais avoir des objets métier plus consistant, mais cela semble impossible en effet.

Merci pour m'avoir conforté dans mon intuition :aie:

Citation:

---

C'est très clair, voire sarcastique...

---

désolé, il était tard :mrgreen:

Citation:

---

Envoyé par pvialatte

Tu vas me dire "oui, mais une sp, c'est un traitement métier sur la base de données"...oui, comme une requête :mouarf:

---

Ah bah non ! Une simple récupération de données n'est pas un traitement métier ;)

Enfin bref, pour répondre à BDMax et être un peu plus nuancé, tu as deux approches possibles : soit être "puriste" et réaliser le traitement en VB.Net au risque de mettre ton serveur à genoux, soit être plus réaliste et déléguer cette tâche à la base de données.

Avec une approche "naïve" qui consiste à traiter tes 10 millions de lignes d'un coup, il est clair que le faire en VB.Net est suicidaire. Une base de données sait faire certaines choses beaucoup mieux qu'un code objet, et il ne faut pas non plus être intégriste au point de refuser de voir les cas ou la BDD est nettement plus performante que l'objet...

Cela dit, vouloir éviter de placer de la logique métier dans la BDD pour une question de consistence est un argument valable; donc à toi de voir s'il est possible de définir une stratégie avec des performances acceptables en VB.Net (découpage et traitement par lots par exemple), ou s'il est possible d'arriver à un compromis (consolidations/organisation des données et exposition sous forme de vues côté base, puis traitement métier côté VB).