Incorporating extreme programming techniques into SQL Server development

The potential central premise of extreme programming is that two ideas are better than one. Two programmers sit side-by-step, one programming, the other a block by line. The reason for this is obvious, if the person who operates on the keyboard is the driver, then the person next to him is the navigator. None of them are bosses-their status is equal and their roles are complementary. The shocking thing about extreme programming is the technology that actually works.

Due to the return, extreme programming has been in the front-end development circle to gain a foothold. It seems absurd to put two of thousands of developers on a single machine, but it turns out to be the case. In extreme programming, most of the program flaws are killed before they are produced, and when writing low speed code, the optimization occurs, knowledge is exchanged, and team relationships are created.

In my experience, this phenomenon has not penetrated into the development of the database layer. I noticed that in some teams, one person writes the stored procedure, the second person writes the data transmission System (DTS), the third is the system, and the fourth makes a commentary on the interface of the intermediate device. Everyone creates the objects they want in isolation, and almost no code is checked. Perhaps the designer prescribes that Sproc98765 accept certain parameters and return a result, and then the other members of the team correspond to it. In any rigorous development organization, checking code and factorization is an integral part of a project, but for some strange reason they are not extended to the database.

I can't understand this. Perhaps we are blind to the managers and let them think that we have nothing to do with the database. Or the price of our services is so high that accountants are breathing by the cost of factoring and limiting programming each week.

For example, in a database that contains 400 tables and 1,600 stored procedures, what is the probability that every result I get is correct? Even if that happens sometimes, the next time a department or customer needs to know the new columns in a table, I had to go back to countless programs, user-defined functions (UDF), and view-and that only illustrated the changes in the table structure.

If possible, I encourage you to try to solve the problem in SQL Server that is currently facing you by using extreme programming methods. For this approach, options include the latest advances in a complex stored procedure, the factorization of a low speed program again, and the optimization of one view. At least try it and let me know how it is used for you.