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:** * Create a schema which maps to the relationships within the static configuration and populate the devices from there? * Create an entity-property style table so that you can extend the configuration easily if you need to while retaining the ability to search relatively easily? * Stick it in a massive xml blob **Given that you've chosen to stick it in a massive xml blob do you:** * Put in an XML Namespace, qualifying the schema elements of the xml and then create an xml column that conforms to that namespace? * Put it in an untyped xml column and index it? * Use ntext **Given that you've chosen to use ntext, do you:** * Answer user queries using a view that you've created to pull out the common elements of the xml? * Answer user queries by searching the table for XML fragments using patterns or regular expressions? * Tell users that it's too hard to query the table, so it's not really possible to tell what is configured where? Head. Wall. Smash. Blood. Any of you had similar experiences?
BWA-HA-HA-HA 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.
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.