Q: What do you call an object oriented database developer?
A: Lost
I’ve been working out with LINQ, Microsoft’s “let’s take databases and turn them into object models” beta product, to be released under .NET 3.0.
In order to use it I had to install the .NET 3.0 extensions for Visual Studio 2005. Now, I usually don’t install beta products on my work machine. But, I was pretty excited by what I saw DevConnections. So I figured, what the hell? Well, now the class diagramming feature of Visual Studio is broken, won’t load. Visual Studio is looking for the old libraries. Oh well.
Let's get over it an move on.
So being hot for LINQ, I decided to do a little demo of the product to my co-workers at the day job, all of whom are database developers. The results were not inspiring. First off, all the DB-heads live in a land of T-SQL, stored procedures and ETLs. These people are mostly about one thing: speed. When you are dealing with multiple databases, each containing data warehouses with transactional data for about six million people, speed and getting the stuff out on time for report consumption is all that really matters. Objects, smobjects.
Pretty much the response from my DB brethren was, “this might be nice if I understood C#, innerfaces, abstract paintings, ah, I mean abstract classes, genetics, oh no wait, it’s generics, isn’t it? and by the way what’s this private, protected and public stuff about?”
“And, hey I imagine in the innards of this stuff there is some SQL. How do I know this is high performance, highly optimized SQL?"
There is little doubt that SQL Server brought a lot more enterprise level database technology to a lot more companies and organizations in a way the Oracle and IBM overlooked or didn’t care to implement. However, Microsoft also has a habit of creating and promoting technologies that look good on the outside for about 5 minutes, but never really catch on due to poor engineering or lack of market acceptance. I mean, MS-Bob may be a distant memory; but at one time it was some MS program manager’s dream of how to get to the top.
So where does this leave LINQ? Well, until they get it to go fast in the real world and have a real cognitive migration path to teach DB developers how to get from T-SQL to .NET, well… I think there is a TV show that describes the situation.
I’ve been working out with LINQ, Microsoft’s “let’s take databases and turn them into object models” beta product, to be released under .NET 3.0.
In order to use it I had to install the .NET 3.0 extensions for Visual Studio 2005. Now, I usually don’t install beta products on my work machine. But, I was pretty excited by what I saw DevConnections. So I figured, what the hell? Well, now the class diagramming feature of Visual Studio is broken, won’t load. Visual Studio is looking for the old libraries. Oh well.
Let's get over it an move on.
So being hot for LINQ, I decided to do a little demo of the product to my co-workers at the day job, all of whom are database developers. The results were not inspiring. First off, all the DB-heads live in a land of T-SQL, stored procedures and ETLs. These people are mostly about one thing: speed. When you are dealing with multiple databases, each containing data warehouses with transactional data for about six million people, speed and getting the stuff out on time for report consumption is all that really matters. Objects, smobjects.
Pretty much the response from my DB brethren was, “this might be nice if I understood C#, innerfaces, abstract paintings, ah, I mean abstract classes, genetics, oh no wait, it’s generics, isn’t it? and by the way what’s this private, protected and public stuff about?”
“And, hey I imagine in the innards of this stuff there is some SQL. How do I know this is high performance, highly optimized SQL?"
There is little doubt that SQL Server brought a lot more enterprise level database technology to a lot more companies and organizations in a way the Oracle and IBM overlooked or didn’t care to implement. However, Microsoft also has a habit of creating and promoting technologies that look good on the outside for about 5 minutes, but never really catch on due to poor engineering or lack of market acceptance. I mean, MS-Bob may be a distant memory; but at one time it was some MS program manager’s dream of how to get to the top.
So where does this leave LINQ? Well, until they get it to go fast in the real world and have a real cognitive migration path to teach DB developers how to get from T-SQL to .NET, well… I think there is a TV show that describes the situation.
posted by Bob Reselman at 8:33 AM
6 Comments:
Um, I've been thinking about something. Maybe you could answer me.
Why use a database? Why not use a sever-side app that handles a datafile?
For example, you could have a host program on the server that waits for another machine to connect to it. You could connect to the host program via any machine over the Internet and exchange data. This would require TCP, like Windows Sockets 2.
Um, I've been thinking about something. Maybe you could answer me.
Why use a database? Why not use a sever-side app that handles a datafile?
For example, you could have a host program on the server that waits for another machine to connect to it. You could connect to the host program via any machine over the Internet and exchange data. This would require TCP, like Windows Sockets 2.
Hate to answer a question with a question, but...
Why use a database for what?
The need sorta dictates how appropriate the method.
Why use a database to store and retrieve simple data like numbers, characters and strings?
I dont even think MySQL can store strings...
Please read:
http://www.htmlite.com/mysql003.php
pay particular attention to varchar and text.
As far as why use a database to store data goes, enterprise level applications typically use databases for data storage. When you are dealing with transactions involving millions of users, databases provide the performance and scalability required. However, the promise of the Provider Model is that any type of data storage can be used as long as you program to the abstract class from which all providers will derive.
So MySQL does store strings. My mistake.
Going back to your original article, I can see why database programmers aren't interested in object oriented database capabilities. They want speed and simplicity.
I just can't see the point in object oriented databases.
Post a Comment
<< Home