Server Side Database Standards

1
General Always use InnoDB storage engine. All databases must use UTF8 charset. Naming conventions Tables: All lowercase with underscores Fields: All lowercase with underscores. Put abbreviation or short form as the first word of field. For ex name in user table should have user_name. Index: All lower case with underscores and idx_ prefixed. Keys: All lower case with underscores and fk_ or pk_ prefixed. Create proper foreign key constraints whenever needed. This helps us in building proper integrity. Create index but do not creates too many as it affects inserts and updates. Do not over normalize the tables. It reduces the selects performance. Sometimes keeping redundant data is good. For example: Lets say a table for doctors with their specialty. One way is to have a specialty table and keep the specialty_id id doctors table. I will suggest is to keep the specialty_name also in the doctor table. This will reduce joins as well as we will have an integrity build and we can still do search based on specialty_id. Create stored procedures if you want to use multiple tables and do some small processing. Measures query performances by explaining its plan. Have archive policy on database. This helps us to manage database size and performance. Don't write business logic inside stored procedures.

description

Server Side Database Standards

Transcript of Server Side Database Standards

General Always use InnoDB storage engine. All databases must use UTF8 charset. Naming conventions Tables: All lowercase with underscores Fields: All lowercase with underscores. Put abbreviation or short form as the first word of field. For ex name in user table should have user_name. Index: All lower case with underscores and idx_ prefixed. Keys: All lower case with underscores and fk_ or pk_ prefixed. Create proper foreign key constraints whenever needed. This helps us in building proper integrity. Create index but do not creates too many as it affects inserts and updates. Do not over normalize the tables. It reduces the selects performance. Sometimes keeping redundant data is good. For example: Lets say a table for doctors with their specialty. One way is to have a specialty table and keep the specialty_id id doctors table. I will suggest is to keep the specialty_name also in the doctor table. This will reduce joins as well as we will have an integrity build and we can still do search based on specialty_id. Create stored procedures if you want to use multiple tables and do some small processing. Measures query performances by explaining its plan. Have archive policy on database. This helps us to manage database size and performance. Don't write business logic inside stored procedures.