Best way to query a data dictionary in sql [closed]

Answer 1

Have a look at the table syscolumns and related ones. This looks rather like what you describe. But with many years of work Sybase and Microsoft have come up with a way that is probably more efficient than you can come up with.

To make use of this for each different set of columns in a report create a new table an import the data - the database will manage the access for you. You comment on no indicies on these tables - but where do you hold that information in your schema - if you had that data then just as easy to create indices on these SQL tables.

Answer 2

I don't know all your requirements but if you simply have extra dynamic fields, you might want to take a look at XML data type in SQL Server: Implementing XML in SQL Server. This will allow you to write SQL queries against the XML data type.

By the way what you are suggesting is not completely crazy idea. There are many well-known document management systems that used a very similar dynamic schema implementation. To query the data you need to construct a rather complex queries. In your case you simply group records by record id and that you give you all record columns.

Before you go ahead to implement any of that, think twice whether there is a possibility to implement this using a static schema. This will make your life much easier (when implementing but especially when debugging your application). Take a look maybe at Class Table Inheritance or Concrete Table Inheritance (these are static schemas that you can extend using "inheritance" at design time).

Answer 3

I know this does not answer the question but I could not refrain from posting (although I will most likely get down voted). It illustrates the point. Straight from The Daily WTF:

It was my second interview and it opened pretty conversationally.

"We're thinking of storing table names and columns in the database," the interview said, "it's an idea floating around."

I replied, "Instead of creating tables and storing the data depending on how it's structured?"

"Yeah!" his eyes lit up, "then we don't have to define structures or any other mess!"

I wondered it it was some sort of test. "How would you do reports? Would it not be awkward?"

"We could do that from the front end."

"Maybe," I said, "but wouldn't it require a lot of code? And it'd be incredibly slow."

"Not if we used hashtables!"

"Okay... what about data integrity, foreign keys, that sort of thing?"

He was getting more defensive, "it'd be all from the front end."

"I suppose, but this would all require an exorbitant amount of code with all sorts of complex SQL queries. It's not that bad to change a database if you—"

"No," he interrupted, "we would use a data access layer to abstract it to normalized data structures."

"You mean... like tables?"

Two days later, my recruiter told me that they declined me as a candidate because I wasn't technical enough. Though I do wonder if they ever implemented their meta-database implementation, I'm glad I'll never know.

http://thedailywtf.com/Articles/Three-for-Three,-Recursion-Threads,-and-Wrong-Answer.aspx