Let’s say you are a member of the development team. Your team got a new project in the works, so everyone’s excited and and prepping for design and coordinating with other team via lots of project and update meetings for the last few weeks. Everything about the project requirement is already documented, including your requirement for a database server in DEV, UAT and Production environment.
So the DBA reports back and she says, “Everything is fine”. She shares some technical document she prepared about the database server you can use for your project with your team. And you’re like “OK as long as we have a database and we can proceed now”. Do you dare ask “What is that?” and “Whats the backup plan”? and “How secure is this blah blah blah” or do you just accept and let the issues clam up during your development phase?
In any applications development project, it is important that the DBA and the development team discuss the project specifications and database server requirements. This is to avoid wasting time debugging your stored procedures and why you cannot store Chinese characters in your database when should be able to. It is important that the development DBA is made part of the project development team.
The following terms maybe used by your DBA in her technical document and here’s why you should understand what it is about.
1. SQL Server Version or Edition – This is the edition of the SQL Server that you will be using and working on during your development, your UAT or testing and deployment or when your project goes live. Ideally, the SQL Server edition used should be the same across all platforms to eliminate edition and compatibility issues once your project goes live.
2. Logical Drives – You need to know how large is the disk space size. There are times during development and testing that you will come across errors of no more disk space. You need to make sure that capacity planning for IO, and how fast your data will grow for the next 3-5 years is discussed with your DBA.
3. Security – You need to know how the DBA set this up. If you have SQL login accounts that you need for your application then the DBA should set this accordingly and allow SQL login to connect to your database. If the database server has the security settings set to Windows Account Authentication only, then your SQL logins won’t be able to connect to your application.
4. Backup Strategy and Disaster Recovery Plan – This is self explanatory. All database servers must have a backup plan and disaster recovery plan in the event of unplanned downtime. You know as they say, “expect the unexpected”.
5. SQL Server Collation Settings – The SQL Server collation settings determines how the SQL Server will store your data and sorting and when you need to compare value strings. This is also important in your application when you need to store Katakana or Chinese characters in your data. You need to check with your DBA whether you can store these types of characters or if you need your application search engine to be case insensitive or not and other similar scenarios.
6. Connectivity – I mean connection strings. How is your application going to connect to the database? What is the IP address or Host/Server name? Is it via OLEDB or ODBC connections? The default port setting for SQL Server is 1433. Has this been changed to some other value?
There are other numerous settings in SQL Server that you will need to discuss with your DBA. The most important thing is that you specify clearly your requirements and that everything is laid out in the table. Then document these discussions so that expectations and responses are managed.
Then everything will be fine.
Image courtesy of InfusionSoft.