The subject of database-first design is a point of contention between database administrators and software programmers. While DBAs naturally argue for database-first design, adopting this approach is fraught with pitfalls that will ultimately limit the power and flexibility of the final application.

Database-first design dictates that the entire data schema is designed and documented first, and then the application is designed around this schema. If the schema dictates that there is a Widget table, then the application is usually designed to encapsulate a corresponding Widget object. The Widget object simply moves data around the application where it is needed, and is responsible for the loading and saving of Widget data.

The alternative approach says that the data is just one piece of the overall application structure. A typical application collects input from the user when needed and uses that input to make decisions on what it needs to do. This could include communicating with other applications for additional data or instruction, notify other users or applications of events as it's working, and finally returning results to the user for inspection.

At pre-determined points in the application's workload it will need to persist some or all of the data it is working with. This is where the data persistence piece of the application comes into view, and it is around THIS interraction that the database should be designed. A database should be designed to hold any necessary data along the points that an application determines it needs to persist data. In other words, the database serves the application's need to persist data.

Some applications, such as online ecommerce or data entry programs, will require many persistence points and almost constant communication with its database. Other applications may require little or no persistent points as its work may be kept in memory, saved to disk, or sent across a network to another program. Again it is the application that determines the database needs.

With the introduction of object oriented programming, service oriented architectures, and XML web services, the application domain is where systems interract with other systems and even its human component. Databases have only one purpose - to persist data. They are not capable of carrying on these complex and ever-changing interractions. They simply weren't designed to do so. A database's entire purpose is solely for persisting data when needed.

Designing an appliation around a pre-defined data schema distorts the structure of the appliation and is the major cause of brittle and unflexible applications. Instead of being designed based on these complex interractions, which is what the application layer is intended to do, the application must instead be designed around how and when it works with its data layer. This completely undermines the purpose of having the application layer in the first place.

Decades ago when applications where nothing but the presentation of saved data, database-first design made some sense. But in the current age of largely complex interractions and ever-changing processes, the database must be relegated to doing what it does best - persisting application data how and when the application needs it. Leave the complex business processes and system interractions to the application layer where it was designed to exist, and design your database schema to support those needs - not the other way around.