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

The Book Is Out


Let’s flash back to 2001/2002. I was working for Solutech, which is now called Quilogy, when the manager got me in touch with the people at IDG. They wanted someone to write a book called ADO.NET and XML: ASP.NET on the Edge. Never heard of it? It’s okay, neither has most of the civilized world. 🙂
 
There are a couple of major problems with ADO.NET and XML: ASP.NET on the Edge.
  • IDG became Hungry Minds and then sold out to Wiley who were really courting for Dummies.
  • Microsoft constantly changed the technology. Anyone who remembers System.Data.ADO will understand.
  • I was a perfectionist at the time and constantly trying to get everything perfect.
  • Some technical editors do not know what they are teching. Fortunately, after firing a few, we found a wonderful technical editor who helped me get through the maze of book writing.
  • I missed some deadlines. When you miss deadlines, no matter how good the reasons are, the book is late.
What is writing a book on beta technology like? Imagine spending all of your waking hours thinking about a future version of the same tools you use at work. Now, picture the tools constantly changing at the whim of somebody else (most times for good reasons) and having to rewrite your content over and over again. Finally, realize you are not going to get paid much for any of the hours you have spent writing and rewriting your book.
 
The smart authors get things working and release one of the first books, even if the product is still beta. In general, the books are not that great, but they make quite a bit of money. The next group of authors take time to write proper primers, which unfortunately sell very few books. These are fairly decent works, but have low sales figures because they did not get out first. The next step is major mental masturbation where authors spew out their own personal musings on application building as if they were inventing a cure to cancer. Some of these books truly push the envelope, although most end up in the pile of mediocrity.
 
After this first experience, I swore I would never write a book on beta technology … again.
 
So, someone please explain this …
 
 
For anyone planning on writing a book about technology while it is still in beta, here are a few lessons learned…
  1. Co-write – It is much less taxing to update a couple of chapters when the final release. Microsoft WILL change things at the last minute and it is much nicer to have a few hours of sleep before heading in to work.
  2. Write on something that truly is new – This reduces the tedium
  3. Get your chapters in on time – Once you figure out how to do this, email me with the secret. 🙂

In all sincerity, this was a fun project. I am still swearing I will not write on a beta technology ever again, but … damn, what did I just say. Ooh, look, Visual Studio Orcas. 🙂