I was asked recently what the best way to start learning to code is. It’s an interesting question that I have been asked before. This is something which is so much easier to do today than ever before. Technologies are so easy to use and access and there is a wealth of documentation, tutorials, blogs, and forums and so on. Whatever your poison you should be able to get up and running pretty fast with your first “Hello World” application.

Learning to code and building a solid, robust, scalable app are two different things. The ease of access to technology has driven the recent web start-up wave but often these new companies run into technical problems that seriously impact their chances of success. So, the question is not what the best way to start learning to code is but what the most important area of building a web app is.

For me the answer is the database. Almost all web apps will have a database at their core and its importance should never be under-estimated. Create the underlying database well and you have a fantastic foundation for both the short and long term. Much of the way in which the rest of the application is coded will be dictated by the database structure. Any mistakes you make in your code logic can be fixed later relatively painlessly but get the database structure wrong and changing that can be very painful indeed, especially when you have a few thousand or more users in there.

Equally the database structure can significantly impact on the performance and scalability of your application. I have often been faced with slow running systems only to find that the problem is due to the way the data is being held. The database becomes more and more important as technology abstracts the developer from much of the code plumbing. For example, a number of technologies now offer very visual ways to getting data onto the screen with databound controls such as grids, forms and so on. The developer no longer writes code but just points these controls at the underlying data source.

I cannot tell you here how to structure your own database as it is so dependent on the application you are building however I can offer some basic advice.

Think about the future; consider functionality that you may not have in version 1 of your app but that you may need later. This may impact the way you structure your data and could require additional tables for use later that should be included now. Think about the areas where you may have large numbers of records and how these will affect performance. Think about primary and foreign key relationships in the context of keeping queries simple and indexing data for better performance. Finally, use table and column naming conventions that will make sense 6 months or a year from now and that will work in the context of any objects you create or code you write later.

Get the database right and the rest will follow.