none
LINQ or SQL? RRS feed

  • Question

  •  

    Hi,

    I have been studying LINQ for a week now and I have to admit, it's nice.  I have been using NHibernate, and now LINQ which has advantages, for instance O/R designer compared to NHibernate tool Hbm2Net, and DataContext to Session object.  There are members of our team who are 'Super DBA' for real.  How can I run this idea by them?  Any ideas, suggestions, readings and/or references would be greatly appreciated.  My thinking is more like how this would effect our performance (query performance), and how less time-cosuming?

     

    Thanks,

    Tuesday, July 15, 2008 8:35 AM

Answers

  • Smile

     

    It really depends - what is your current structure ? Do you put business logic in stored procedures ? Or sprocs are just CRUD (as they should be).

     

    If the first one is not the case, then you don't need any buy in from DBAs - it is all about the mapping of the coming data into meaningful objects. Instead of handcrafting the same code over and over.

     

    create connection, create reader, create parameters, add parameters, determine what changes need to be done, execute necessarry stored procs, retrieve the results and map them into domain objects - all this is a good chunk of a work in db driven systems. And an ORM is there to take this pain from developers.

     

    For Linq to SQL in particular, you can also argue that it is free from Microsoft, it is in production and there is a fair amount of documentation out there in msdn and blogosphere.

     

    Run these by them, and let's see what they'll come up with Smile

     

    Sidar

     

    Tuesday, July 15, 2008 2:02 PM

All replies

  • Has the buy-in already been done to nhibernate, or do you need a buy from DBAs for ORM s rather than linq to sql over classic ADO.NET ?

     

    In any case, Linq to SQL is built on top of ADO.NET and at every point you can use GetCommand() and execute it manually, and you can execute any stored procedure or text based query any time.

    Tuesday, July 15, 2008 1:33 PM
  • NHibernate is an open-source technology.  We are considering LINQ.  You are right, the buy is from DBAs for ORMs.  Any suggestions?

     

    Thanks,

    Tuesday, July 15, 2008 1:50 PM
  • Smile

     

    It really depends - what is your current structure ? Do you put business logic in stored procedures ? Or sprocs are just CRUD (as they should be).

     

    If the first one is not the case, then you don't need any buy in from DBAs - it is all about the mapping of the coming data into meaningful objects. Instead of handcrafting the same code over and over.

     

    create connection, create reader, create parameters, add parameters, determine what changes need to be done, execute necessarry stored procs, retrieve the results and map them into domain objects - all this is a good chunk of a work in db driven systems. And an ORM is there to take this pain from developers.

     

    For Linq to SQL in particular, you can also argue that it is free from Microsoft, it is in production and there is a fair amount of documentation out there in msdn and blogosphere.

     

    Run these by them, and let's see what they'll come up with Smile

     

    Sidar

     

    Tuesday, July 15, 2008 2:02 PM
  • Indeed, CRUD sprocs are defined to retrieve data which is loaded into an excel file.  Processes, such as SSIS, and DTS are in place to process these requests.  Getting the data and mapping it to objects will give you a picture of your data just as it is in your database.  But wouldn't one would require the "know-how" of not only LINQ, but also SQL, in order to query the objects?  Wouldn't that be taking work from DBAs and increasing it on the developers?  Thanks for your help.

    Wednesday, July 16, 2008 8:35 AM
  • No, they don't need to know sql. They just need to know what they need(which they are already doing), in terms of data and express it in Linq.

     

    Using extension methods in linq is pretty easy and has a very little learning curve.

    Wednesday, July 16, 2008 9:07 AM
  • Extension methods sound good.  Thanks for all your help.  I will set out my opinion.

    Wednesday, July 16, 2008 9:30 AM
  • Every layer needs computing power and will affect the performance.

     

    A DataReader will always be faster than a DataTable (in a dataset) or using Linq.

     

    However Linq is designed to utilize the SQL Database the best possible way. Changes are that a programmer working in the SQL Team at microsft has more knowledge and experience in producing efficient code than most programmers in different roles.

     

    The use of NHibernate or Linq will generaly make cleaner and more readible code. So the perfomance won with for example DataReaders will be lost in updateability, readiblilty and perhaps security.

     

    In my opinion Nhibernate and Linq are both of good use, if the programmers have more experience with nHibernate, why would you change? Linq will not per se have a better performance than nHibernate.

     

    However, I read some topics which are stating that nHibernate is not very suited for big ERP applications...  I cannot speak out of experience to denie or support that.

     

    Linq is not the silver bullit, so why change?

     

    These are my two cents on the subject..

     

    Thursday, July 17, 2008 7:49 AM