This document lays out the policy for adding, deleting or altering any database object, user or configuration. This policy is a necessity to efficiently manage the database schema as we grow.
All schema changes will be performed by the Database Team, unless someone is authorized by a senior member of the Database Team[1].
The policy for schema change requests is different based on whether the database is a development database or a production database.
1.
The
developer will have a meeting with the Database Team and discuss his/her
requirements and the application specifications. The developer should not only
talk about the current needs of the application but also inform the Database
Team of future implications, expectations and requirements. Once the schema
design is agreed on, the Database Team will send email detailing the proposed
schema changes to the developer.
2.
The
developer will be required to provide documentation[2]
for the schema changes. (Schema changes
will not be made unless adequate documentation is supplied)
3.
Upon
receipt of the documentation from the developer the Database Team will provide
the developer with an ETA via email.
4.
Once
the schema changes have been made the Database Team will send email to the
developer informing him/her that the requested changes have been made.
5.
The
developer will then be required to check and verify the changes and inform
the Database Team via email whether the changes are good and don’t need a
review, until and unless the Database Team receives such an email, schema
changes will be considered temporary and will not be propagated to the
production database.
1.
Unless
there is an extreme emergency schema changes
will not be made to the production database unless they have been tested on the
development database.
2.
When
a developer wants a certain set of schema changes to be propagated to the
production database he/she will be required to send email to the Database Team
requesting the change. The email should refer to the changes made on the
development database.
3.
The
Database Team will respond with an email to the developer listing the permanent[3]
changes that their records show.
4.
The
developer will then respond with an email confirming that the listed changes
are indeed the ones he/she requires (this email should be sent at least one
business day before the change is required)
5.
The
Database Team will then email the developer providing him/her with an ETA,
including the Database Change window that this schema change is scheduled to
take place in
6.
The
Database Team will make the change in the scheduled DBC window[4]
7.
The
Database Team will send out an email to the developer upon completion of the
schema changes in production
The
Managers of System Development are responsible for enforcing this policy within
their team, and making sure that all the team members are aware of it. It is
imperative that we adhere to this policy to ensure the proper management of the
databases.
[1] A Senior member of the database team is either System Architect or a Senior DBA
[2] The documentation should have a brief description of each table involved, and a short description for each column in the tables
[3] A change is not considered permanent until and unless the requesting developer confirms the changes on the development database as per Section “Schema Change Requests” sub-section “Development Database”
[4] As per the Production Database Change Policy