Discussion :

[ClaudeBg]

Bonjour,
--------

Je suis pour l'instant un peu contraint de mener plusieurs programmes de front. Pour l'un d'eux (qui sort de mes domaines habituels), j'ai besoin de me construire une sorte de petite base de données, avec :

- Sauvegarde dans deux fichiers (2 "bases" : "clients" et "factures")
- Accès à partir d'un seul PC, et pas de partage des accès nécessaire
- Requêtes sur le contenu des deux fichiers.

J'ai fait quelques essais concluants avec Linq to XML dans le cadre d'un autre programme, mais je m'interroge sur le fond même du problème :

Est-ce judicieux de créer des documents XML pour sauver les mini-bases de données, ou vaut-il mieux utiliser des fichiers d'un autre type?

Je m'interroge en fait sur la façon la plus optimale de travailler : sérialisation et désérialisation d'une classe personnelle? Travail direct sur fichiers XML avec load? Lancement d'un serveur SQL? Autre solution?

Je cherche le maximum de rapidité de traitement avec le minimum de ressources (le serveur SQL me semble démesuré pour une base à accès par un seul programme). Linq 2 XML semble génial et simple à mettre en oeuvre, mais je me demande s'il est judicieux de créer toute une structure XML alors qu'au final je n'ai besoin pour cette application de n'être compatible avec personne, ni avec aucun format standard.

Quelle est la bonne piste?

Merci d'avance
Claude

[(Benoit)]

J'ai déjà eu cette problèmatique. A l'époque tout ce que j'avais sous la main pour faire ça c'était... Access. N'empêche ça répond à ton besoin : tu as tes données sous forme de fichiers, tu peux faire des requêtes SQL dessus !

[Gulix]

Pourquoi pas du SQLite ? Tu y accèdes comme à une base de données, mais au lieu d'attaquer un serveur, tu attaques un simple fichier

[tomlev]

Pourquoi pas du SQLite ? Tu y accèdes comme à une base de données, mais au lieu d'attaquer un serveur, tu attaques un simple fichier

+1 !
1000 fois mieux qu'Access...
Plus d'infos : http://sqlite.org/
Provider ADO.NET : http://sqlite.phxsoftware.com/

[WOLO Laurent]

Bonjour,
--------
J'ai besoin de me construire une sorte de petite base de données, avec :
- Sauvegarde dans deux fichiers (2 "bases" : "clients" et "factures")
- Accès à partir d'un seul PC, et pas de partage des accès nécessaire
- Requêtes sur le contenu des deux fichiers.
Claude

Bonjour,
Si l'objectif est de ne pas recréer la roue, il vaut mieux partir pour un SGBDR qui offre la plupart des fonctionalités des bases de données modernes actuelles.
Qu'est ce qui va se passer si ton bosse ou ton client te demande d'ajouter telle ou telle autres fonctionnalités, requêtes et états ?
Tu vas te retrouver avec une application à recréer quelle perte de temps !
Pour ma part, je te conseillerais d'utiliser une version lite de SQL Serveur 2005. Merci pour votre comprehension.

[ddaime]

Une autre alternative à SQLite, c'est Microsoft SQL Server CE

[ClaudeBg]

Bonjour,

Merci pour les conseils.

Mon but n'est pas de faire une application commerciale, ni pour un patron.
C'est simplement pour rendre service à un ami qui trouve les programmes commerciaux trop compliqués et trop "blocants" (impossible de modifier des factures déjà établies par exemple). Il en a déjà acheté 2, et ça ne lui convient pas. Son ancien programme (Datafakt) ne tourne plus sur son nouveau PC et la nouvelle version n'est plus aussi simple que l'ancienne. Il a aussi esssayé des logiciels gratuits, mais de nouveau, rien de concluant.

Il veut un petit programme facile d'emploi, permettant juste d'entrer et de chercher des clients, et de rédiger ou modifier une facture pour les dits clients, et c'est pourquoi il voudrait que ce petit programme fonctionne "à la carte", avec une interface utilisateur agréable et rapide.

Pour ma part, je veux bien lui rendre service en lui écrivant un petit programme C# adapté, mais je n'ai pas vraiment envie d'apprendre de nouveaux supports ni logiciels, ni d'acheter une licence pour un utilitaire quelconque.

C'est pourquoi je voulais savoir la meilleure façon de sauver sur disque deux fichiers sur lesquels faire des requêtes linq à partir du C#.

La maintenance ne pose pas problème, j'ai déjà fait un programme de ce genre pour un autre ami (en VB6), et je n'ai du le modifier que 2 fois en 3 ans, et juste pour des petites améliorations. Une fois le programme au point, on n'y touchera plus.

Par contre, si j'utilise un programme dédié que je n'utiliserais pour rien d'autre, le jour où il faudra faire une modification j'aurais oublié comment ça fonctionne et je devrais me farcir à nouveau toute la doc. Franchement, à tout prendre je préfère encore réinventer la roue

Je vais donc préciser ma demande, parce que c'est vrai que ça peut prêter à confusion :

Quelle est la meilleure méthode, à partir d'un programme en C#, pour créer deux fichiers sur lesquels faire ensuite des requêtes linq?

Merci
Claude

[tomlev]

Si tu as besoin de Linq il ne reste plus que 2 choix possibles (dans l'état actuel des choses en tous cas)
- SQLite
- SQL Server Compact
A ma connaissance, ce sont les 2 seules bases de données fichier qui supportent Linq

[WOLO Laurent]

Si tu as besoin de Linq il ne reste plus que 2 choix possibles (dans l'état actuel des choses en tous cas)
- SQLite
- SQL Server Compact
A ma connaissance, ce sont les 2 seules bases de données fichier qui supportent Linq

Non, link peut s'appliquer à n'importe quelle source de données.
Quelle subdivision de Link veux tu utiliser ?

[tomlev]

Non, link peut s'appliquer à n'importe quelle source de données.

Théoriquement seulement...
- Linq to SQL ne marche qu'avec SQL Server (version Compact non comprise il me semble)
- Linq to Entities est un système plus ouvert et peut théoriquement être utilisé pour n'importe quel SGBD, à condition qu'un provider compatible Linq soit implémenté. Pour l'instant il n'y a que très peu d'implémentations viables pour des SGBD autres que SQL Server. Il y en a un qui marche bien pour SQLite, mais pour les bases de données fichier je crois que c'est tout...

Après, on peut bien sûr faire sa propre couche ORM et utiliser Linq dessus (avec Linq to Objects), voire charger les données dans un DataSet et faire du Linq to DataSets. Là ça marchera pour n'importe quelle source de données, mais ce n'est pas du "direct" Linq -> SGBD

[ClaudeBg]

Salut
-----

Non, link peut s'appliquer à n'importe quelle source de données.
Quelle subdivision de Link veux tu utiliser ?

Ben, justement, c'est ma question.
Je me suis probablement mal exprimé dès le départ. Je vais tenter d'être plus explicite.

Avant, lorsque je devais manipuler des données dans un programme, je créais une classe (ou un équivalent selon le langage), je manipulais la classe par du code, et je transférais le contenu de la classe dans un fichier (soit texte , soit binaire selon le contenu). Si je faisais une recherche, j'écrivais le code correspondant "en dur".

Or, je tombe sur des vidéos expliquant qu'avec Linq, on peut maintenant directement faire des requêtes sur des données se trouvant dans des classes ou des collections, exactement comme si on faisait des requêtes SQL sur un serveur SQL. Et ça fonctionne aussi sur des fichiers XML.

Je vois directement l'intérêt, car ça élimine toute nécessité d'écrire le code de recherche et de traitement de l'information, il suffit d'écrire des requêtes Linq. Et ça fonctionne pour tout type de données (classes, collections, etc). Avec le binding, on récupère des tables qui s'affichent directement dans des grilles, c'est très puissant.

Donc, on sait manipuler les données présentes en RAM avec Linq.
Donc, si j'ai bien tout compris, avec Linq, plus besoin de coder en dur mes recherches et manipulations, j'écris pratiquement comme du SQL, alors que je n'ai aucun serveur SQL en service, et je reste à l'intérieur du code de mon programme (erreurs détectées à la compilation et non à l'exécution).

Reste donc à permettre les échanges fichier/Ram (sauvegardes et restaurations)

Or, je vois qu'en gardant les possibilités Linq, on a le choix entre :

- Linq to XML, qui permet de travailler directement en chargeant et sauvant des fichiers XML

- Linq "tout court" : qui semble gérer les requêtes dans des classes ou des tables, mais qui ne s'occupe pas de la sauvegarde/lecture dans les fichiers

- Linq to SQL, qui permet d'envoyer des requêtes à des fichiers gérés par un serveur SQL comme sql server.

Reste donc le problème de savoir "quelle est la meilleure façon d'écrire sur le disque mes données (classes ou collections) :

- Linq to XML, qui fait tout automatiquement, mais qui impose que le fichier sauvegardé soit au format XML (lourdeur? Taille sur le disque? Rapidité pour les conversions?)

- Gestion par code en dur des écritures et des lectures sur le disque, dans un fichier binaire (plus rapide mais moins souple etc) avec utilisation de linq "simple"?

- Installer un serveur SQL sur la machine et y envoyer les requêtes, bien que sachant que les données ne sont pas partagées par d'autres programmes (gaspillage des ressources etc) en utilisant Linq to SQL?

C'est à ce niveau que j'ai besoin d'un conseil, n'ayant jamais utilisé linq : de quelle façon et sous quel format dois-je enregistrer sur disque mes fichiers, sachant que pour l'un d'eux il y aura des champs de longueur variable et que je vais faire des requêtes sur les données qu'il contient via Linq?

Je précise que je parle de petits fichiers, disons 200 clients et 2000 factures pour donner un ordre de grandeur.

Sachant évidemment que la façon de stocker les informations aura une répercussion sur la façon de les traiter.

Et si je décidais par exemple d'utiliser des fichiers XML, vaut-il mieux importer les fichiers dans une classe (désérialisation par exemple) et les traiter avec Linq, ou bien les utiliser tels quels en les chargeant avec load, mais en utilisant alors Linq to XML?

J'espère qu'expliqué comme ça, ma question est plus claire.

Merci pour votre patience

Claude

[tomlev]

(pour info : vu la longueur de ton post, tu as sans doute manqué mon post précédent...)

Si je comprends bien, avant tu utilisais une sorte d'ORM (Object relational mapping) fait à la main ? i.e., tu manipulais des objets qui correspondaient à des entités de la base de données.
Dans ce cas, si tu es habitué à cette approche le plus simple est peut-être de garder la même. Un ORM comme Linq to SQL ou Linq to Entities devrait correspondre à ton besoin.

A mon avis l'utilisation d'un fichier XML n'est pas une très bonne idée : le volume de données n'est pas encore monstrueux mais commence à être conséquent, et plus il va augmenter plus les performances vont se dégrader. D'autre part, la syntaxe de Linq to XML n'est pas super intuitive je trouve (en tous cas beaucoup moins que celle de Linq to Objects/SQL/Entites)

Si tu utilises une BDD, tu profiteras :
- des index qui améliorent les performances lors des accès aux données.
- des transactions qui permettent de garantir l'intégrité et la cohérence des données

Personnellement je trouverais dommage de s'en priver...

[ClaudeBg]

Salut
-----

pour info : vu la longueur de ton post, tu as sans doute manqué mon post précédent...

Effectivement, je l'ai vu après avoir posté

Si je comprends bien, avant tu utilisais une sorte d'ORM (Object relational mapping) fait à la main ? i.e., tu manipulais des objets qui correspondaient à des entités de la base de données.

Oui, tout à fait, sauf qu'il n'y avait même pas de base de données : juste des fichiers contenant du binaire. En fait, les objets et la base étaient abstraits, et n'existaient que dans ma tête.

Je travaillait "bas niveau" en récupérant des "objets" qui n'étaient que des groupes d'octets, dans des fichiers binaires, et je manipulais en sachant l'offset de l'information recherchée dans l'objet en question. Par exemple, pour accéder au champs "X" de l'objet (si j'ose dire) Y, je faisais un seek dans le fichier à l'adresse (Y*taille d'un objet)+offset du champs X

Très rapide, mais lourd et ne correspondant pas à la programmation objet de C#. Ce n'est pas très adapté à un petit logiciel de facturation. De plus, j'ai un de mes programmes domotique à réécrire en C#, et qui devient trop lourd avec cette méthode (trop d'objets différents). Bref, ce que je vais utiliser pour ce petit soft va m'être utile pour l'autre, je fais d'une pierre deux coups. C'est pour ça que c'est important pour moi de partir sur de bonnes bases.

Un ORM comme Linq to SQL ou Linq to Entities devrait correspondre à ton besoin.

Tu réduis donc mon choix à 2, ce qui est déjà une bonne nouvelle.
Si j'ai bien tout compris, Linq to SQL nécessite de faire tourner un serveur SQL sur la machine.

Question1 : est-ce pertinent pour une unique application avec des tables non partagées?

Question 2 : est-ce que ça présente des avantages par rapport à Linq to entities? (je présume que ça veut dire : Linq pour objets en mémoire RAM, genre collections ou classes?)

Question 3 : est-ce possible avec cette méthode de travailler avec des objets de taille variable? Parce que c'était impossible avec ma méthode d'offset, et que ça conduit à un grand gaspillage de place.

On trouve des explications séparées pour les différents concepts, mais rien qui rassemble les avantages et inconvénients des différentes options.
On part toujours dans ces démos d'une hypothèse "si vous avez à manipuler ceci ou celà". Mais moi, je n'ai rien à manipuler à priori, je crée ce que je veux.

A mon avis l'utilisation d'un fichier XML n'est pas une très bonne idée : le volume de données n'est pas encore monstrueux mais commence à être conséquent, et plus il va augmenter plus les performances vont se dégrader.

C'est une réponse claire à une de mes questions. Je pressentais que l'utilisation de XML allait alourdir les opérations, mais c'était difficile d'appréhender si c'était sensible ou non. Tu as répondu, merci. J'élimine Linq to XML, et j'élimine aussi la sauvegarde en fichiers XML.

Si tu utilises une BDD, tu profiteras :

Dois-je comprendre par BDD une base de données explicite gérée par SQL server? Parce que dans une collection aussi, j'ai des indexes.

Si tu parles de BDD via SQL server, ce logiciel tourne-t-il tout le temps sur la machine, ou peut-on le lancer de façon synchrone avec l'application? Parce que le PC va servir à plein d'autres choses, il serait idiot qu'une application inutile tourne sans arrêt.

Désolé pour toutes ces questions, mais je n'utilise jamais des BDD réelles, mon expérience là-dessus se limite à SQL vu à l'école (et ça date, LOL), ainsi qu'à un peu de mysql pour mon site. Mes applications habituelles sont des applications embarquées à microcontroleurs (en "assembleur") et des logiciels PC destinés à communiquer avec mon hardware (VB6). Ici, je suis à l'autre bout de l'informatique, beaucoup plus haut niveau qu'à mon habitude, LOL

Merci
Claude

[tomlev]

Si j'ai bien tout compris, Linq to SQL nécessite de faire tourner un serveur SQL sur la machine.

Question1 : est-ce pertinent pour une unique application avec des tables non partagées?

A mon avis non, mais c'est une question de point de vue...
Je trouve ça un peu galère de devoir installer un serveur pour une application qui de toute façons ne fonctionnera qu'en local. Ca complique pas mal le déploiement.

Question 2 : est-ce que ça présente des avantages par rapport à Linq to entities? (je présume que ça veut dire : Linq pour objets en mémoire RAM, genre collections ou classes?)

Non, ou alors pas grand chose. Au contraire, Linq to Entities est apparu après Linq to SQL pour pallier les manques de Linq to SQL (du moins c'est comme ça que je l'interprète). Linq to Entities a une architecture plus ouverte qui fait que ce n'est pas limité à SQL Server. En plus il y a un découplage entre le modèle physique et le modèle conceptuel de données, ce qui permet d'avoir un modèle objet plus "naturel", qui n'est pas lié à la structure de la base de données. De toutes façons, je crois que MS est en train d'abandonner Linq to SQL au profit de Linq to Entities...

Question 3 : est-ce possible avec cette méthode de travailler avec des objets de taille variable? Parce que c'était impossible avec ma méthode d'offset, et que ça conduit à un grand gaspillage de place.

Euh... qu'est-ce que la taille des objets a à voir dans l'affaire ? A priori en .NET tu n'as jamais besoin de t'en préoccuper, vu que la mémoire est gérée automatiquement. D'ailleurs tu ne connais jamais l'adresse mémoire d'un objet (à moins d'utiliser du code unsafe). Utiliser des tailles d'objet et des offsets, c'est une pratique héritée du C qui n'a plus de raison d'être en .NET (sauf pour l'interopérabilité avec des fonctions natives, ou pour lire des fichiers dans un format binaire propriétaire).

Dois-je comprendre par BDD une base de données explicite gérée par SQL server?

N'importe quelle BDD digne de ce nom

Parce que dans une collection aussi, j'ai des indexes.

Ah bon ? tu t'es fait des collections "custom" alors ? ou tu utilises des Dictionary ou Hashtable ? Je me demande si on est bien en phase sur le sens du terme "index"...

Si tu parles de BDD via SQL server, ce logiciel tourne-t-il tout le temps sur la machine, ou peut-on le lancer de façon synchrone avec l'application? Parce que le PC va servir à plein d'autres choses, il serait idiot qu'une application inutile tourne sans arrêt.

Par défaut ça tourne tout le temps, mais il doit être possible de le démarrer et l'arrêter avec l'application. Mais encore une fois, je pense que SQL Server pour faire ça, c'est un peu utiliser un bulldozer pour écraser une mouche...

[ClaudeBg]

Salut
-----

Déjà , encore merci pour ta patience, il en faut

A mon avis non, mais c'est une question de point de vue...
Je trouve ça un peu galère de devoir installer un serveur pour une application qui de toute façons ne fonctionnera qu'en local. Ca complique pas mal le déploiement.

OK. Ca aussi ça me dérangeait un peu.
XML = fichiers trop lourds
SQL server : contexte trop lourd.
SQL to objets : limité

J'y vois déjà plus clair.

Par contre, tu m'introduis "Linq to entities", et j'avoue que j'étais passé complètement à côté de ce concept, puisque les démos que j'avais trouvées n'en parlaient pas. Il faut dire qu'elles parlaient des anciens noms 'DLinq et XLinq".

Bref, une nouvelle piste, qui, si je te suis bien, est la bonne.

Euh... qu'est-ce que la taille des objets a à voir dans l'affaire ? A priori en .NET tu n'as jamais besoin de t'en préoccuper, vu que la mémoire est gérée automatiquement.

C'est mon côté "bas niveau", LOL.
Ce que je voulais dire, c'est que dans un fichier à accès aléatoire, on se sert de la taille de l'enregistrement comme référence. Du coup, il faut que chaque objet aie la même taille ET les mêmes champs.
Et si j'étais contraint d'utiliser un fichier binaire comme je le faisais avant, il me faut bien des repères pour séparer les différents records.

ou pour lire des fichiers dans un format binaire propriétaire).

C'est de ça dont je parlais. Ici, un moment donné, je pensais devoir "convertir" mes objets en valeurs binaires à envoyer dans un fichier, d'où ma question. En effet, si j'éliminais le XML et que je recourais pas non plus au SQL server, ne me restait qu'une solution "codée" pour enregistrer mes objets dans un fichier binaire.

N'importe quelle BDD digne de ce nom

Pour moi, jusqu'à présent, une BDD était gérée par un serveur. Si je te suis bien, tu parles d'une BDD "interne" au programme, et gérée directement par celui-ci?

Ah bon ? tu t'es fait des collections "custom" alors ? ou tu utilises des Dictionary ou Hashtable ? Je me demande si on est bien en phase sur le sens du terme "index"...

Non, je parlais d'indexer sous forme de numérotation des éléments (indices) et pas au sens BDD du terme.

Mais encore une fois, je pense que SQL Server pour faire ça, c'est un peu utiliser un bulldozer pour écraser une mouche...

C'était bien le sens de mes questions sur ce point. Intuitivement ça me semblait inapproprié.

Mon problème c'est que tu avais éliminé toutes les autres solutions que je connaissais, vu que j'avais loupé le chapitre "Linq to entities". Ne me restait donc pas d'autre choix que SQL server, d'où ma perplexité.

Maintenant que grâce à toi j'ai la bonne piste, je vais chercher des tutoriaux et des exemples sur Linq to Entities afin de voir ce que ça représente au juste, et comment mettre ça en oeuvre en pratique.



Claude

[tomlev]

Pour moi, jusqu'à présent, une BDD était gérée par un serveur. Si je te suis bien, tu parles d'une BDD "interne" au programme, et gérée directement par celui-ci?

Une BDD est souvent gérée par un serveur, mais ce n'est pas une obligation... Access, par exemple, est une base de données fichier. Le moteur de la base est une DLL que tu peux utiliser à partir de ton programme. Tout comme SQLite.

Maintenant que grâce à toi j'ai la bonne piste, je vais chercher des tutoriaux et des exemples sur Linq to Entities afin de voir ce que ça représente au juste, et comment mettre ça en oeuvre en pratique.

http://pmusso.developpez.com/tutorie.../introduction/

[ddaime]

Une petite remarque, Linq To SQL peu aussi s'appliquer à SQL Server CE 3.5.

[tomlev]

Une petite remarque, Linq To SQL peu aussi s'appliquer à SQL Server CE 3.5.

OK, bon à savoir...
Ce me surprend un peu, parce que Linq to Entities n'est pas supporté par SQL Server CE

[ClaudeBg]

Bonjour,

Bon, je suis en train de lire le tutorial renseigné, et d'autres.

Si j'ai bien compris, avec linq to entities je peux accéder à des bases de données créées (entre autres) par sql server, et ce, de façon plus "abstraite" qu'avec linq to sql, sans devoir faire tourner sql server sur la machine cible, et sans avoir à me préoccuper le la façon dont sont physiquement construites les tables. Tout ça est parfait.

MAIS se pose pour moi le problème que tous ces tutoriaux partent de tables existantes. Or, moi, je pars de rien et je dois construire mes tables (qui sont rudimentaires pour cette application-ci).

Je n'ai rien trouvé qui explique comment faire à partir de mon programme.
Je peux ajouter des enregistrements, mais pas créer la table.
Pire, le tutorial renseigné sur linq to entities (sensé m'épargner l'utilisation de sql server) m'impose comme prérequis... l'utilisation de sql server.

J'ai donc du commencer à lire des infos sur sql server, pour construire mes tables, et là, j'apprends que l'installation de sql server ne permet pas de créer ses tables, et qu'il faut télécharger "sql server express manager". Soit encore un logiciel à apprendre.

J'ai le sentiment d'être devant une "usine à gaz", et je commence à trouver les solutions sensées me faciliter la vie, un peu... lourdes.

Tout ça pour mettre en place un fichier clients et un fichier factures: La programmation objet à un coût, et le coût c'est qu'on finit par ne plus faire que de l'apprentissage au lieu de faire du développement.

Franchement, je commence à avoir de la fumée qui me sort par les oreilles et je commence à me demander si le temps perdu en apprentissage d'autant d'outils est vraiment compensé par le temps gagné en rendant les objets abstraits.

En tout cas, pour le type d'applications que je fais d'habitude : je commence à être un peu dérouté, je l'avoue.

Et je retrouve le même problème pour une autre de mes applications. Je dois récupérer des données audio de la carte son. Sous Dos, ça me faisait 3 lignes à écrire. Sous dotnet, me voilà embarqué dans des wrapper pour interfacer du code C++ non managé avec C#, et contraint de me farcir 200 pages de doc sur dshow. Je ne dois pas être l'utilisateur type ciblé par Microsoft, LOL.

Plus on s'éloigne du bas niveau, plus il devient simple de faire des choses compliquées, mais plus il devient difficile de faire des choses simples : créer deux fichiers et faire des recherches dessus, ça me semblait pourtant au départ quelque chose de très élémentaires. Je dois me faire vieux...



Claude

[tomlev]

MAIS se pose pour moi le problème que tous ces tutoriaux partent de tables existantes. Or, moi, je pars de rien et je dois construire mes tables (qui sont rudimentaires pour cette application-ci).

Je n'ai rien trouvé qui explique comment faire à partir de mon programme.
Je peux ajouter des enregistrements, mais pas créer la table.

Ca varie selon le type de BDD que tu utilises, mais il y a quand même une constante : tu peux toujours faire un CREATE TABLE en SQL...

Pire, le tutorial renseigné sur linq to entities (sensé m'épargner l'utilisation de sql server) m'impose comme prérequis... l'utilisation de sql server.

Le tutoriel prend SQL Server par ce qu'il faut bien choisir un SGBD, mais tu peux en utiliser un autre... (SQLite par exemple)
Par contre je réalise que j'ai dit une bêtise quelques posts plus haut : SQL Server Compact ne supporte pas Linq to Entities. Mais il supporte Linq to SQL (d'après ddaime).

Plus on s'éloigne du bas niveau, plus il devient simple de faire des choses compliquées, mais plus il devient difficile de faire des choses simples : créer deux fichiers et faire des recherches dessus, ça me semblait pourtant au départ quelque chose de très élémentaires. Je dois me faire vieux...

Il faut dire que tu ne te facilites pas les choses... Linq c'est très bien, mais ça suppose quand même d'avoir quelques notions sur les bases de données. A la limite, il vaudrait peut-être mieux pour toi manipuler la BDD d'une façon plus "classique" avec ADO.NET via des requêtes SQL.

Jette un oeil à ces tutoriels :
http://dotnet.developpez.com/articles/ado1/csharp/
http://dotnet.developpez.com/articles/ado2/csharp/