Vous êtes pris au milieu d’affrontements entre développeurs et DBA. Comment trouver un terrain d’entente sur les modifications de schéma ?

The info at the left is a perpetuation of what frequently goes wrong with databases. I used to be a front-end Developer and bear no ill will to them but most are simply not qualified to design databases nor schema modifications. And, no... DBAs typically don't just say "No". If they're worth their salt at all, they instead say "No, here's a better way, here's how it will benefit the front, and here's how easy it will make things. Remember, we're all on the same team here. There should be no ego. As Walter E. Deming is quoted as saying, "Without data, you're just another person with an opinion". It's just like index maintenance... everyone says it CAN improve performance. I've never seen anyone prove that it's significant.

I have the greatest respect for developers. As DBA though, I believe that any schema change can impact importantly performance of the database. Developers do deploy in test environment and believe if it works, it will on production. Unfortunately, it is not that simple as databases are usually different in size, data distribution and concurrency. Dba has the experience and understands such issues. Ideally schema changes would go through DBA peer review systematically.

DBAs act probably as quality gates though the decision needs to be made by somebody who is in a better position to evaluate the advantages and disadvantages while looking at the bigger picture (e.g. application architect).

Involve both developers and DBAs in testing schema changes. Developers can create and run tests to ensure functionality, while DBAs focus on performance, security, and integrity. Use a staging environment to pilot the schema changes before they are rolled out to production. Both teams can collaboratively test and refine the changes, ensuring that they meet everyone’s needs. If conflicts persist, consider involving a neutral third party, such as a project manager or an external consultant, to mediate discussions and help find a compromise.

Schema changes have to be viewed from many dimensions 1/ business model 2/ data read write - frequency 3/ storage 4/ accessibility 5/ data integrity 6/ consistency, concurrency etc...just to name a few...along with who the consumers are (apps , reports...api's) before an optimal design is thrown out for review with all teams concerned

Effective communication is crucial in bridging the gap between individuals or teams, including developers and DBAs. When both parties are transparent about their needs and constraints, it fosters mutual understanding. Developers can explain the purpose and benefits of proposed changes, while DBAs can provide insights into potential risks or performance impacts on the database. This open dialogue allows for collaborative problem-solving, leading to more informed decisions that align with both application requirements and database integrity.

Having a change process in place is quite important, though policies, procedures, best practices and processes must be in place to make sure that all parties have a basis for collaboration. Rules must be defined for exceptions, escalation and whatever is needed outside of the standard processes.

Absolutely, by establishing clear guidelines for proposing, reviewing, and implementing changes, both developers and DBAs can work together more effectively. This process should include: Planning: Here developers can propose changes including benefits & impacts. Although most DBAs are not involved in this phase. Review: The DBA team can review the changes and provide their insights. Testing: Both agree to common grounds make changes in lower environments and test it. Documentation: Once the changes are validated they are documented. Implementation with follow-up: These changes are then promoted to production in a controlled manner with minimal impact. A follow-up to ensure the desired effects.

Just functionality testing is not enough. You have to make sure that there is load testing done as well. Usually that is where the issues come up when releasing big changes to production.

Tests should catch all important issues, though they might not be enough. Monitoring should be enforced for the critical points and results should be reviewed periodically. Conversely, the tests should address all range of issues that are important, even if not applicable to certain applications by design.

Version control should be applied to the code developed internally, respectively to the code coming from their parties. Unfortunately, RDBMS and other components from the infrastructure act sometimes like black boxes. One should track at least the most important changes between the versions of such systems.

A version control not only helps us track the changes, but it also helps us ensure a proper rollback procedure is included with the change. There has been significant development in version control tracking in the database world. We now have liquibase, Redgate DB DevOps tools that can standardize the database change deployment.

If you take the time to understand why someone, or a group, is doing or saying something then it will be easier to deal with. You must take the time to understand what is important, and why, to various members of a team.