Rants Tagged with “Databases”
<< < 1 2 3 4 5 > >> (Total Pages: 5/Total Results: 47)
Not sure how I missed this before. I was very impressed by this discussion of the issues around Typed DataSets. Yeah, sure he agrees with most of my opinions...but I like hearing that as well as dissenting opinions.
I was reading this article which is mostly about Oracle's grid database support, but what surprised me was this
link that talks about
Microsoft's partnership to include the CLR in 10g? This i've got to check out.
DevSource has my new article up continuing the discussion of the CLR integration in
SQL Server 2005. Take a look!
I haven't had time to look at this new round of discussions about where DataSets fit into the data world. I am still reformulating my ideas around DataSets after meeting with Microsoft and being told that they did not want to encourage use of DataSets in place of business objects.
I have also been using CSLA.NET at a client and it has some good ideas about entity mapping in general, though it has a number of well documented downsides as well. As Rocky would probably tell you, CSLA has it's place in some architectures but was not meant to fit into all solutions.
My plan is to unveil something new that attempts to address the shortcomings of all the camps (ORM, DataSet, Custom Business Entities), but I am not ready to present it yet. I think we need a good solution for Whidbey and beyond and I don't see that coming out of Redmond (don't get me started on ObjectSpaces ;).
Check out the first part (of 2) where I discuss the basics of writing managed code inside of
SQL Server 2005.
I've been digging deep into SQL Server 2005's CLR integration over the last few days. I am surprised by several specific omissions. My guess is that they have been dropped because of time constraints:
- Server-side cursor in Managed Code (SqlResultSet) is now missing and will probably be MIA in the release.
- Good solution for translating a SqlDataReader's schema into SqlMetaData (which is used with SqlDataRecord to share schema with the client).
- No access to current Transaction. (Used to be part of the SqlContext, but now is missing).
In addition, the current release of the InProc Managed provider has made some interesting choices that are different from earlier version:
- SqlContext no longer gives access to the current connection, but if you create a command object and execute it, it magically is done on the current connection.
- No way to enlist a command to the current transaction.
Its going to be interesting to see where it goes from here. All of these changes are only since the February CTP. I can't imagine it's going to stop here...
Forget everything I told you. It's all changed in the April CTP. I hope to re-give this talk soon in the Atlanta area with the new bits.
After looking over the latest Data Access Block, i'll say it is better. But I still have my gripes:
- They are still calling PrepareCommand with an open connection. Even if you get the parameter out fo the parameter cache, the check with teh Database is still going to happen. I think a code-gen solution (a la Typed DataSets) for Command objects is a good idea (and Whidbey and I both have different ways to handle this).
- There is still no way to update multiple datatables within a single transaction.
- There are still issues with Table/Column Mappings in that they are being obfuscated from teh user therefore they'll never know when they can use them.
It is better in a number of areas though:
- Much better connection management.
- More more generalized away from SQL Server. Complete usage of IDb* interfaces helps, but real database independence is a pipe-dream IMHO.
On the whole though, I'd still recommend not using it and rolling your own DataAccess object with some of these ideas, but not most of them.
I have talked with many people over the last few years about my issues with the the Data Access Block, but it seems I've never enumerated my issues in 'print'. Here they are. If this has been fixed in the EL version the Data Access Block then yippie!
- PrepareCommand is called from many of the helper functions. PrepareCommand causes the connection to be open before the Parameters are adding to the connection. This causes each parameter to be 'checked' with the server causing many unnecessary round-trips.
- Opening connections too early and closing them too late.
- Obfuscates the way the data access works so when there is an issue, the users must dive into levels and levels of overloaded methods to find the private method that is really doing the work.
- Filling DataSets is doing TableMappings but no ColumnMappings. Hiding this detail from developers only delays the learning of this important concept.
- No support for multiple DataTable updates within a single transaction.
I was listening to Jim Gray today about about lots of interesting ideas (listen to the entire two parts for some fun). But in the second part of the discussion, he talked about another coming of the Client-Server vs. 3-Tier war. He seems to really like
SQL Server exposing WebServices directly. He understands the issues very well. After he mentioned WebServices in
SQL Server he directly brings up the DMZ issue with putting
SQL Server out of the web. I think he's right here. C/S is easier, 3 tier is usually easier to scale. As he says, "They're both right."
Later in the conversation, he brings up the difference between WebServices story from Indigo and his view (RPC vs. Document) and his discussions with Don Box about them. It's nice to see that inside MS the right people are talking about both sides of the argument. I still contend that WebServices are about interop, not IPC. That might leave me in the middle of Don and Jim.
Anyone interested in the future of SQL, WebServices and how the TerraServer was built, take a gander at these talks.
