Rants Tagged with “Databases”
1 2 3 4 5 6 > >> (Total Pages: 6/Total Results: 51)
I like to write blog posts where I offer some pragmatic advice. In most posts I try to include tons of code samples and example projects...but this post is different. I am trying to get my head around something so I want to share what is in my head so I can get a conversation started with my readers to help me out. Once you read this post, please comment...
The other day I was responding to a tweet from Doug Purdy. He had posted a link to some new EF 4.0 features by the boss at Microsoft's DevDiv. I, as usual, complained instead of lauded the list. I started a conversation about lazy loading and the potential danger of it, but quickly Doug mentioned that ORM's maybe were the wrong approach in general. That got me thinking (not always a good idea).
Those of you who have followed me for a long time are apt to remember that I go back to ADO (actually even farther back) to a time when writing your own data access layer was the norm. And using that data access layer against your business objects was what we all did.
Things are really different today as most of us now use an Object Relational Mapper (ORM) of one sort or another. Entity Framework, LINQ to SQL, nHibernate, LLBGenPro, etc. They all essentially do the same thing (but in very different ways). The problem is that to some it feels like ORMs are business objects. In fact, ORMs are just data access. Are they making our jobs easier? It depends...
Most ORMs lean heavily on code generation to create entities and other code. The mapping is generally trying to take some relational model and create an object oriented model. It works this way because this is what we've done for a couple of decades. But is it helpful? Perhaps not. But because we build class-based (or object oriented) software today that seems plausable to do.
Object orientation is at a cross-roads in many ways. We've been told for a couple of decades now that it is the way that you can benefit from reuse, ease of development and modeling. Of course, like all magic pills, applying it to every problem space doesn't help. In the case of ORM's, its always felt like we were putting a round peg into a square box.
Don't get me wrong, mapping a rectagular result (e.g. SELECT * FROM Foo) makes a lot of sense. But the problem is that the mapping happens between *related* entities which is hard. Relationships in data stores are not as simple as 1..n, 1..1, or 0..1. By shaping the relational model into a class structure, we're losing fidelity. You can see if you're losing fidelity when an ORM is going to allow you to get deep inside to hint at the actual queries. At that point we're fighting the tools.
I am not anti-ORM at all and I can clearly see how ORMs help build smaller projects easier. This is especially true if your relational model looks like the object model (or as is common in DDD, using the class model to push down the schema). Great if you're building small projects, but when those same techniques are used on large or enterprise solutions, the stack gets big fast (see right). The problem is that we end up with in-memory classes that represent entities, then we need business objects that apply business rules, then DTOs to communicate the shape of hte data across the wire and in some cases data contract classes outside the firewall. Under the ORM entity objects, the ADO.NET managed providers still exist and sometimes an unmanaged stack too. Sometimes that a lot of code to worry about.
My big worry here is that ORMs are seductive. When you start a project and build a data layer with a couple of clicks you can focus on building the benefit to the business. Like most development issues, the real cost is in the maintenance. I fear that much of the work in this space is done by consultants because typically consultants help get a solution built and move on. Its not that consultants are bad, but because they can go from greenfield to greenfield project (I certainly have been guilty of this before), the pain of maintaining this code isn't always obvious. What happens when the database is overwhelmed with data. What happens when you try to add indexing to an existing application as the use cases change and mean that adding index hints is hard (though in SQL Server 2008 you can do this without modifying the calls).
That comes back to Doug Purdy and other folks in the twitterverse. What's the next wave of solutions out there? I admittedly haven't spent enough time playing with solutions like ActiveRecord, but they feel like dynamic classes which doesn't feel like it will solve the problem. I have heard that maybe getting away from relational databases is the solution, but the object database/non-SQL/BigTable solutions I've seen never seem to scale to high transaction systems or work well with reporting.
Your turn...what's your take?
As many of you who've been following know, I use a simple database of XBox game data as my example database. I usually remember to include it on the server project but in some examples its been forgotten. In other cases I've shipped with a 2008 version of the database instead of the 2005 version. To address this, I've uploaded .zip'd versions of both the 2005 and 2008 databases for anyone to use for any reason. This includes my RIA Services sample (which is using a SQL Server 2008 version) or my MVVM MSDN article sample which also uses a 2008 version. They include a MDF and a LDF. If you have trouble attaching them to an existing database, try deleting the LDF file. Go grab there here:
Any questions/problems, post a comment!
UPDATE: I've confirmed that the NHibernateContext class supports the IUpdateable and IExpandProvider interfaces required by ADO.NET Data Services (I think these are the implementations I added in the NHibernateContrib tree some months back - (See IUpdateable Part 1, Part 2, Part 3 and IExpandProvider posts).
I want to congratulate Ayende (ok, Oren) and the rest of the team on releasing the 1.0 version of the LINQ provider. I am very excited that NHibernate has a full LINQ implementation. I'll be moving my Silverlight + NHibernate examples over in the next few weeks.
(Its not that EF, LINQ2SQL, LLBGenPro aren't all good, its just that choice==freedom)
As regular readers of my blog know (RIA Services Concerns Squashed), I have been a lukewarm supporter of RIA Services for Silverlight. As many of you know, Brad Abrams and company have come through with their latest release (RIA Services Preview July '09) with lots of changes I've been hoping for. Honestly I haven't had time to look at the new build (probably this weekend), but I am hopeful of its overall direction. I am still somewhat tentitive about some of the basic behavior of the framework but I will hold my tongue until I have more time to dive deeper into the code.
What really concerns me is that I've talked to students and others and many are opting to building systems with RIA Services right now. This only concerns me because RIA Services is not part of Silverlight 3 and is not released. Actually, the July version is a "Preview" (something like a CTP) which means they haven't even reached Beta with RIA Services. Now many these developers are working on very long time lines and can wait until RIA Services releases, but while investigating it makes a lot of sense (and I encourage everyone do that), building production code against a framework that is still in transition is a risky venture in my opinion.
I am curious who out there is using RIA Services in production systems that will ship this year. Could you comment on the blog with whether you're using it for an upcoming project?
If you havent voted, please feel free to vote for what data access strategy here:
http://wildermuth.com/2008/03/21/Data_Access_Strategies.aspx
For those who were interested in the results:
One thing that I took away from this is that some strategies did not get any votes (and I expected them to) like CSLA. I think that's a product more of the fact that Rocky's readers probably don't read my blog...so the poll is very unscientific. I was surprised by the sheer number of LINQ for SQL respondents and the big Entity Framework numbers. Both being new technologies, I didn't expect there to be much usage yet. Go figure.
I had interesting conversations with a number of people about different data access/ORM strategies at MIX recently and was trying to understand where people are spending their efforts in consuming data. The conversation was essentially a discussion of who is using what to access data in .NET applications. I had assumed that certain solutions were widely used and others were not but I didn't have a good idea of what the market was really like. To help me with this I am asking you (my readers) to share with me where you are investing time in data access by taking the following poll:
I loves the funny!
Its been a busy weekend for Microsoft. First the announcement that EDM is being delayed six months to be after Orcas...now two new dynamic data access layers for web-based apps:
- Astoria: Expose your data as web services for AJAX
- Jasper: Another RAD solution to Data Access
I haven't looked at either of these *yet*, but I thought it was already confusing...now look a the data access toolbox from MS:
DataSets...LINQ for SQL (Server)...EDM...Astoria...Jasper
I can't imagine that the Data team is going to be able to give good enough advice as to where to use what. Hopefully after I dig in deeper, it'll make more sense.
I was reading this codinghorror.com entry today and thought someone else was advocating Guids as keys when I saw mention of something I hadn't seen before:
NEWSEQUENTIALID() Function in SQL Server 2005
This function (which is only valid in a columns's DEFAULT constraint) will make GUIDs that are somewhat sequential which eliminates the biggest complaint of mine (fragmented PK Indexes). It is SQL Server 2005 only, but its a cool feature. To be clear this is how its used:
CREATE TABLE Employee
(EmployeeID uniqueidentifier DEFAULT NEWSEQUENTIALID())
It looks like Microsoft has cancelled FoxPro 10 and will be open-sourcing the work they've done on it. I worked with it, but that was pre-MS and many many years ago. I feel for the FoxPro MVP's that heard this today.
