Sign Me Up!
I am joining the battle. It's the Battle Against Lawless Database Design (BALD-D or baldy). Because, after all, enough is enough. I encourage you too to join the battle. Cross your arms, join the battle cry! Enough is enough!
VSTSDBE RC0 Post 2
There is no joy in Mudville. The install of RC0 went smoothly. I was able to create a new server project and deploy it. I was able to reverse engineer AdventureWorks into a new project and deploy that. When I went to create a new compound project, combining the output from the two... deployment failed. I got an arcane error about something in the Microsoft.Data.Schema.SchemaModel.ModelSerializationException erroring out. Useful. So, at this point, the functionality I had in my demo for the PASS Summit isn't working. Yikes. I've got two weeks... no pressure... I posted a note about it over at the MSDN discussion site. If you have a solution, swing by and drop it off.
Great Article on DBA-Developer Conflict
What a great way to phrase the issue. I love the concept of the people-people impedence mismatch. We're going through it pretty regularly where I work. Our developers are convinced that using an ORM tool, in this case nHibernate, they're eliminating all the problems with the database because they're taking complete control of the database through nHibernate. All code will be on their side of the fence, no more messy stored procedures. All data structures will look like their objects, no more having to figure out those silly JOINS. Best of all, by setting all this up, no more messing with those stupid and obnoxious DBA's. Unfortunately, they're still planning on object persistance (don't call it data storage) inside of a SQL Server database... Um, guys, you haven't eliminated a…
Query Fingerprints and Plan Fingerprints
SQL Server 2008 has been released, but the full capabilities of the product are still be discovered. This isn't a case of discovery so much as Microsoft, in the person of Bart Duncan, has shown us something new. Read the article. This is one of the most exciting things I've seen in a long time. It's especially exciting as we see databases becoming less and less manageable through the implementation of tools like nHibernate. As I noted in a previous post, nHibernate will create a lot of execution plans. With the capabilities here, we'll be able to easily and quickly aggregate some of those plans to identify the costly queries coming out of nHibernate without having to resort to 24 hour Profiler monitoring. Great stuff.
Buggy Whips
I just spent two days learning about project management and the Feature Driven Development methodology from Jeff De Luca. He's a fascinating and informative guy. He's actually going to be running a project and mentoring a bunch of people where I work. It's going to be interesting times. I expect to learn a lot. Why buggy whips? What the heck do they have to do with FDD? Nothing, directly. A big part of FDD is the development of business models. These models can, and usually do, directly correlate to objects/classes in code. Because of this, object oriented methods are, not an inherent part of FDD, but certainly easily automated and used by those designing and developing systems in FDD. Buggy whips? I'm getting to it. Mr. De Luca has spent…
nHibernate Recompiles and Execution Plans
One little potential for performance problems that we've seen comes out of how nHibernate generates it's parameratized queries. It limits the length of any parameter to the length of the column, but if the length of that parameter is less than the column, it uses tha smaller length when declaring the variable. This results in a query that looks like this: exec sp_executesql N'INSERT INTO dbo.users (Name, Password, EmailAddress, LastLogon, LogonId) VALUES (@p0, @p1, @p2, @p3, @p4)',N'@p0 nvarchar(8),@p1 nvarchar(6),@p2 nvarchar(12),@p3 datetime,@p4 nvarchar(8)',@p0=N'Ted Cool',@p1=N'abc123',@p2=N'ted@cool.com',@p3='2008-04-29 14:10:44:000',@p4=N'ted_cool' Note the parameter @p4 which is the parameter mapping to the primary key for the little sample table. In this query it's declared as nvarchar( 8 ) because 'ted_cool' is composed of eight characters. But if we changed it to 'ted_coolish': exec sp_executesql N'INSERT INTO dbo.users…
Easy Fix To Problem #1
I did a little bit, and I mean a little bit, of looking through the documentation on nHibernate and located a spot for the schema, actually a couple of spots. It can be added to the Hibernate Mapping definition, which will make it a default for all classes within the definition, and by extension all the tables in the database you connect to. You can also add it to the class definition, specifying a particular schema for a given table. So now the query looks like this: exec sp_executesql N'INSERT INTO dbo.users (Name, Password, EmailAddress, LastLogon, LogonId) VALUES (@p0, @p1, @p2, @p3, @p4)',N'@p0 nvarchar(9),@p1 nvarchar(6),@p2 nvarchar(13),@p3 datetime,@p4 nvarchar(9)',@p0=N'Jane Cool',@p1=N'abc123',@p2=N'jane@cool.com',@p3='2008-04-25 11:11:48:000',@p4=N'jane_cool' On to the data length problem.
nHibernate First Impressions
If I'm going to have to support it, I want to understand it. So, I got going yesterday, installing nHibernate 2.0 and walking through the Quick Start Guide. My C# is a bit rusty, to say the least, but I managed to sqeak by. The Guide is meant for an older version of nHibernate and there have been a few changes made that affect the code displayed. What that means is, I had to do more than simply type up what was presented to me. Which, was actually good because it forced me to do a bit more learning in order to get everything to work. What I found was interesting. I can see why developers like this. It really does let you treat the database as just another object…
LINQ and (by extension) ORM Discussion
Steve Jones' editorial today was questioning the use of LINQ. His focus was on the security aspects. The discussion went past that. This is a bit of circular reference since I posted over there and linked back to my ORM Concerns post below. There are a lot of interesting points being made. Some of it, from a DBA stand-point, is quite repetitive although I'd prefer to think of it as reinforcing. Steve's editorial is worth a read and the discussion is excellent.
ORM Concerns
Object Relational Mapping (ORM) software is a great idea. You can't deny that the mismatch between objects and relational data has to be dealt with. Instead of all the time, money and effort being spent here, why not get a tool that does most of the work for you? But... One direction that this can lead is towards dumb databases. After all, if putting a piece of software between the object & the db makes things easier, how much easier if the db and the object look exactly the same. Ta-da! Even less code to write & maintain. Unfortunately, TANSTAAFL (There Ain't No Such Thing As A Free Lunch) still applies. What you save in initial coding you will pay for in reporting, data cleanup, integrity issues, data integration issues...…