Exhibit A:

Ugly

Imagine for a second that you're a hotshot designer pitching your new idea to the boss.

You: I have a great new idea that will bring us big numbers!
Boss: Great! Lets hear about it!
You: Instead of cutting corners, lets embrace them! 90 degree angles are really getting popular, just take a look at the Honda Element, and Scion xB.
Boss: I was under the impression people wanted sleek designs which emitted class, style, and sophistication?
You: You're wrong.
Boss: You're clearly a cunning linguist. I'm sold.

I have to admit, there might have been less discussion about these vehicle designs than in my hypothetical (albeit, totally believable) pitch above.  What I kept thinking to myself is how do they make money, who buys these vehicles? Then, in an instant of clarity it all made sense...

Block Head

Yup, block head, of Gumby fame.

These masters of business who pushed forth the Nissan Cube into a anxious society are surely pondering what more they can do for the 2011 model year. More square, more "edgy"... something that would appeal to their existing audience, while breaking through into another segment. Me, always keeping my mind open, and having an entrepreneurial spirit decided to take a few minutes to design such a concept vehicle. Nissan, Honda, Scion... your welcome.

The Picasso Xtreme SS

Lets examine in excruciating detail how awesome this vehicle is. First off, the name is the "Picasso Xtreme SS". It will appeal to artsy folk, MMA fighters, and soccer moms everywhere. The slight angle in the front of this vehicle says "yeah, I can party, I'm just one of the guys". You think Wendy's doesn't cut corners, you haven't seen nothin' yet! Covering half of the rear wheels appeals to the baby boomer's who miss the 70's era vehicles. Tinted windows? You bet!  Need to haul some kids to Chucky Cheese... check out the spacious third row seating! And what vehicle has purple tinted windows? I won't even go into aerodynamics, I think the picture speaks for itself.

Feel free to contact me at any time. My design is, of course, patented, copyrighted, and trademarked.

Prior to jumping into a project, a developer should always lay out the database design plans first. A poorly thought out database design can and will cause headaches in the future. Any developer having to work with a legacy system that has a poorly designed database will surely attest to this.

1. Normalize your design

A database design should be, for the most part, normalized. There are several levels of normalization. Without going into the details of what each level surmises, normalization essentially prevents data duplication (more details in a future post). Normalizing your database will reap its benefits when your database grows. Do not cut corners when building your table structure. Trust me!

2. Naming Convention

Oftentimes when multiple developers are working on the same project, they won't follow the same naming convention. Although SQL is not case sensitive, all developers in a team should be following the same naming convention to keep everything consistent and much more pleasurable to work with. With table names, I personally prefer to capitalize the first letter of every word. Non-alphanumeric characters should be avoided.

3. Use Schemas

As of MS SQL Server 2005, users and schemas are separated. When a table is referenced as dbo.Table, "dbo" is the schema. When developing in .Net this is essentially what namespaces are used for. This allows us to group tables into logical structure, set permissions based on these schema's, and generally organize our database objects easier.

4. Never use *

ColdFusion developers will be all too familiar with this rule. When using * in ColdFusion it will sometimes throw errors because field names are cached, and if a field in the table changes, ColdFusion will still try to access it based off of sed cache, throwing an error. It's good practice to take the time to write the field names out. If you change a field name, or add a field to a table it may cause your program to shat itself (if a table your joining against has that same field name).

5. Always reference objects with the schema

In your queries, you should always have the schema plugged in next to the object name. If you don't, then MS SQL Server does an unnecessary check in the database to see if the object is a built in object, as opposed to something you created.

SELECT field1 FROM dbo.MyTable

opposed to

SELECT field1 FROM MyTable

6. Use stored procedures where applicable

Creating stored procedure caches the query and 9 times out of 10 makes the query run faster in subsequent executions. Another major benefit of using stored procedures is the ability to fix a query without having to recompile code. On the flip-side, don't use stored procedures for EVERYTHING, its easy to get carried away.

7. Consider synonyms when migrating an application

If your given the unenviable task of updating an existing program, consider using synonyms. Synonyms are exactly what they imply, objects that reference other objects. If you have a table named dbo.THISisACrappyNamedTable you can create a synonym for this table, give it a better name, and eventually rename the original table once all references to it are updated.

8. Correctly set the clustered index

There are two types of indexes in MS SQL Server, clustered and unclustered. Clustered indexes are faster, and by default they are created on your primary key fields. If your primary key field isn't what gets hits the most then consider changing it to another field. Use the execution plan in a development environment to test it out and see if you get a performance boost.

9. Join tables correctly

I frequently see developers writing deprecated joins.

SELECT t.field, t2.field
FROM dbo.Table1 t, dbo.Table2 t2
WHERE t.field2 = t2.field2

Joining tables like this is deprecated and should be avoided. Instead, use the proper syntax:

SELECT t.field, t2.field
FROM dbo.Table1 t INNER JOIN dbo.Table2 t2 ON t.field2 = t2.field2

Well, that completes my first programming blog post. I was trying to hit on a bunch of topics, and will probably go more in depth in future posts.

What to expect from my blog? Mostly programming related topics, from Flex Builder 3 to .Net to SQL, but for now, I'm going to pass out.