Introduction
Relational databases are now part of most IT project as knowledge is stored in them. I am saying knowledge and not data because, now a days, Object Relational Mappings or ORMs are happening in the majority of IT systems and the relation between multiple business objects make it active linked network of information. Such databases are backbone of any system as they closely work with data generated by users. They are no longer standalone systems as backend.
In the systems, databases work as data managers by storing, updating and retrieving the data for the systems ahead to them. In this task, their efficient working decides the response time of entire system you develop.
So coming to the point, time taken for storing and updating data is little bearable for users however time taken to retrieve the data is matter of concern where the database performance is to be observed. If we hustle in designing database and go ahead, the data accumulated in the database becomes structural and creates bottleneck in the performance throughout the lifetime of the database design for particular system. There can be arguments that using indices, one can make them faster however if you want it the ‘fastest’ i.e. inherently fast, you should consider following dos and don’ts of design principles -
Dos
Always prepare database based on sample data provided by customer - have a memorandum of understanding with client does not share data with third party but for design purpose, actual data makes lot of sense.
Identify ‘entities’ of the business logic and prepare separate master tables for each of them. e.g. Users, Roles, Materials, etc.
Where the second layer of master data is getting generated, keep them separate like
User_Roles.Try to achieve ‘third normal form’ in the design for entire design to balance the space and performance.
In major databases, Primary keys and foreign keys constraints also bear built-in indices. So whenever multiple entities generate a new layer of data like ‘User_Roles’, foreign keys must be used. It is observed that designers are reluctant in implementing foreign keys. Then they get hit by low performance, rework in design and poor validation in every corner of system.
Don’ts:
Never design a query without consideration of indices. Indices inherently cover primary keys and foreign keys. So, secret behind fast queries, is use of primary keys and foreign keys in the joining conditions. e.g. instead of joining conditions like follows -
select A.user_name, B.role_name from users as A inner join roles as B on A.user_name = B.user_name where B.role_name = ‘user’;
Consider following -select A.user_name, B.role_name from users as A inner join roles as B on A.user_id = B.user_id where B.role_name = ‘user’;Never design a table without keys: it is the converse of Dos sereial 5. However, it is always tempting to create a table quickly for business requirements. We must avoid it and should always try to identify keys before implementing a table. Never design database in a hurry.
Never use query without indices for business logic. Whenever queries require conditions that are not related to previously designed keys, use indices. e.g. consider where condition in earlier query -
where B.role_name = ‘user’;Here, firstly, instead of role_name, role_id should be used to avoid indexless operation. Secondly, if at all, you want to use the column, implement an index on the database column.
Never allow anybody else to design your database. It means that you should design your own database as system requirements and business requirements are clear to you. Always design database after having discussion with end user.
Never put business logic in triggers. As far as possible, avoid triggers to implement business logic. It has catastrophic effect on the performance of database. Always use an application layer to clock the business logic. In case application layer is not to be concerned and you find the series of steps can be performed in database without input of further layers, implement the same in stored procedure but not triggers.
Written By: Amey Inamdar
Designation: Project Manager
LinkedIn: https://www.linkedin.com/in/amey-inamdar-43b149120/