A practice that I occasionally encounter is having the database to be used by a system entirely “designed” upfront before development starts. This practice implies that the data structure an application requires may be anticipated before the code is developed. Practical experience shows this view to be at best naive.

Attempting to fully anticipate the needs of a system upfront is an exercise in futility. Any business system complex enough to be worth considering as a project will have facets that only become apparent as the system is constructed. Additionally as a development team works with a problem domain they will generally gain additional insight into the nature of the problem and the required solution. Feeding this knowledge back into the system design will result in a more effective solution that will be better suited to the business use. The system will also likely be cheaper to build and maintain as it will more cleanly express the business problems and will not require the kinds of excessive and redundant logic a poorly suited model necessitates.

Attempting to design the database upfront will almost certainly miss key information and produce a sub-optimal representation of the business concern. As this is generally apparent when a developer is required to work with an upfront design I generally see it in two scenarios. The first is when it is requested by a client who believes it to be a necessary or expected process. It is the job of development teams in this scenario to educate clients who cannot and should not be expected to be experts in software development.

I also see it with developers who are unfamiliar with the development of anything but very small systems. I have done this myself when I was a junior developer but this practice is not acceptable in anyone who aspires to be a senior developers. Senior developers must recognise the boundaries of their experience and understand when the knowledge and practices that they apply in the domains they are familiar with no longer apply. In my experience it is significantly more likely to be a problem when developers who only work at small scales attempt to work on larger systems. Larger systems are much less forgiving of loose practices and techniques that are often (wrongly) considered unnecessary at the lower end become mandatory at the higher end.

My preferred approach with databases at this time is to utilise automatic generation capabilities to produce the relevant schema from the application. Any ORM worth using should have such a capability. This approach focuses on the needs of the application and relies on the underlying technology to make it all work. This is efficient in terms of developer productivity. Where relevant it remains possible to optimise for specific cases but this can be done only where necessary.