I really hate it. No, you have no idea. I really despise it….
It’s that crusty, old, smelly, and repugnant idea that everything… and I mean everything…. must be in a database. It’s a profuse nauseating waste of effort and time that just wont die. Don’t get me wrong, databases were great, they had a purpose, filling a gap between COBOL programs (that makes schema changes as easy as mixing oil and water) and well… anything else at the time.
I know, I know, all the other alternatives to-date are either not ‘enterprisey’ enough, or have as much performance association that electric hybrids have to every self-indulgent quadruple billionaire 42 year old looking for their next ultra-performance car. It just doesn’t register, no matter how much faster the electric is compared to a Lamborghini Guirado. It’s that perception that bothers me the most; and it is that perception that causes you to receive a slightly grotesque distortion of your co-workers face when you mention not using SQL and a database to store your data.
All that being said, databases are in your server room. They sit there, stunted, childish, semi-retarded things. But hey, lets admit it, we’re all probably working on a project right now using SQL Server 2005. And given that we were are forced to play with a semi-retarded child that eats sand, maybe we can put a bag over his/her head so we don’t have to pay attention to it.
Microsoft makes a-lot of money selling SQL Server, and they realize we (coders) don’t like it. They have at least made the effort in 2005 to add a new data-type with native XPATH, and with this little bit we can at least tolerate it, or at least not look at it so often. How might you ask?
Well consider you are creating a simple authentication process with your website. You want users to have multi-factored authentication. You know, where you get an ugly, plain, and generic picture that you are supposed to memorize to magically prevent you from being the victim of phishing schemes as well as some random security questions.
If your me, you start with your domain objects (contracts). And you come up with some .NET classes that serialize to some xml.
So now, you’ve got some options:
- Store your data in an in memory object and be done with it.
- Spend the next 2 weeks arguing with a pretentious DBA about a database schema that doesn’t comply with 5th normal form.
So given you are likely here because you can’t choose #1, how do we minimize the impedance-mismatch between our code and the relational database? Answer? Serialize to XML and ‘talk’ to the database using XML.
Going with our XML example (remember generated from XML Serialized C# class). We can use the serialized class and create a stored proc that takes in the serialized XML and maps it to the corresponding relational database. Forget updates, just go with full delete / then update. Example SQL 2005 parsing is shown below.
declare @xml as xml
set @xml = '... string contents of xml file ...'
-- user information
select
doc.value('@Attribute', 'varchar(max)') 'attribute'
, doc.query('Element').value('.', 'varchar(32)') 'Element'
, doc.query('Element/Nested').value('.', 'varchar(32)') 'ElementNested'
, doc.query('data(Element/@Id)').value('.', 'varchar(64)') 'NestedAttributeValue'
from
@xml.nodes('//Root/Items') tbl (doc)
What we are effectively doing is limiting the touch-points between the code and the database. Seperations-of-Concerns says that my objects shouldn’t care about their storage, and that my storage shouldn’t care about my objects. With the above example we would basically have two methods for our data access. Create, and Delete, with Read (Query) being the second part of this exploration and update being a full delete, with a full create.
Next time we can explore a database design, that is both normalized and allows for quick and efficient lookups of information while still allowing for a rich object model that can use the criteria (specification) pattern to deliver rich searching to your application without spreading database concerns throughout your application.
Recent Comments