September 18, 2008 at 10:36 pm
Comments posted to this topic are about the item The Glue that Binds
September 19, 2008 at 12:22 am
Hi
I've tested linq, and I find that if you want to do something heavier it does not give me the performence that I want. Maybe I didn't write the code the perfect way thou, don't know, but I find that linq is nice for manipulating datasets or lists or other simple and not huge data structures.
I once tried to use linq to join a xml structure with a couple of db tables, it worked, and I was amazed by that, but it was awfully slow to get the result instead of say doing the stupied thing to load the entire db tables into the c# program (to some custom made scructures) and then the xml and then compare it (with linq). This later way was actually faster and that was a bit sad since the joining of an xml structure (huge one) with some db tables could have been kinda neat..
So nah, for me, stored procedures etc is what I like and get best performance by far with. Linq is neat for simple or light data structures thou or when you already have the data in the right memory on the server or computer. However, linq has many possibilities and I've not explored them all by far. If you for instance get a structure of data and want to display it on a say a webpage, and only some data depending on if the user clicks to see all columns or something then it's also cinda neat (all thou an overhead to load too much in the first place).
That's my experience with it this far..
September 19, 2008 at 1:45 am
Hi
I'm just starting to explore the LINQ thingie. Been reading a lot and trying stuff out. I especially like the sqlmetal tool that you can use to create the DAL. Then, by using the concept of partial classes, you can easily extend the functionality if you feel the need. I also have my doubts on performance when using large tables though. Actually I have my doubts on the whole .NET environment being slow (I come from developing in C and I've always been a very critical person). But then again, I'm not a professional developer and only a junior DBA so I'm sure some guru out there knows the tricks to get results blazing fast.
Regards
Thierry
September 19, 2008 at 4:04 am
Remember that this is just the first version of LINQ. Probably the next will be something like it was .NET 2.0 compared to 1.1 - a lot better.
I personally tend to minimize LINQ use for databases for now, but for XML and memory collections is an enormous benefit. We have to wait 1-2 more years probabaly to have a good LINQ for database.
September 19, 2008 at 5:39 am
Tibi V (9/19/2008)
Remember that this is just the first version of LINQ. Probably the next will be something like it was .NET 2.0 compared to 1.1 - a lot better.I personally tend to minimize LINQ use for databases for now, but for XML and memory collections is an enormous benefit. We have to wait 1-2 more years probabaly to have a good LINQ for database.
Tibi nailed the point here on all accounts:
1.) This is the first version, the second should be quite a bit better. (good analogy with the frameworks, btw).
2.) If you use LINQ for stuff that is already in memory, you'll love it ...if you use it to actually grab the data from it's disk store (whatever it may be), you'll probably notice quite a bit of slow.
...and Thierry, .NET is a tad slower than a C/C++ app would be, but the time savings on the development side makes it worth it for most people I know ...and you'd be surprised at how closely a well written C# app can compete with a native code app.
September 19, 2008 at 5:59 am
Based on a meeting earlier this week, a significant part of our developers consider database access the mostly costly and least productive part of their work. They're skipping LINQ and going with nHibernate so that they can not only automatically get data access code without having to write an TSQL, but they'll generate all their own tables and structures as well. If it wasn't for the fact that most of the rest of the developers just don't think it's that big of a deal, I'd be looking for work.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
September 19, 2008 at 6:02 am
Never used LINQ directly but my main concern is how well LINQ will integrate? How LINQ's know how to form an efficient SQL query. I don't think it uses a query plan / cache to use an optimize version of the query like a stored proc can. From my point of view so far, it's not really better than an embedded query in .Net for example.
The time to access a database is very short. Being in both world (dev and sql) most of my time is spent in the dev part. We almost always use classes that do the work for us automatically. Calling a stored proc to filled a dataset is one code line, literally (if you have a proper class to handle data access, see sqlhelper class from Microsoft). Then you loop through the dataset to format data on the screen the way you want.
Generaly our main concern is to keep inline with the 3tiers architecture, maintainability over time, avoiding duplicate code (.Net and SQL to compute same business statistics for example).
What saves us the most time, is the knowledge of using SQL while developing in .Net. The "How will I do this" is not really a concern but mostly "where should the code be to be most efficient with the architecture and rules".
Performance has never been an issue in .Net. I've developed both in C and .Net and the main point is having the right structure. An n2 structure in .Net will out run by far an n3 C structure in the long run. What's matter is the way you handle the data not the language for most applications.
Finally, from my experience and imo the data access is a very small pourcentage of dev time. The presentation and business layer by far take most of our time and I believe this is what business oriented projects should tend to, more business code than "IT" code. So in the end LINQ is not really something we will use in the short / middle run.
September 19, 2008 at 6:18 am
Particularly in a waterfall methoodology, developer time is not that significant; the big chunks are the business and systems analysis, testing and configuration ... and, if you already have a good DAL, data access should be a small part of development.
I've not tried LINQ but it worries me. From what I know, it's constructing individual queries all of which will get cached in 2008. How does LINQ handle stored procedures or do we have to do all the processing at the client side with consequent bandwidth issues?
If I am inexperienced, I suspect that it's a great help in getting something to work quickly but, otherwise, do the benefits outweigh the costs?
... or should I just sign this 'grumpy old man' ??
September 19, 2008 at 7:14 am
As a developer, I think there's three primary reasons we like LINQ:
1) It provides compile-time type checking: If something changes in the database (e.g. rename a field or add a parameter to a stored proc), the compiler will help us find all the places in the software that need to be changed. Techniques that rely on passing strings to a DAL tend to find incompatibilies only at run time. This capability would be better if sqlmetal supported "refreshing" its model from the database, but it still can be made to work.
2) It allows a query to be composed in multiple independent "layers" that match software abstractions. That is, you might have one software layer that knows how to compose a query that will return a set of documents that the current user is allowed to see. You can then pass that (unevaluated) query on to other software layers to compose additional filtering on, say, date ranges or title contents. At the LINQ expression level, you're just building up a parse tree - a specification for the query - until the query is finally enumerated. Only at that point is SQL generated and rows returned from the database.
3) You can build your software in a database-independent manner.
I don't think there's any time savings in writing a LINQ query vs. a TSQL query - they're at the same abstraction level, have the same complexity. One would hope there's a savings during testing.
As far as performance, SQL Server 2005+ essentially auto-parameterizes dynamic SQL and does a pretty efficient job of caching plans for the generated SQL. The LINQ team has published some pretty interesting performance analysis - see Rico Mariani's blog.
It is true that any technology that obscures exactly what query you're running can result in unexpected performance "surprises". Spending the time to learn what LINQ does can help reduce those surprises.
September 19, 2008 at 7:16 am
I've always seen the distinct difference between front end/business app coding and database coding. They really are two separate disciplines, and any SQL against relational data can be hard to get your head around if you've been writing VB/C#-style app code. You can't just join one table to another and get the expected results.
You have to have some sort of DAL/data interface to separate the two worlds, so that app developers just pass a SQL command through the DAL and get back an expected resultset, even if it is just a standard middleware component that gets included in front end code objects with generic data access methods and return values.
I always use stored procedures so I can "publish" the SQL calls the app developer needs. The SP parms represent the database interface the same as any function call in the app code, so for the app developer it makes sense. I can then hide the data structure, T-SQL, etc. from the app developers. I also use an @Method varchar(50) parm in all SPs to receive the function name, so that each one can act like a psuedo-class module. This helps with encapsulation of code without thousands of SPs being created, and more closely ties the database code to the business objects. You can also easily test each call in isolation or in sequence.
I am not using LINQ and have no plans to do so. KISS dictates that you resist doing the latest greatest "cool" thing in favor of simpler, easier to deconstruct/understand/enhance solutions. When I write my app code, I use Visual Studio. When I write my database code, I use Query Analyzer/SSMS. Two worlds, two mindsets, two specialized environments. Easy to keep straight.
J Pratt
September 19, 2008 at 7:23 am
One of the biggest complaints I hear about .NET from developers, friends who used to be developers, and just about anyone who worked in RDBMS's like Visual FoxPro, Access and others - is that .NET takes what used to be Rapid Application Development and turns it into LSPD (Long, slow, painful development). These developers are used to an integrated system (like VFP, Access, etc) where the Development environment has its own data layer and plenty of tools to tap into that. Even backending these now somewhat outdated systems to SQL was easier then, than it has been in .NET. Its a fair complaint, but of course "where goeth Microsoft, we all must follow", and .NET is the future.
I see LINQ as the further bridge of that gap and I agree that as yet, its still a bit early in its lifecycle to place full judgement, but it promises to "heal the wound" left where these older, more truly integrated systems were a bit easier to work with. LINQ holds the promise to make coding a bit more of a 'direct' process when calling for data than it has been thus far, and it also seems to me to be the 'natural next step' in continuing to make the .NET framework as robust as possible.
LINQ is also far more encompassing for today's development technologies than anything these older RDBMS's had to deal with, and in that, those who would poo-poo the .NET world for being overly broad, complex and complicated need to remember that the days of simply coding for PC's is over and gone - never to come back. The Internet, portable devices, and all sorts of new hardware and software technologies means that development tools had to mutate, and generally I think Microsoft has done a reasonably good job with that. LINQ seems the next natural step. I am excited about it as we begin to play with it, but I am also waiting until it matures a bit to see what LINQ will "be" after its been flushed out and enhanced.
September 19, 2008 at 7:30 am
Hello,
i started using linq about 2 weeks ago to develop a web based administrative application.
Before that I was using the typed datasets / stored procedures combo ...
But now Linq is giving me a TREMENDOUS productivity boost and added flexibility.
Performance might be somewhat slower but is not a real problem (I am working with tables having several thousand or several tentousands records). I guess Linq optimization, and SQL server caching the exacution plans, do their job just fine here.
Alexis
September 19, 2008 at 7:49 am
In my experience data access takes only a small portion while most of the time is taken in making the business logic or presentation work. With an established DAL, data access becomes a very straightforward and thus quick job, there is not much testing/QA time spent. On the contrary the business rules need more rigorous design analysis, implementation and testing.
About using nHibernate (or such): I have not used any one personally, only read about a few. My opinion about such frameworks is not very positive. I believe it takes more time for a developer to know and understand them, than it would if s/he had to write the code to access data using simple inhouse/self-made DAL. Besides, such frameworks add more layers between the provider and consumer. Thus they are bound to slow down the job. Same, imo, applies to LINQ. [On similar lines, I remember gettign frustrated using MFC and many times felt that writing plain windows programming might be quicker and easier].
Ultimately its about striking the balance and I stop the pursuit at a home grown DAL.
September 19, 2008 at 7:54 am
Using Linq to SQL for direct table access is something I've just recently started doing, but only in limited respects. Mainly, for now, for constructing queries for a search, i.e. where you don't know ahead of time which where clauses to include in the query. Previously I would've used a stored procedure and passed the user's search terms to it, and within that procedure construct a dynamic SQL string to actually retrieve the results from the database. Now with Linq to SQL I can do all the processing of the search terms in my C# code, dynamically add where clauses as needed, and send the query to the database. From a development standpoint I just find doing work in C# easier than in T-SQL, and in this particular case where I would've had to use dynamic SQL anyway using Linq to SQL for the same task is a no brainer. About the only downside I see is that if I ever want to change how I'm processing the search terms (allow relational comparisons for numbers, etc) I have to recompile my program rather than just edit a stored procedure. But that's not a huge enough advantage for me seeing how simple recompilation is.
I still use stored procedures for anything else that I do because at the very least they allow me to protect the security of the underlying database tables. So most of the time I end up using Linq to SQL as my data access layer.
Viewing 15 posts - 1 through 15 (of 51 total)
You must be logged in to reply to this topic. Login to reply