I am working on a project with a team of 4-5 people. Is it necessary to discuss the database changes with the team before implementing? I am working on the database api's.

Is it better to discuss this or not? In my team are senior people. So can't I make changes myself and implement the change and explain the changes.

  • 3
    Who owns the database schemas?
    – user1249
    Dec 22 '10 at 10:46
  • If you are implemented the database API and the rest of the team is merely implemented code which will rely on your API than frankly I do not think it is needed. However, for the better sake of the team I think it is worth at least touching on for some other insight. You may think your changes are great but someone might have a different thought and teammates like to be included in design decisions.
    – Chris
    Dec 22 '10 at 12:59
  • @Thorbjorn Ravn I owns the schemeas
    – WebDev
    Dec 22 '10 at 16:27
  • @walter thanks for editing , want to improve my grammer
    – WebDev
    Dec 22 '10 at 16:28

Table structure reflects relations between your object. Such changes are quite important and should be discussed.


I dont think this is only related to database changes.

If you are not the Senior Architect or Database Programmer in your team, any changes you make to design & implementation of code or SQL or DB tables or any other artifacts, should be reviewed and approved by other team members - either peers or seniors.

Are you hesitant to do this? Is there no formal review process already in place?


In your case, it depends on what impact the changes have. Are you making a small change like the length of a single VARCHAR2 column or adding new columns to the table which need buy-in from the front-end developers too? In any case, I'd say discussion is better than not doing so - and regretting later

  • I am not hesitant , but i don't want to discuss unnecessarily if not required , as per your answer you are suggesting changes should be reviewed and approved
    – WebDev
    Dec 22 '10 at 10:33
  • @Rahul: It depends on what impact the changes have. Are you changing the length of a single VARCHAR2 column or adding new columns to the table? In any case, I'd say discussion is better than not doing so - and regretting later.
    – JoseK
    Dec 22 '10 at 10:36

I don't think there will be a good general answer. It really depends on whether the work of other team members will be affected by what you do or not (although I tend to think changes of the database structure will affect other code). If the database design and API is solely your responsibility, then the least you should do is INFORM people of changes that may affect them. If you are not sure about the effects, ASK the team members so you will be able to judge the trade-offs and make the best (re)design decision - the team as a whole will benefit from it.

If there are other people being allowed to make changes to the database or share your responsibility there will be a need to COORDINATE everything. You can call this DISCUSSION, but I don't see anything bad in it, unless your team's way to discuss things is perceived as an unjust judgement/criticism of your work. If this is the case I'd understand why you feel uncomfortable with it. But the way to solve this is not to think about what to discuss and what not, but to change the "how" to discuss and to change the team spirit.

  • you understand my questions very much as you write in your second paragraph
    – WebDev
    Dec 22 '10 at 11:08
  • "But the way to solve this is not to think about what to discuss and what not, but to change the "how" to discuss and to change the team spirit. " Please explain this line
    – WebDev
    Dec 22 '10 at 11:09
  • My suggestion then is to discuss with the team that the discussion in itself is a problem, because it seems to focus on creating bad feelings instead of better team results. You can call this a "meta-discussion". Even if some team members don't produce the best code every time, the way it is discussed is not very productive for the team result. A discussion should not focus on past blame, but on future fame :)
    – Ray
    Dec 22 '10 at 11:45

Depends what you mean by "discuss".

If by "discuss" you mean "debate" or "design by committee", I say no. The developer who is the owner of a section of an application gets to say what the schema looks like.

If, instead of "discussing" database changes, you change the database and not let anybody know until their code fails, I say yes, "discussion" is critical.

  • +1 for explaining both negative and positive of discuss >> from now want to design by my self not by commitee
    – WebDev
    Dec 22 '10 at 16:10
  • and want to discuss every design with the team memeber before their code fails
    – WebDev
    Dec 22 '10 at 16:13

As pointed out by others before, its definitely better to discuss. This is especially true in case of database changes. Database, being pretty much the lowest layer, means that any changes to it ( both additions but especially modifications) can potentially have the GREATEST impact to the developers on the team.

A formal review process is a MUST (and preferable this has to be done by the data architect / dba / someone who owns the schema ) but even if that is in place, i would still recommend a discussion with team members about data especially schema changes before hand.

People with a broader technical / domain / application understanding than you might be easily able to point out pitfalls / need / changes to your approach at an earlier stage than a review saving you time and effort (if they are right)


This seems as a design change. This must be done in the design phase. This should get reviewed in the design review.
So my short answer is Yes. Get it reviewed as early as possible. Because if it is not reviewed and someone else has created yet, that person is surely going to get pissed.

  • ...and then there's reality. Not that I disagree with you: it should. But then there's reality.
    – Dan Ray
    Dec 22 '10 at 13:02
  • Edited the response.
    – Manoj R
    Dec 22 '10 at 13:14

Don't you have team meetings? Daily scrums or weekly status get-togethers or anything? This is the kind of thing I'd expect to be raised in these meetings. It doesn't sound like the changes are so significant that they require fair warning, but they're presumably important enough to warrant changes to the API, so people should definitely be informed. Does your team use a wiki? If so, then maybe create a page that lists database changes and the date they were made. Alternately, if you're using a bug reporting system, you could create a "change" or "improvement"-class issue and describe the change there.


iff you own the API and your changes dó not affect others, Then I would consider you to have free hands in doing what is neccesary to dó your job.

A's soon as your changes influence others it becomes a team issue.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.