La conception pilotée par le domaine est-elle un modèle anti-SQL?


44

Je plonge dans le DDD (Domain Driven Design) et même si j'y vais plus profondément, il y a des choses que je ne comprends pas. Si je comprends bien, l’un des principaux objectifs est de séparer la logique de domaine (logique d’entreprise) de l’infrastructure (base de données, système de fichiers, etc.).

Ce que je me demande, c'est ce qui se passe lorsque j'ai des requêtes très complexes comme une requête de calcul de ressources matérielles. Dans ce type de requête, vous travaillez avec des opérations sur des ensembles lourds, le genre de choses pour lesquelles SQL a été conçu. Effectuer ces calculs à l'intérieur de la couche de domaine et travailler avec de nombreux ensembles, c'est comme abandonner la technologie SQL.

Ces calculs dans l'infrastructure ne peuvent pas se produire non plus, car le modèle DDD permet de modifier l'infrastructure sans changer la couche de domaine et sachant que MongoDB ne dispose pas des mêmes fonctionnalités, par exemple SQL Server, cela ne peut pas se produire.

Est-ce un piège du modèle DDD?


34
Bien que SQL soit conçu pour gérer l’algèbre des ensembles relationnels, ce n’est pas un jour amusant lorsque vous réalisez que la moitié de votre logique d’entreprise est enfouie dans une poignée de fonctions SQL difficiles à refactoriser et encore plus difficile à tester. Donc, déplacer ceci sur la couche de domaine où il peut jouer avec ses amis me semble attrayant. Est-ce que cela jette une bonne partie de la technologie SQL? Bien sûr, mais SQL est beaucoup plus facile à gérer lorsque vous utilisez uniquement SELECT / JOIN.
Jared Goguen le

30
@JaredGoguen mais cela peut être dû au fait que vous n'êtes pas un expert en SQL et non à la technologie
Leonardo Mangano

2
@JimmyJames Ce que j'ai essayé de dire, c'est que si le DDD est bien implémenté, il permet de changer de couche avec un minimum d'effort, comme de passer de SQL Server à MongoDB. Mais, si vous avez des requêtes complexes dans le code SQL, il est possible que je ne puisse pas basculer vers MongoDB en raison de leurs différences techniques. Je pense avoir dit une chose évidente.
Leonardo Mangano le

7
... is like throwing away the SQL technologyCe n’est pas parce qu’une technologie donnée peut faire quelque chose que c’est le meilleur choix. C’est une preuve anecdotique, mais j’ai rencontré beaucoup trop d’entreprises qui stockaient la logique d’entreprise dans la base de données et s’éloignaient de cette base en raison des problèmes de maintenabilité à long terme qu’elle entraîne. Une simplification excessive, mais les bases de données servent à stocker des données et les langages de programmation à transformer des données. Je ne voudrais pas utiliser une base de données pour la logique métier plus que d'essayer d'utiliser mon application pour stocker mes données directement.
Conor Mancone le

8
SQL lui-même est un excellent exemple de DDD. Face à l’organisation des données associées, les utilisateurs ont d’abord spécifié un langage pour le faire: SQL. La mise en œuvre importe peu. Un administrateur de base de données n'a pas besoin de connaître C / C ++ pour interroger la base de données. De même, face à la tâche de planification des événements, une personne a proposé la syntaxe CRON (mhdmw), un modèle de domaine simple qui répond à 99% des problèmes de planification. Le noyau de DDD n’est pas de créer des classes ou des tables, etc. Il faut comprendre votre problème et mettre au point un système qui fonctionne dans votre domaine de problèmes
slebetman

Réponses:


39

De nos jours, il est probable que les lectures (requêtes) soient traitées différemment des écritures (commandes). Dans un système avec une requête compliquée, il est peu probable que la requête elle-même passe par le modèle de domaine (qui est principalement responsable du maintien de la cohérence des écritures ).

Vous avez absolument raison de dire que nous devrions rendre à SQL ce qui est SQL. Nous allons donc concevoir un modèle de données optimisé autour des lectures, et une requête de ce modèle de données utilise généralement un chemin de code n'incluant pas le modèle de domaine (à l'exception peut-être d'une validation d'entrée - garantissant que les paramètres de la requête sont raisonnables).


13
+1 Bonne réponse, mais vous devriez donner à ce concept son nom propre, Ségrégation Command-Requête.
Mike soutient Monica le

6
@Mike Avoir des modèles de lecture et d'écriture complètement différents s'apparente davantage à CQRS qu'à CQS.
Andy le

3
Le "modèle de lecture" n'est-il pas le modèle de domaine (ou une partie de celui-ci)? Je ne suis pas un expert en CQRS, mais j'ai toujours pensé que le modèle de commande était assez différent du modèle de domaine classique, mais pas du modèle de lecture. Alors peut-être que vous pouvez donner un exemple pour cela?
Doc Brown le

Il m'a fallu trop longtemps pour comprendre que High Performance Mark attirait l'attention sur une faute de frappe.
VoiceOfUnreason

@DocBrown - voici ma tentative de clarification pour vous -> cascadefaliure.vocumsineratio.com/2019/04/…
VoiceOfUnreason

21

Si je comprends bien, l’un des principaux objectifs est de séparer la logique de domaine (logique d’entreprise) de l’infrastructure (base de données, système de fichiers, etc.).

C’est là le fondement du malentendu: le but de DDD n’est pas de séparer les choses le long d’une ligne dure comme "ceci est dans le serveur SQL, donc ne doit pas être BL", le but de DDD est de séparer les domaines et de créer des barrières entre ceux qui permettent aux éléments internes d’un domaine d’être complètement séparés des éléments internes d’un autre domaine et de définir des éléments externes partagés entre eux.

Ne pensez pas que "être en SQL" est la barrière BL / DL - ce n'est pas ça. Au lieu de cela, pensez à "c'est la fin du domaine interne" en tant que barrière.

Chaque domaine doit avoir des API externes lui permettant de fonctionner avec tous les autres domaines: dans le cas de la couche de stockage de données , il doit comporter des actions de lecture / écriture (CRUD) pour les objets de données qu'il stocke. Cela signifie que SQL lui-même n'est pas vraiment la barrière, les composants VIEWet PROCEDUREsont. Vous ne devriez jamais lire directement dans le tableau: c’est le détail de l’implémentation que DDD nous dit qu’en tant que consommateur externe, nous ne devrions pas nous inquiéter.

Considérez votre exemple:

Ce que je me demande, c'est ce qui se passe lorsque j'ai des requêtes très complexes comme une requête de calcul de ressources matérielles. Dans ce type de requête, vous travaillez avec des opérations sur des ensembles lourds, le genre de choses pour lesquelles SQL a été conçu.

C’est exactement ce qui devrait être dans SQL alors, et ce n’est pas une violation de DDD. C'est ce pour quoi nous avons fait DDD . Avec ce calcul en SQL, cela fait partie de la BL / DL. Ce que vous feriez, c’est d’utiliser une vue / procédure stockée / what-have-you distincte et de maintenir la logique métier séparée de la couche de données, car c’est votre API externe. En fait, votre couche de données doit être une autre couche de domaine DDD, dans laquelle votre couche de données possède ses propres abstractions pour fonctionner avec les autres couches de domaine.

Ces calculs dans l'infrastructure ne peuvent pas se produire non plus, car le modèle DDD permet de modifier l'infrastructure sans changer la couche de domaine et sachant que MongoDB ne dispose pas des mêmes fonctionnalités, par exemple SQL Server, cela ne peut pas se produire.

C'est un autre malentendu: il est dit que les détails de l'implémentation en interne peuvent changer sans changer les autres couches de domaine. Il ne dit pas que vous pouvez simplement remplacer tout un élément d'infrastructure.

Encore une fois, rappelez-vous, DDD consiste à masquer les éléments internes avec des API externes bien définies. La position de ces API est une question totalement différente, et DDD ne le définit pas. Il définit simplement que ces API existent et ne devraient jamais changer .

DDD n'est pas configuré pour vous permettre de remplacer ad-hoc MSSQL par MongoDB: il s'agit de deux composants d'infrastructure totalement différents.

Utilisons plutôt une analogie pour définir ce que DDD définit: les voitures à essence par rapport aux voitures électriques. Les deux véhicules ont deux méthodes complètement différentes pour créer une propulsion, mais ils ont les mêmes API: un marche / arrêt, une manette des gaz / frein et des roues pour propulser le véhicule. DDD affirme que nous devrions pouvoir remplacer le moteur (à essence ou électrique) de notre voiture. Cela ne dit pas que nous pouvons remplacer la voiture par une moto, et c'est en fait ce que MSSQL → MongoDB est.


1
Merci pour l'explication. Pour moi, c'est un sujet très difficile, tout le monde a un point de vue différent. La seule chose avec laquelle je ne suis pas d'accord est la comparaison entre MSSQL (voiture) et MongoDB (moto). Pour moi, la bonne comparaison est qu'il s'agit de deux moteurs différents pour la même voiture, mais ce n'est qu'un avis.
Leonardo Mangano le

8
@ LeonardoMangano Ah, mais ils ne le sont pas. MSSQL est une base de données relationnelle, MongoDB est une base de données de documents. Oui, "base de données" décrit les deux, mais c'est à peu près tout. Les techniques de lecture / écriture sont complètement différentes. Au lieu de MongoDB, vous pourriez utiliser Postgre ou MySQL comme alternative, ce qui constituerait une comparaison valable.
410_Gone Le

3
"Tu ne devrais jamais lire directement de la table ..." Folie.
JPMc26 le

"Vous ne devriez jamais lire directement à partir de la table ..." C'est une règle que je suis venu à appliquer par moi-même après une décennie d'écriture d'un logiciel qui s'interface avec des bases de données et qui souffrait de la peine de vouloir suivre des tutoriels structurés autour de modèles de conception populaires.
Lucifer Sam

@ LuciferSam Aye. Cela facilite beaucoup la gestion de la séparation entre les détails d'implémentation et les limites de domaine. Un "objet" dans le domaine peut être représenté par 5 tables. Nous utilisons donc une vue pour encapsuler cet objet.
410_Gone

18

Si vous avez déjà participé à un projet pour lequel l'organisation qui paye l'hôte de l'application décide que les licences de couche de base de données sont trop chères, vous apprécierez la facilité avec laquelle vous pouvez migrer votre stockage de base de données / données. Tout bien considéré, même si cela arrive, cela n'arrive pas souvent .

Vous pouvez obtenir le meilleur des deux mondes pour ainsi dire. Si vous considérez que l'exécution des fonctions complexes de la base de données est une optimisation, vous pouvez utiliser une interface pour injecter une autre implémentation du calcul. Le problème est que vous devez maintenir la logique à plusieurs endroits.

Déviant d'un motif architectural

Lorsque vous vous trouvez en désaccord avec la mise en œuvre d'un schéma purement ou avec des écarts dans certains domaines, vous avez une décision à prendre. Un modèle est simplement un moyen de faire des choses sur la base de modèles pour aider à organiser votre projet. À ce stade, prenez le temps d’évaluer:

  • Est-ce le bon modèle? (plusieurs fois c'est le cas, mais parfois c'est juste un mauvais ajustement)
  • Devrais-je dévier de cette manière?
  • Jusqu'où ai-je dévié jusqu'à présent?

Vous constaterez que certains modèles d'architecture conviennent pour 80 à 90% de votre application, mais pas autant pour les bits restants. L’écart occasionnel par rapport au modèle prescrit est utile pour des raisons de performance ou de logistique.

Toutefois, si vous constatez que vos écarts cumulatifs représentent bien plus de 20% de votre architecture d’application, il s’agit probablement d’un mauvais ajustement.

Si vous choisissez de vous en tenir à l'architecture, alors rendez-vous service et indiquez où et pourquoi vous vous êtes écarté de la façon de faire prescrite. Lorsque vous avez un nouveau membre enthousiaste dans votre équipe, vous pouvez lui indiquer la documentation qui comprend les mesures de performance et les justifications. Cela réduira le risque de demandes répétées pour résoudre le "problème". Cette documentation contribuera également à dissuader les déviations généralisées.


J'éviterais l'utilisation de phrases telles que "est-ce le bon modèle" dans les réponses. Il est déjà assez difficile d'amener les gens à être plus précis lorsqu'ils écrivent leurs questions et, de votre propre aveu, "c'est parfois un mauvais choix", ce qui suggère que non, ce n'est pas le bon modèle.
Robert Harvey le

@ RobertHarvey, j'ai participé à des projets où le modèle utilisé n'était tout simplement pas adapté à l'application, ce qui a entraîné l'échec de certaines mesures de qualité. Ce n'est certainement pas la norme, mais lorsque cela se produit, vous devez prendre la décision difficile de modifier les architectures ou de conserver du code de décor dans l'application. Plus tôt vous pourrez déterminer le mauvais ajustement, plus il sera facile de remédier à la situation. C'est pourquoi j'inclus toujours cette pensée dans l'évaluation des cas extrêmes. En même temps que la dernière balle, vous ne réalisez parfois pas à quel point il est difficile d’atteindre l’aide jusqu’à ce que vous constatiez une accumulation de déviations.
Berin Loritsch le

7

La logique de manipulation des ensembles dans laquelle SQL est bon peut être intégrée à DDD sans problème.

Supposons par exemple que je doive connaître une valeur globale, le nombre total de produits par type. Facile à exécuter en sql, mais lent si je charge tous les produits en mémoire et les additionne tous.

J'introduis simplement un nouvel objet de domaine,

ProductInventory
{
    ProductType
    TotalCount
    DateTimeTaken
}

et une méthode sur mon référentiel

ProductRepository
{
    List<ProductInventory> TakeInventory(DateTime asOfDate) {...}
}

Bien sûr, je compte peut-être maintenant sur certaines bases de ma DB. Mais techniquement, j'ai toujours la séparation et tant que la logique est simple, je peux dire que ce n'est pas de la "logique métier"


Eh bien, jusqu'à présent, je m'en souviens. Les référentiels sont supposés être Queryaussi des paramètres. repository.find(query);. J'ai lu la même chose mais avec Specs. That opens a door to leave Query` comme une abstraction et / QueryImplou une implémentation de requête spécifique à la couche infrastructure.
Laiv

5
oh mon dieu, je sais que certaines personnes le font mais je pense que c'est affreux. Vous pouvez voir ce genre de chose comme une étape dans cette voie. Mais je pense que cela peut être pris avec prudence.
Ewan

I know some people do thatCertaines personnes sont Pivotal et son cadre. SpringFramework a beaucoup de cela :-). Quoi qu'il en soit, comme @VoiceOfUnreason l'a suggéré, la clé autour de DDD est de conserver la cohérence des écritures. Je ne suis pas sûr de forcer la conception avec des modèles de domaine dont le seul but est d'interroger ou de paramétrer des requêtes. Cela pourrait être abordé en dehors du domaine avec des structures de données (pocos, pojos, dtos, row mappers, peu importe).
Laiv

de toute évidence, nous avons besoin d’une sorte d’inquisition pour aider ces personnes à retrouver leur santé mentale. Mais je m'en tiens à mes armes. L'exposition partielle de la couche de données est acceptable si elle permet objectivement une meilleure application, où ce qui est ou non un "objet de domaine" est subjectif
Ewan

1
@LeonardoMangano dépend de votre application et de sa mise en œuvre. La principale chose à réaliser est que vous pouvez réinterpréter votre domaine pour le rendre praticable.
Ewan le

3

Pour résoudre ce dilemme, l’un des moyens possibles consiste à considérer le langage SQL comme un langage d’assemblage: vous codez directement dans ce langage, mais lorsque les performances sont importantes, vous devez être en mesure de comprendre le code produit par votre langage. / C ++ / Golang / Rust et peut-être même écrire un petit fragment d'assemblage, si vous ne pouvez pas modifier le code dans votre langage évolué pour produire le code machine souhaité.

De même, dans le domaine des bases de données et du langage SQL, diverses bibliothèques SQL (dont certaines sont ORM ), telles que SQLAlchemy et Django ORM pour Python, LINQ pour .NET, fournissent des abstractions de niveau supérieur tout en utilisant le code SQL généré dans la mesure du possible pour améliorer les performances. Elles fournissent également une certaine portabilité quant à la base de données utilisée, avec éventuellement des performances différentes, par exemple sur Postgres et MySQL, en raison de certaines opérations utilisant un code SQL plus optimal spécifique à la base de données.

Et comme pour les langages de haut niveau, il est essentiel de comprendre le fonctionnement de SQL, même s'il ne s'agit que de réorganiser les requêtes effectuées avec les bibliothèques SQL mentionnées ci-dessus, pour pouvoir atteindre l'efficacité souhaitée.

PS Je préférerais en faire un commentaire mais je n’ai pas une réputation suffisante pour cela.


2

Comme d'habitude, c'est l'une de ces choses qui dépend d'un certain nombre de facteurs. Il est vrai que vous pouvez faire beaucoup de choses avec SQL. Son utilisation présente également des difficultés et certaines limitations pratiques des bases de données relationnelles.

Comme Jared Goguen le note dans les commentaires, SQL peut être très difficile à tester et à vérifier. Les principaux facteurs qui ont conduit à cela sont le fait qu’il ne peut pas (en général) être décomposé en composants. En pratique, une requête complexe doit être considérée dans son intégralité. Un autre facteur de complication est que le comportement et l'exactitude du code SQL dépendent fortement de la structure et du contenu de vos données. Cela signifie que tester tous les scénarios possibles (ou même déterminer ce qu'ils sont) est souvent irréalisable ou impossible. Le refactoring de SQL et la modification de la structure de la base de données sont également problématiques.

L'autre facteur important qui a conduit à l'abandon de SQL est que les bases de données relationnelles ont tendance à évoluer uniquement verticalement. Par exemple, lorsque vous générez des calculs complexes en SQL à exécuter dans SQL Server, ils s'exécutent sur la base de données. Cela signifie que tout ce travail utilise des ressources sur la base de données. Plus vous en ferez avec SQL, plus votre base de données aura besoin de ressources en mémoire et en CPU. C’est souvent moins efficace de faire cela sur d’autres systèmes, mais il n’ya pas de limite pratique au nombre de machines supplémentaires que vous pouvez ajouter à une telle solution. Cette approche est moins coûteuse et plus tolérante aux pannes que la construction d’un serveur de base de données monstre.

Ces problèmes peuvent ou non s’appliquer au problème à résoudre. Si vous êtes capable de résoudre votre problème avec les ressources de base de données disponibles, peut-être que SQL convient à votre problème. Vous devez toutefois envisager la croissance. Tout va bien aujourd'hui, mais dans quelques années, l'ajout de ressources supplémentaires risque de poser problème.


L’alternative à une base de données monstre n’est-elle pas simplement un nombre monstrueux et une diversité de systèmes auxiliaires? Quelle est la résilience des systèmes auxiliaires, s’ils sont tous suspendus au système principal? Et si la justification est simplement la limitation technologique du système principal, il s'agira souvent d'une optimisation prématurée pour la plupart des systèmes d'entreprise. SQL peut généralement être écrit de manière découplée, si nécessaire.
Steve

@Steve Je pense que là où vous vous êtes trompé, c'est de supposer qu'il doit exister un système de base unique sur lequel les autres peuvent se tenir.
JimmyJames

@Steve Pour donner un exemple, vous pouvez remplacer une base de données complète du système par une seule base de données non-SQL (je ne dis pas que c'est toujours le bon choix, mais que cela peut être fait.) Cette base de données peut ensuite être stockée dans plusieurs systèmes, même des régions géographiques. Une telle base de données n'est pas auxiliaire, c'est un remplacement en gros de la base de données SQL.
JimmyJames

@ JimmyJames, d'accord, mais lorsqu'il n'y a pas de système central, cela peut créer ses propres problèmes pour l'analyse des dépendances et le maintien de la cohérence des données. C'est la raison pour laquelle les monolithes créent une certaine sorte de simplicité, et donc certains types d'analyse et d'efficacité de maintenance. Les solutions non monolithiques échangent simplement certains problèmes ou coûts pour d’autres.
Steve

@jmoreno Jeter des ressources sur quelque chose afin de boiter avec ce n'est pas ce que j'appellerais une bonne ingénierie: "afin de gérer le volume de données énorme du site, et exécute 9 000 instances de memcached afin de suivre le nombre de transactions la base de données doit servir. " Considérez-vous le coût de vos conceptions ou supposez-vous que quelqu'un va débourser de l'argent pour que vos préférences personnelles soient exploitables?
JimmyJames

2

Est-ce un piège du modèle DDD?

Permettez-moi d’abord de dissiper quelques idées fausses.

DDD n'est pas un motif. Et cela ne prescrit pas vraiment de modèles.

La préface du livre DDD d'Eric Evan se lit comme suit :

Les principaux concepteurs de logiciels considèrent la modélisation et la conception de domaines comme des sujets critiques depuis au moins 20 ans. Pourtant, étonnamment, peu de choses ont été écrites sur ce qui doit être fait ou comment le faire. Bien qu’elle n’ait jamais été clairement formulée, une philosophie est apparue comme un courant sous-jacent dans la communauté d’objets, une philosophie que j’appelle la conception pilotée par domaine.

[...]

Une caractéristique commune aux succès est un modèle de domaine riche qui a évolué à travers des itérations de conception et est devenu une partie intégrante de la structure du projet.

Ce livre fournit un cadre pour prendre des décisions de conception et un vocabulaire technique pour discuter de la conception de domaines. C'est une synthèse des meilleures pratiques largement acceptées ainsi que de mes propres idées et expériences.

C'est donc une façon d'aborder le développement de logiciels et la modélisation de domaine, ainsi que du vocabulaire technique prenant en charge ces activités (un vocabulaire comprenant divers concepts et schémas). Ce n'est pas quelque chose de complètement nouveau.

Une autre chose à garder à l'esprit est qu'un modèle de domaine n'est pas sa mise en œuvre OO qui peut être trouvée dans votre système - c'est juste une façon de l'exprimer, ou d'en exprimer une partie. Un modèle de domaine est la façon dont vous envisagez le problème que vous essayez de résoudre avec le logiciel. C'est comment vous comprenez et percevez les choses, comment vous en parlez. C'est conceptuel . Mais pas dans un sens vague. C'est profond et raffiné, et c'est le résultat d'un travail acharné et de la collecte de connaissances. Il est ensuite affiné et a probablement évolué au fil du temps et implique des considérations de mise en œuvre (dont certaines peuvent limiter le modèle). Il devrait être partagé par tous les membres de l'équipe (et experts de domaine impliqués), et cela devrait guider la manière dont vous implémentez le système, de sorte que le système le reflète étroitement.

Rien à ce sujet n'est intrinsèquement pro ou anti-SQL, bien que les développeurs OO soient peut-être généralement mieux en mesure d'exprimer le modèle dans des langages OO, et que l'expression de nombreux concepts de domaine est mieux prise en charge par OOP. Mais parfois, certaines parties du modèle doivent être exprimées dans un paradigme différent.

Ce que je me demande, c'est ce qui se passe lorsque j'ai des requêtes très complexes [...]?

De manière générale, il existe deux scénarios.

Dans le premier cas, certains aspects d'un domaine nécessitent en réalité une requête complexe, et cet aspect est peut-être mieux exprimé dans le paradigme SQL / relationnel - utilisez donc l'outil approprié pour le travail. Reflétez ces aspects dans votre pensée de domaine et le langage utilisé dans la communication de concepts. Si le domaine est complexe, il s'agit peut-être d'une partie d'un sous-domaine avec son propre contexte lié.

L'autre scénario est que le besoin perçu d'exprimer quelque chose en SQL est le résultat d'une pensée contrainte. Si une personne ou une équipe a toujours eu une pensée orientée base de données, il peut être difficile pour elles, juste à cause de l'inertie, de voir une manière différente d'aborder les choses. Cela devient un problème lorsque l'ancienne méthode ne répond pas aux nouveaux besoins et nécessite une réflexion originale. DDD, en tant qu'approche de la conception, consiste en partie à trouver des moyens de sortir de cette boîte en rassemblant et en distillant les connaissances sur le domaine. Mais tout le monde semble ignorer cette partie du livre et se concentre sur le vocabulaire technique et les modèles énumérés.


0

Sequel est devenu populaire lorsque la mémoire coûtait cher, car le modèle de données relationnel offrait la possibilité de normaliser vos données et de les stocker efficacement dans le système de fichiers.

Maintenant, la mémoire est relativement peu coûteuse, nous pouvons donc ignorer la normalisation et stocker dans le format que nous utilisons ou même dupliquer beaucoup de mêmes données pour des raisons de rapidité.

Considérez la base de données comme un simple périphérique IO , auquel il incombe de stocker des données dans le système de fichiers - oui, je sais que c'est difficile à imaginer, car nous avons écrit de nombreuses applications avec une logique métier importante écrite dans des requêtes SQL - mais essayez simplement d'imaginer que SQL Server est juste une autre imprimante.

Souhaitez-vous incorporer le générateur de PDF dans le pilote d'imprimante ou ajouter un déclencheur qui imprimera une page de journal pour chaque commande client imprimée sur notre imprimante?

Je suppose que la réponse sera non, car nous ne voulons pas que notre application soit couplée au type de périphérique spécifique (sans même parler de l'efficacité d'une telle idée)

Dans les années 70-90, la base de données SQL était efficace, maintenant? - Vous n'êtes pas sûr que, dans certains cas, une requête de données asynchrone renvoie les données requises plus rapidement que plusieurs jointures dans une requête SQL.

Le langage SQL n'était pas conçu pour les requêtes complexes, mais pour le stockage efficace des données, puis pour fournir une interface / un langage permettant d'interroger les données stockées.

Je dirais que construire votre application autour d'un modèle de données relationnel avec des requêtes complexes constitue un abus du moteur de base de données. Bien entendu, les fournisseurs de moteur de base de données sont satisfaits lorsque vous associez étroitement votre entreprise à leur produit. Ils seront plus qu'heureux de fournir davantage de fonctionnalités qui rendront ce lien plus fort.


1
Mais je continue de penser que le langage SQL est bien meilleur pour les calculs d'ensemble que tout autre langage. De mon point de vue. votre exemple est à l'envers, utiliser C # pour des opérations très complexes avec des millions de lignes et de jointures implique d'utiliser le mauvais outil, mais je peux me tromper.
Leonardo Mangano

@ LeonardoMangano, quelques exemples: avec c #, je peux fragmenter des millions de lignes et les calculer en parallèle, je peux récupérer des données de manière asynchrone et exécuter des calculs "à temps" lorsque les données sont renvoyées, avec c #, je peux effectuer des calculs avec une utilisation de mémoire réduite en énumérant des lignes par rangée. Avoir une logique complexe dans le code vous fournira de nombreuses options pour effectuer des calculs.
Fabio le
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.