Ok, so it's Friday afternoon - and I don't know about your offices, but it's showing badly here. I thought I'd do a bit of database design investigation for my current client (even though I'm on a .NET contract). Anyway, some quiz questions:
You have to configure several hundred devices with a statically laid out configuration, which has defined elements. Do you:
Given that you've chosen to stick it in a massive xml blob do you:
Given that you've chosen to use ntext, do you:
Head. Wall. Smash. Blood.
Any of you had similar experiences?
It's not Friday afternoon here, yet, but you just put me in the mood.
Yes, lots of similar experiences. My favoritee is the multi-statement table valued user defined functions system. The developers saw how UDFs worked, so they started putting them into the design. They had UDFs. Those UDFs called other UDFs and joined them together to create new structures. These were used with other UDFs combined with calls to sitll other UDFs that made structures that could be consumed by other UDFs. Basically, they built an object oriented data structure using UDFs.
First time I saw it, I said, this won't work. I was dismissed out of hand because, it had been tested. A lot. In dev. With one row per table and one user. So, it was released to production, where there were tens of thousands of rows and hundreds of users. The rest, as they say, is history.
answered Oct 08, 2010 at 06:12 AM
Grant Fritchey ♦♦
answered Oct 08, 2010 at 05:48 AM
Depressingly familiar. I spent some time recently with a database that held call centre-type data (details of caller, type of query, etc) in an XML string. Stored in a SQL Server text field.
Previous DBA said "No, we can't report on this". I took that as a challenge... Didn't take long to get a rudimentary report up & running.
The real problem was that there were about 300 different "call types", each with their own little foibles once you got beyond the basic caller / handler information.
answered Oct 08, 2010 at 05:43 AM