being old school, i would prefer my db queries being tightly coupled and efficient and know (mostly) what was going on under the hood.... if MS want to bring hibernate to .net then time to grab my coat...

I've been developing software for years now, and most of the programs I work on have a database back-end. These are mainly located on AS/400 machines, and then also some in MySQL (or similar) and some in simpler databases like Access files.

I also program in about 6 or 7 different languages as I not only write new stuff but also maintain some legacy apps, so it depends on what I'm making and where it has to run. Believe me, SQL is a godsend. Whatever system I'm working on/with, I can always get to the databases in the same way. SQL is a cross-platform standard, fast, simple to learn and powerful.

Now, I had a look at the LINQ samples, and as far as I can tell, for an array with a small amount of numbers in it, it can have it's uses. For querying a database with lots of tables and millions of records? Hah! forget it. Just look at the samples, first you have the "GetProductList()" function which gets ALL your data to your client, and then the piece of LINQ, which looks like some weird sort of iteration construct, gets you the records you need. Who in his right mind thought thàt was a good idea?? Anyway, can we also see what's in the GetProductList() function? Some good old SQL maybe ;-)

No wonder Vista moves like a dead donkey...

Anyway, typical isn't? Replace a standard that can be used anywhere with some one vendor technology. Mmm, now where did we hear that one before?

" - addresses the impedance mismatch between OO programs and a specific relational database, SQL Server. "

As an old electrical/electronics engineer, I'm very familiar with the concept of impedance mismatch, its effect on power transfer between source/destination and its effect on reflections at transmission line junctions. I can even still derive the appropriate equations if I try hard.

Can anyone please define for me the 'impedance' of a program and a database and at least point me to an appropriate article that explains the concepts?

From the article: "For programmers, one of the best resources I've found for getting one's brain around LINQ is the intriguingly labeled 101 LINQ Samples for Visual C# that can be found here. Intriguing, why? Because there are actually 99 samples."

And I thought 101 was binary for 5.

"Application programmers are used to dealing with things such as objects, classes and methods but they are not usually familiar with SQL"

Then they should be sent back to school (or at least forced to read some books) until they are, or simply taken out and shot to free up headcount for competent people.

How is it even possible to avoid being familiar with SQL ? Anyone with a college or university level education in the field will (or ought to) have been through at least one RDBMS module during which they will (ought to ?) have been at least introduced to SQL. If you're hiring people without a formal education - not necessarily a bad thing - then SQL, as an industry standard (of sorts) should be on your training plan for them.

Anyone who isn't familiar with it has no business being anywhere near a database driven app, and as such it's usually an advertised requirement for MIS (and such) developers.

I had always believed that I'd had the misfortune to work with quite a few seriously incompetent people over the years (as well as some truly excellent ones, you know who you are), but I never came across anyone who couldn't speak SQL.

Maybe I've been luckier than I thought ?

It's software written by Smart Technologies for using their interactive whiteboards without it being physically connected to the PC. It is already a registered trademark. I feel a copyright lawsuit coming on...

"However, LINQ to SQL is actually "LINQ to SQL Server". Microsoft will not create LINQ to Oracle or to any other database. Microsoft leaves it to the vendors or the communities to implement those. To this end it is worth mentioning that LINQ is not just "embedded SQL", but is built upon a number of other sound language enhancements." ..... and with that I would agree wholeheartedly, Uffe Seerup. It does though then leave the way open for a lead vendor/community/programmer to implement/develop all the disciplines mentioned above in Accord with all vendors and communities. And that could of course be a Microsoft or a Sovereign Wealth Fund* or even a wealthy philanthropic proxy/anonymous donor because all such Research and Development is always Program and Programmer led as they follow IT Leads.

Spookily enough, I had reason to pen the following earlier this morning, which appears to mirror/parallel the article with some prior art work ......

<<< "After moving ASCII, ASCII sound and the Instant ASCII Camera, this is the first serious step in the direction of three dimensional ASCII which is considered to be the Holly Grail of hackerdom." .... http://www.ljudmila.org/~vuk/ascii/architecture/ ....Hmmmm?

A Shift into Virtualisation, which is surely AIReal/a Real Imaginary State, must surely Present a Portal into any number of other dimensions for Alternate Reality Games Play .... Intellectual Property Placement/Mind Control via Environment Manipulation/Pixellation/Digitisation of Thought4Sight2. Being as we may be/are Beings in the Sum Total of our Thoughts via Sublime Interaction* with that we XXXXPerience in/with/because of/led by ITs Knowledge, that which we can then Imagine to See may very well be that which we receive back as Vision and its stock item, Sight.

Sight being that which we are expected to See because it is a product of previous thoughts realised and Vision being that which is planned to be Seen, in Ideas looking for Realisation/Manufacture/Third Party Positive Reinforcement/Global Support.

That suggest that a Strong Willed Entity Sharing Views/Thoughts for Vision will Create Sight and Sights/Site and Sites for Viewers/all other Beings to XXXXPerience as and in AI Future Reality Programmed 42 Appear Real although Created Virtually by Sheer Presence of Mind Shared for Realisation with Like-Minded Peers.

I will Ponder those Words 42 Improve upon their Sense 42 Simplify the Ease of their Understanding.

*...... Sublime Interaction is somewhat of a misnomer as IT is really a very Conscious HyperRadioProActivity on a very Particular Path .... in local vernacular, a man on a mission and all variations on that theme such as amfM HyperRadioProActivity in AI Mission Magical Mystery Turing where Intelligence Programs Spontaneously Communicate for Continuity [Linked Sequelling?] with a View 42 Create AI Beta Vista for Programming the Universe/Future.

Of that there is No Doubt other than that which is harboured in Others. >>> [*...... and also, on a relative matter discussing similar allied concepts, received for no good reason, one of those demon DAEMON notices .... <<<Hi. This is the qmail-send program at yahoo.com.

I'm afraid I wasn't able to deliver your message to the following addresses.

This is a permanent error; I've given up. Sorry it didn't work out.

<adic@emirates.net.ae>:

213.42.1.75 does not like recipient.

Remote host said: 550 5.1.1 unknown or illegal alias: adic@emirates.net.ae Giving up on 213.42.1.75.>>> ]

It is not the first time that possible/probable Juicy Lucy amfM titbits have been apparently refused electronic passage/TEMPESTuous delivery, No matter though, posterity has IT stored to try, try and try again, if IT be necessary for earthly requirements...... and accurate chronicling of Future Events? SQLs? Oracling?

My humble apologies for the lengthier tome as opposed to a catchy shorter Script, but there is more than just a little to convey.

More anon..... :-) in the Digitised ControlLed Future?

PS Whoever invented RSS Feeding was one SMART Cookie?

Impedance mismatch is not between program and database but between an object oriented construct and its relational equivalent, and vice versa. The idea is that there is an overhead involved in mapping from one to the other that one would like to minimise. Intersystems talk about impedance mismatch a lot (because they're good it at reducing it) so you might want to try their web site.

"Application programmers are used to dealing with things such as objects, classes and methods but they are not usually familiar with SQL - the language used to query relational databases."

I just spent three months attempting to hire a developer and I can tell you that 90% of people that I interviewed didn't have a clue about either! And these were people with, apparently, 5 or more years experience.

From Chris, the AS400 expert:-

"Now, I had a look at the LINQ samples, and as far as I can tell, for an array with a small amount of numbers in it, it can have it's uses. For querying a database with lots of tables and millions of records? Hah! forget it. Just look at the samples, first you have the "GetProductList()" function which gets ALL your data to your client, and then the piece of LINQ, which looks like some weird sort of iteration construct, gets you the records you need. Who in his right mind thought thàt was a good idea?? Anyway, can we also see what's in the GetProductList() function? Some good old SQL maybe ;-)"

Oh for God's sake - they're SAMPLES!!! Add a parameter to the GetProductList() method and it becomes at least a little bit more real-world. No-one is suggesting that they're good examples of how to architect an application, they're just examples of code. Why don't you blame them for not having security checks or logging in the samples as well? The samples aren't the bible, you are expected to adapt them to your own requirements...

Read Uffe's post, above. He covers the technical details very well. You've still got all your SQL, it's still there if you need it including Stored Procedures. Linq to SQL is just a very convenient syntax for querying databases, and it's only a part of what Linq is all about.

I have been doing this SQL stuff for about the length of time that Microsoft have been around.

Sorry people, almost everything out there that is not COBOL or FORTRAN is SQL. Most of the other things that anybody does in software are just pretty/shiny stuff to display or update the contents of a database.

I suspect that SQL will be around, long after Microsoft has become just another entertainment monolith.

Programmers, please just learn SQL - It really is much easier.

So now we can have developers that are clueless about the way that databases work and write really bad queries as a result. Yet another VB from microsoft.

Hi All,

I’ve read a load of posts here in the for/against vein. Some have it right, others are way off mark.

I don’t think it’s the posters fault that they are off mark; I feel it’s more to do with the wording of the article.

First, remember that .Net Framework clients should be detached from the database server. That is, only the data pertinent to the query should appear client side, those results are added to, changed and deleted. Then the client program should post the results back to the server as a whole, never as a row changes, is deleted or added. I think this is called “Disconnected Data”.

With this in mind, you should never get huge amounts of data sent from a server to a client in the first place. Just get what you need. This is where server side views/functions/stored procedures come into their own! I don’t know what they are called in non SQL Server setups.

If you know the DB, it’s far better to have it do all the work server side and return the results to the client, either directly or via a (web) service. The DB admin or the programmer should know how to do this.

I’d argue that a good DB admin with knowledge of how the DB works, and how it’s partitioned and indexed is far better than a client side OO programmer. As long as the programmer can communicate effectively, the DB admin should be able to create SQL that gets the data the programmer wants in the most efficient way.

I don’t see Linq as means of doing that. I see it as allowing the client programmer to query the data he/she has got on the client side. Regardless of weather the data is stored in custom types, xml, datasets or datatables.

That, in itself, is useful to client side programmers, because it allows them process data regardless of the way the data is held.

So, DB admins are still very much in a job!

Also, forget built in tools like the Visual Studio 2005 query builder, it creates crap SQL and reformats it to such an extent that it’s almost unreadable. Use something like Sql Server Management Studio or Sql Server Enterprise Manager to create queries, they leave the formatting alone.

Hopefully, I haven’t added to the confusion here. By the way I’m not a DB admin, I’m closer to client side programming.

Shad.

Linq isn't SQL nor is it an ORM tool. True, Linq statements are tightly coupled to the queried elements (tables in the case of a query against a DB) but the forthcoming Entity Framework for ADO.NET will add that necessary layer of abstraction, divorcing the the application layer entirely from the physical implementation.

"Application programmers are used to dealing with things such as objects, classes and methods but they are not usually familiar with SQL - the language used to query relational databases"

Err... then they are not Application programmers are they? They're bedroom hackers, or ivory tower theorists. Unfortunately there are a lot of them about.

Has anyone tried to hire a Computer Science graduate in the UK recently to become an Applications Programmer? I interviewed 4 CS MSc post-grads (all from Russell Group uni's) a few weeks ago - their lack of knowledge about what's required of real-world programmers left me seriously shocked. One guy had done several "database" courses in his MSc but hadn't come across SQL at all.

It's just a tool, and it's going to sell VS 2008 licenses, so LINQ is already a resounding success from Microsoft's point of view.

SQL is fine, I work with it in the field every day. It's very gratifying to write perfect SQL, tune for performance, and watch your app hum along as users are slamming the database. But I'd say the downfall is how long it takes to derive a proper schema -- do you really have all the corner cases of your application figured out? -- if such a thing is even possible up-front. On top of that, the problems of refactoring.

I know everyone on this site has the SQL standard memorized and has never ever made a design flaw that impacted a production application, but in past situations when I had to rapid-prototype a new app or a new function, database stuff was always the bottleneck on my development time. And well it should be, you might say -- maybe so, I can't tell you for sure.

So where does LINQ fit in? I'm not sure if there's a "killer app" for it, but it should help some people. If I were back in application development land, I could imagine hacking out an Excel or CSV file, writing some LINQ code against that, then doing the grunt work to change my data source to a relational DB when application logic isn't the bottleneck on my development time anymore.

The app "just works" after I change the data source. (Right? No comment...) For stored procedures, hack out a C# function using LINQ to emulate the procedure, then switch over to the actual procedure call when you're ready.

Of course, I'd have in the back of my mind the whole time the way I "really" wanted things to look in the database, along with potential integration issues. Or, you know, I could just design the schema up-front and let LINQ write my queries for me, and tune when a performance bottleneck actually shows up.

Lots and lots of in-house projects limp along just fine with carefully hand-written, yet absolutely terrible SQL. LINQ has to at least be capable of generating absolutely terrible SQL really quickly, thereby freeing up other development time. Not every app is a #10 Oracle-bloated ERP system where a missing clustered index will burn the office down and send your children to jail.

I don't think it's going to be a "Hibernate killer"...I believe for "real" Hibernate apps you're supposed to auto-generate your tables based on your Hibernate XML, thereby buying whole hog into their paradigm. I tried to put Hibernate on top of existing development databases a couple years ago and they certainly didn't make it easy on you back then. The key differentiator is the integration into the whole .NET stack.

And it's not an SQL killer, at all. But it gets us a little closer to the dream of being "data store agnostic" which was, after all, the intention of SQL in the first place. I don't use or support Microsoft's products in any way, but this is one of the things you can get when one company unilaterally controls an entire software stack.