Databases

There several ways to persist information in any application experience. In most cases, a database is the solution that makes the most sense though several methodologies may be employed simultaneously, particularly when working in a web application development envrionment. Databases, however, are now much more powerful than just simply means to store data on a permenant basis.

I have a strong background in query languages and stored procedure languages, in particular Microsoft SQL Server. Finding and recommending the right database solution for any job has more to do with requirements and scale than cost. Databases can be pretty inexpensive, making a choice that stops before your growth does is costly.

One of the advantages of the smaller database environments like MySQL and MS Access is that there is typically an upgrade path to a larger enterprise solutions. There is always a way to migrate from one to another, but sometimes custom code has to be written to accomplish this…either way, I have done both. Preparing for fortunate growth is an important plan best made early.

Some key operations I can perform that are typically required in any web project, independent of language, are listed below. Keep in mind that some techniques are not necessarily shared across database platforms, though often there are functional similarities between them all.

Design a normalized data architecture using database native or third party tools. Where possible, some third party tools allow forward and reverse engineering of a projects data model which goes a long way in maintaining design integrity and release cohesion.
Build and maintain integrity into the data solution by way of indecies, triggers and constraints at the field and table levels.
Maintain documentation on the more complicated relationships between tables but design for as much simplicity as possible. Often a programmatic solution in the application being designed can be a better solution that some data component.
Larger databases typically to support their own custom programming language to facilitate database server-side functionality, taking the burden off the primary application server...this too can have pros and cons. Well thought out goals lead to well through out solutions. I am familiar with Oracle's PL/SQL and Microsoft's T/SQL.
Generally, Android mobile application rely on SQLite but that does not change any of the aforementioned techniques or notions. The scale may be smaller but design for mobile off-line storage typically mimics "big brother" architecture, particularly when the mobile application relies in SOAP or REST services to get it's data from a website.