SELECT * for flexibility


I was having a conversation the other day about software flexibility. Seems a fellow computer nerd was having problems with table changes being propogated down into his business layer causing a lot of work to be done for necessary changes. His solution:
 
SELECT * FROM <TABLE>
 
When you use select *, it does not matter how many changes you make to the underlying tables, you do not break the selection stored procedures.
 
I stopped for a minute to add "what about business objects", but we quickly overcame that objection.When you havethat little pesky situation where your business objects have changed (aka, always) you can code generate those bit.
 
What about binding to the UI? Well, I have thought that one thru (yeah, it is a spelling foh pah, but get over it). Switch all of your data access to DataSets and use the "create columns" binding for your pages. In addition, remove all UI pages and forms that have elements that do not nicely fit into a DataGrid.
 
Here are a couple of other prime architecture ideas (these ones are stolen from other geniuses, but I am going to steal them for my new architecture):
 
1. Combine all of your data needs into a single object you can simply pop on a page.
2. Put all of your columns into an XML snippet. This allows you to flexibly store information, including collections of information. Imagine the User table under this system. Very simple:
 
— SQL Server 2000
CREATE TABLE User
(
   ID int  IDENTITY(1,1) PRIMARY KEY
  , Information text NOT NULL
)
 
— SQL Server 2005
CREATE TABLE User
(
   ID int  IDENTITY(1,1) PRIMARY KEY
  , Information xml NOT NULL
)
 
User has one address, no problem. Thousands of addresses, no problem. And, you do not have to think about this. In addition, with every related table having just two columns, ID and Inforamtion (and possibly a foreign key reference), queries are simplified.
 
SELECT Information FROM User
WHERE ID = @ID
 
What could be simpler?
 
3. Remove all constraints from your database. There are multiple good reasons for this:
a) constraints hinder performance. If your 200 user application was on Google’s radar, those extras milliseconds would kill the sell
b) constraints show a lack of trust in your development staff, who is smart
c) Constraints cause exceptions while developing, which hinders progress as much as the QA department reporting bugs (those bastards)
 
4. Make sure you have configuration files on every level of your application. Every tier needs ultimately flexibility. After all, your next assignment may be with a completely different vertical and you need to be able to take your generic architecture everywhere you go.
 
What I have just described is a new architecture I would like to call Smart, Hybrid Interactive Technology. I will let you put the acroynym together from the first letters. I still have to work out a few particulars, as some of the bits contend with others, but this should be easy by bolting on another idea; I will call this idea of technological incubation Simple Thoughtful Ubiquitous Technological Idea Development. I think you get it, use STUPID and get …
 
See you next time!
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: