The agile method in database design

Introduction

In the past few years, we have applied agile methodologies to database design. We have developed techniques that allow databases to evolve as applications evolve, which is an important attribute of agile methods. Our approach is to work closely with database administrators (DBAs) and application developers through continuous integration and automated refactoring. These techniques are effective at all stages of application development.

1 Agile Methodologies

In recent years, there has been a new methodology for software development-Agile methodology. This puts forward some new and huge demand to the database design. One of the centers of these needs is evolutionary design. In an agile project, it is necessary to assume that we cannot determine the requirements of the system in advance. So the idea of having a detailed design phase at the beginning of a project is unrealistic. The design of the system must evolve with the change of software. Agile methods, especially extreme programming (XP), make this evolutionary design possible through a number of practices. In the database design adopt Agile method, iterative iteration.

Many people wonder whether agile methods can be used in systems with large database components. But we did use a lot of agile and XP techniques to solve the evolutionary and iterative problems of projects based on large databases.

This article will introduce some of the practice of using agile methods in database design. Of course, this is not to say that we have completely solved the problem of database evolution, but we want to provide some effective methods.

2 Positive response to change

One notable feature of agile programming is its attitude toward change.

The general interpretation of the software process is to understand the requirements as early as possible, stop the change in demand, take these requirements as the basis for design, stop the design changes, and then start building the system. This is the waterfall approach--based on the life cycle of the plan.

This approach reduces change through a lot of upfront work. Once the preliminary work is completed, changes in demand can cause a lot of problems. So when demand changes, there is a big problem with this approach, so demand change is a big problem in this process.

Agile programming, however, faces change in a different way. Embrace change and even allow changes in the late stages of project development. Although change can be controlled, this attitude will allow for as many changes as possible. Part of the change comes from the volatility of project demand, partly from the need to support a changing business environment to face competitive pressures.

In order to do so, must adopt a different design attitude. Design is not just a phase--a phase that is most accomplished before the building begins; Design is an ongoing process that is related to coding, testing, and even publishing. This is the difference between planning design and evolutionary design. An important contribution of agile methods is to propose evolutionary design in a controlled manner. So it's not because the design doesn't plan well, it's confusing.

Agile methods provide the skills to control evolutionary design and make it workable. An important feature of the agile approach is iterative development, which runs multiple complete software lifecycle cycles throughout the project lifecycle. The agile process will pass through a complete lifecycle in each iteration. Iterations can complete the requirements of the final product by encoding, testing, and integrating code. Agile methods have shorter iterations, usually between a week and two months, and we tend to have shorter iterations.

When using agile methods, the biggest problem is how the database is designed for evolution. Many people think that database design is the work of the Prophase plan, and later change the database design plan can cause the application crash; changing the database design plan after configuration can cause data migration problems.

Over the past three years we have been involved in a large project that uses a practical approach to evolutionary design. The project, which includes 100 project teams and more than 200 tables, has evolved in 1.5 of its initial development, even in the process of distributing to multiple users. At first we had to iterate one months, and after a few months it was a 2-week iteration.

As we extend these experiences to more and more parts of the project, we gain experience from a growing number of cases. At the same time, we have also absorbed some experience from other agile projects.