Just a quick note to let you all know that my brother, Geoff, has begun blogging as well. I gave him a chance to get a few entries up for your reading pleasure, and figured now was a good time to share. Check out his blog here:

Flashback Humor

You may have seen the recent news of over 100 major college representatives calling upon Congress to have the nation's minimum drinking age reduced to less than 21. They're arguing research that shows that the previous increase of of the drinking age has done little to prevent alcohol-related deaths in that age group.

Of course, on the other side is MADD, Mothers Against Drunk Driving, is arguing that these college officials are twisting the data to make it say what they want it to. After all, there would be a signifigant shift in security needs and liabilities for these colleges were the drinking age to be lowered to 18. Then again, would putting alcohol in the hands of younger individuals make things better? It's a debate that comes about as regularly as the legalization of marijuana, and very similarly fails to see the forest for the trees.

The factor that is left out of all these studies is history and exposure to alcohol, as age is not the sole indicator of responsible alcohol consumption. For someone who grew up in a household where one or more parents abused alcohol, it's likely that they will either grow up to abuse it themselves (and follow the examples set before them), or avoid it completely (attempting to avoid the same fate). In these cases, their experience has a polar effect.

Similarly, those who grew up in a household preaching the downfall of alcohol are likely to see this same polar effect. Either they stay the course that they have been taught, or they rebel and take alcohol consumption to it's limits.

However, those who have been exposed to responsible alcohol consumption are more likely to be able to accomplish that feat themselves. Sure, there are exceptions to this, but more often then not they are influenced by the good examples that have been set before them. In my opinion, lowering the drinking age only limits the time parents have to set a good example for their children.

In the end, I believe the only way to positively influence the current trend of irresponsible alcohol consumption in young adults is to teach parents how much they doo have an influence in their kid's lives, no matter what age. It's time for fewer parents to stop going out and getting sloshed with their friends and more to show that they can responsibly have a single glass of wine with dinner. For some, it may be quite the sacrafice. But that's what good parents do to help make their children better people.

After all, if you can't make a sacrafice for the well-being of your own offspring, it may be time to re-think your priorities...

One of the debates during these 2008 Olympics has been over the ages of several members of the Chinese gymnastics team, all in posession passports stating they are the minimum allowed age of 16 (with the ever so discreet birthdate of 1/1/1992...geesh, where'd they learn to make their fake IDs? At least they didn't give them the name McLovin). Ironically, in this highly-censored nation, it was actually a Chinese newspaper that reported team members were as young as 13.

Now, while they are breaking the rules by having underage girls competing when there is a minimum age set (supposedly for the safety and well-being of athletes all over the world), it does all seem a little silly. After all, American swimmer Amanda Beard did win a gold medal and two silvers in her first Olympics in Atlanta at the tender age of 14. What makes a 13-year-old gymnast any less fit to compete than a 14-year-old swimmer?

In my opinion, the spirit of the Olympics is to bring together a collection of the worlds greatest athletes in the sports that are represented. If that person happens to not be able to get into a PG-13 movie by themselves, does that really make them a less deserving athlete? Not in my book, even if it costs the US of A a few medals, and it's time for all the Olympic sports entities to get on the same page.

A few jobs ago, I was taking over as the DBA at a local real estate finance company, and it was my first dedicated DBA position. Prior to that, I had done a combination of application development and database programming. Well, not long after I started, we had one of our developers, who also did some database programming, quit and I had to sit down with him for a "transfer of knowledge".

What I quickly learned was that this developer did not have a grasp on how our MSSQL database server worked. Looking at his code, I began to see a number of nested views in his views called by the application, and I asked him why he used those. He told me "views are pre-compiled in the database, so that makes them run faster", all while the views took 15-45 seconds to pull back their data with nesting as many as four levels deep. The truth is that when you use nested views in 90% of databases, each view needs to execute independently, and only once a nested view has retrieved it's data can the parent view begin processing. However, when I tried to correct this developer, who was about 20 years my elder, he dismissed me as a young programmer who didn't know what he was talking about. Instead of arguing with a guy I probably wouldn't see again after the end of the week, I just let it go and happily went about rewriting his views after he left and getting their execution time to be a fraction of what they had been.

The point of this isn't to brag though, but to educate those who will listen. Nesting views can be a bad idea for a number of reasons:

1. As mentioned above, nested views execute in a cascaded fashion. If you have a large view and nest it in another view to filter it's contents down, it will always take at least as long as the initial view to execute. This is because the parent view doesn't know what data it's working with until the nested view has returned the data.
   
2. Nested views often are written from an Object Oriented perspective, trying to have a base object that can be used in a number of other parent views. However, this often means that the nested view is pulling information that the parent view doesn't need because it is trying to accommodate a number of similar but differing parent views, which just chews up processing time.
3. While using nested views often cleans up the appearance of the code in the view, it makes them more difficult to read because each nested view needs to be opened and evaluated to find the source of the data.
4. Using nested views can become a slippery slope when code changes need to be made as well. Every change you make to a nested view will impact every parent view involved.

While not every database handles nested views in this manner (some sophisticated databases will create optimized execution plans for the view basically just using your code as a guide), the majority of them work this way. And even in the cases that don't work this way, we still have to worry about points 3 & 4, and how changes will impact parent views.

In general, your best bet is to not use nested views, as they are a bad database practice that have consequences that most developers and DBAs do not foresee. Even if it means you have to make the same update to code in multiple views, at least you know exactly what you're impacting with that change.

I just read this great article in Harper's magazine by Jonathan Rowe and wanted to pass it along. It's a great look at the perspective of "the economy" and how the term is often misused and the measure being contraindicative.

If you have a few minutes, I definitely recommend giving this a read:

Our phony economy

Seeing as it's been a few weeks since I wrote anything, I figured I'd let you all know why I haven't been blogging. For the most part, it's because my wife and I are in the process of purchasing our first home, which has been an exciting, exhausting and time-consuming process. It seems like we're meeting with someone, be it an inspector, insurance agent, realtor, financial advisor, mortgage broker, or someone else, almost every-other day. I never realized that it would be so all-consuming.

So with house on the brain, I haven't really been too focused on blogging, which I'm sure you can understand. Until things get settled down, my blogging will probably be a bit sporadic (or is that more sporadic?).

Today's Database Design Principle is based around data movement within the database, specifically when it doesn't need to be done.

The basic problem I came across here was that two identical tables (A and B) were being used, along with a shared key, to manage the status of information inside the database. The application had a web form that could be filled out, saved, and later recalled to be submitted. In order to differentiate between the saved and the submitted data, the saved form fields were stored in table A, with an assumed status of 'ENTRY', while the submitted form fields were being stored in table B, with an assumed status of 'SUBMITTED'. When a saved form was then submitted, the data from table A would be copied to table B, and then the record in table A would be deleted.

While this design was functional, there were some definite drawbacks to the approach:

• Table Maintenance - If a new field were added, or a field deleted from the form, then the same change had to be made in two places in the database.
• Doing With Two Transactions What Could Be Done With One - With this design, the submission of data then requires two transactions: one insert to populate table B, and a delete to remove the save record from table A. If a single table had been used with a status field, then this could have been accomplished with a single update transaction.
  
• Complicating Queries and Views - With the two-table approach, I now have to union together the two tables and calculate a status field to get the full set of data. This just adds a layer of complexity to the database, and it increases exponentially with each time this structure is used. Imagine if you have information in three or more different forms that are stored like this that are linked together and all the extra code that is required to keep things straight.

In this case, the easiest solution, as I implied above, would be to maintain a single table with a status column to no longer make the status implied, but explicit. This not only makes any coding linked to the table much easier, but if you are going to do any reporting or allowing non-developer business analysts access to the tables, it will be much easier for them to read the data.

The lesson here is to keep your tables simple and logically laid out. If you can avoid the hassle of moving your data all over (especially just to maintain implied statuses), you should. It will decrease the amount of work that needs to be done, and will be easier to read for anyone else who joins takes over your project.

Over the past few years, I've done a significant amount of Database Administrator (DBA) work in Oracle, Microsoft SQL and MySQL, and I've seen a lot of different approaches to databases. Needless to say, some have been more successful than others, and some have downright confounded me. While everyone has their own style and approaches, there are just some that are bad and should be avoided.

Hence, I've decided to create a topic on my blog here for Database Design Principles (DDP for short) where I can share the general mistakes I've seen, along with better suggested approaches to the problem. Some of these will be specific to certain database applications, but I plan on keeping things pretty general in order to help as many people as possible.

So keep an eye out for this new intermittent feature here on my blog!

Anyone who is interested in the current economic situation of the United States should take a few minutest to read Too Big to Fail? by Peter Goodman in The New York Times.  It's a very terse look at the current American situation, and some of the questionable things that have been done in an attempt to prop up the declining economy.  While the government is again jumping to bail out poorly run businesses, the article points out that is probably not the best option:

For one thing, this argument goes, taxpayers - who now confront plunging house prices, a drop on Wall Street and soaring costs for food and fuel - will ultimately pay the costs. To finance a bailout, the government can either pull more money from citizens directly, or the Fed can print more money - a step that encourages further inflation.

"They are going to raise the cost of living for every American," said Peter Schiff, president of Euro Pacific Capital Inc., a Connecticut-based brokerage house that focuses on international investments. "The government is debasing the value of our money. Freddie and Fannie need to fail. They are too big to save."

I know I was upset to hear that the government was going to bail out another poorly-run entity.  The biggest problem is that these companies are being saved at the cost of the citizens of this country.  Shouldn't things be happening the other way around?

Well, this week has been a fairly quiet one, as the only semblance of baseball that was played took place an Yankee Stadium. The media is still going on and on about the experience, presumably being paid by the Steinbrenners because I haven't heard a word from anyone else about it. It'll have to do as a send-off though, because it doesn't look like there's going to be much of interest going on at the stadium as the pinstripers are falling further and further behind the Red Sox and Rays in the division.

But now we get back to this crazy and wonderful season where nothing is what you'd expect. Few of the usual candidates are in line for any kind of awards this year, and a number of expected contenders and also-rans have swapped places. With two more weeks until the trade deadline, it looks like things could get a lot more interesting as well.

Most importantly, I'll have to get back to updating my fantasy rosters daily, which is a fun habit to be in!