Différence entre ADO.net LINQ et commandes SQL

Bon ben....Bonjour
voila je débute sur MS Visual Studio et MS SQL Server...
Je voulais savoir quel est la meilleur méthode pour interroger la base de donnée (LINQ, SQL..)
J'ai réussi à créer une toute petite BDD... j'ai réussi à faire du DATA BINDING...
Je veut savoir maintenant comment pourrai je faire des Enregistrement , suppression et modification sur les tables.... ainsi que LA JOINTURE ENTRE LES TABLE( par exemple.. une fenetre ou un formulaire avec "la liste des clients".... et si je clique sur un client je pourrai consulter seulement les informations concernant ce dernier "la Fiche de ce client")
Je suis un peu perdu , si quel qu'un pouvais m'aider ou m'orienter....ça serai avec un grand MERCI :)

Citation:

---

Envoyé par ramzichouchan

Je voulais savoir quel est la meilleur méthode pour interroger la base de donnée (LINQ, SQL..)

---

Que préférez vous pour conduire une voiture :
1) être au volant ?
2) mettre un aveugle au volant, vous à l'arrière et vous lui indiquez ce qu'il doit faire en fonction de ce que vous vous voyez ?

Citation:

---

J'ai réussi à créer une toute petite BDD... j'ai réussi à faire du DATA BINDING...
Je veut savoir maintenant comment pourrai je faire des Enregistrement , suppression et modification sur les tables....

---

Utilisez les commandes SQL INSERT, UPDATE, DELETE et MERGE
Au passage une table n'étant pas un fichier il n'y a pas de notion d'ENREGISTREMENT ! On parle de ligne de table...

Citation:

---

ainsi que LA JOINTURE ENTRE LES TABLE( par exemple.. une fenetre ou un formulaire avec "la liste des clients".... et si je clique sur un client je pourrai consulter seulement les informations concernant ce dernier "la Fiche de ce client")
Je suis un peu perdu , si quel qu'un pouvais m'aider ou m'orienter....ça serai avec un grand MERCI :)

---

Faite du SQL ! Toute autre possibilité n'est qu'une pâle abstraction du SQL et rendra les choses plus complexes et moins performantes !

A +

Merci SQLpro, pour votre réponse... ,
donc d'après vous je ne dois faire que du SQL...ni LINQ ni autre chose... OK
jvai suivre ce chemin ^^ ThnkU

Je suis d'accord avec SQLPro, pour re situer le contexte, je viens de reprendre du dev après avec bossé des années dans d'autres domaines (7 ans), mon avis est très loin d'égaler de vrais pros. Ce que j'en pense :
- l'utilisation d'un ORM comme LINQ (Object Relational Mapper -> Mapping objet relationnel -> Créer/mapper une BDD à partir d'objets d'un programme ou vice versa) :
--> la structure d'une BDD peut rapidement devenir très complexe, voire illisible avec plusieurs centaines de tables au lieu d'en contenir 15 à 20

Il me semble qu'il soit parfaitement possible de structurer une base correctement avec un ORM, par contre le développeur doit être rigoureux à faire une modélisation correcte.

Ce que je vois aujourd'hui en milieu professionnel (j'ai obtenu mon BTS en 2008) me parait être une abbération complète des principes de modélisation de base de données, LINQ est tous les autres ORM est un outil pour feignasse qui ne souhaite (ou n'a pas le temps) de travailler la modélisation. Le pire c'est que ces outils ont l'air de devenir une norme à regarder les frameworks web tels que Symfony, Django en Python et j'en passe. Ces outils forcent quasiment le dev à ne plus faire du SQL brut est je vois ça comme une grave erreur.

Bonjour

Je souhaite apporter un bémol aux dires ci-dessus. J'utilise Entity Framework et Linq to Entity avec le langage C# sous Visual Studio dans mes projets actuels. On peut raisonnablement dire qu'il y a deux façons d'aborder leur utilisation : Code First et DataBase First. Dans le premier cas, effectivement, on n'est pas maître du modèle relationnel, mais dans le second oui. C'est d'ailleurs l'approche que j'utilise. En l’occurrence je maîtrise parfaitement les modifications d'architecture de ma base. Entity Framework permet un mapping rapide et correct. Donc dans mon code C# je manipule des objets dans un univers d'objets, c'est beaucoup plus simple et productif.

Pour ce qui est des requêtes de sélection, insertion, mise à jour et suppression c'est une question de bon sens. Les requêtes simples, qui composent 90% de celles que j'effectue, sont parfaitement bien gérées par Linq to Entity. Par contre dès que j'ai des requêtes un peu plus complexe j'écris des procédures stockées ou j'établis des vues que je peux appeler via Linq to Entity.

Pour répondre à SQLPro je dirai plutôt que c'est un choix entre :
- conduire soit même et choisir précisément le chemin
- avoir un chauffeur et lui faire confiance même s'il ne prend pas exactement le chemin voulu du moment qu'il arrive à destination quite à prendre le volant pour les chemins les plus complexes.

Cela dit il me semble essentiel de connaître le SQL et il ne faut pas uniquement se reposer sur un ORM qui a ses limites.

Cordialement