Musings of Geekdom by Eric Newton

tail /var/log/thoughts
posts - 88 , comments - 41 , trackbacks - 68

New SQL Server feature I'd like to see...

I'd like to see more namespacing support for tables' names.   If you consider even ASP.Net, we've “munged” namespaces into databases for a while by just prepending the actual name of the table with a namespace.  They tend to be very flat hierarchies also because of name length considerations.  Maybe its time for an additional field (for example in SQL Server) in the sysobjects table for a namespace. 

Tables/views/sprocs within the same namespace by default can reference each other.  Not sure if I'd make it harder for other tables to ref “out of my namespace” tables, but there always needs to be some kind of bridge.

The best example is a commerce database.  A lot of companies “do commerce”... ie, they have a list of products that they sell, manufacture, or deal with in some way.  So we'd all have a OpenSql.Commerce.Products table for instance, fairly generalized.

Next is a feature request for more transparent verticle partitioning.  If I understand the term right, this is analogous to a class-subclass relationship.  In DB terms I'd call it a “1 to 1.”  Now heres the cool part.  I'm Company XYZ, and I need a couple more data points on the Products.  So I create a table called “CompanyXYZ.Commerce.Products | OpenSql.Commerce.Products”  (the bar indicates the 1 to 1-ness). 

I think the combo of these two features might require name aliasing (which is basically the equivalent of scope variables in most languages anyway)

Oh well, Sql 2005 is cool enough with XML datatypes and the partitioning support that they already have.

Print | posted on Wednesday, August 17, 2005 12:24 PM |



# re: New SQL Server feature I'd like to see...

I like that idea. Hell, only a hop, skip, and a jump from table inheritance :-) Talk about increasing complexity! I'd love it, tho.
8/17/2005 12:44 PM | Michael Flanakin

# re: New SQL Server feature I'd like to see...

Agreed, its toeing the line, but there's gotta be a way to leverage all those lookup abilities of SQL with extending table information.

I'd also like to point out that tables should NEVER have any functionality on them. They should continue to be containers of data only, just now with a little more intelligence of relating data in new ways.
8/18/2005 12:40 PM | Eric Newton
Comments have been closed on this topic.

Powered by: