Choosing the right database for your company can be a daunting and time-consuming task, particularly for the ill-acquainted.
While it is tempting to implement a system with the mindset of simply ticking a necessary box, it is becoming increasingly important that organisations choose a specialised database for their own requirements.
With this in mind, we sat down with Randal Hoff, VP at database company Faircom, to find out what needs to happen in the decision-making process.
TechRadar Pro: How do you identify the right database for a company's needs?
Randal Hoff: The first step is understanding your business needs and assessing the volume and type of data you are trying to extract, store and analyse.
During this step, it is important to note whether you have data sources that are confined in legacy databases and applications. Sometimes this type of data has been developed using COBOL and other venerable coding languages, which can make the process of extracting it quite difficult.
Nonetheless, understanding the full scope of data that will be included in the project is vital context for business decisions and must be gathered before determining which database – or databases and platforms –is right for your needs.
TRP: Simultaneously, it is also necessary to brainstorm the future needs of the company. How will the database architectures be managed and modified as business needs evolve and need to be maintained?
RH: One critical factor is ensuring support for standard APIs, which are critical to the integration of databases and data stores with other business applications.
Developing support for APIs, particularly when some data stores are locked within legacy applications that do not support modern APIs, can be a daunting task since they may sometimes require modernisation efforts across legacy platforms.
At the same time, there are existing practices that support modernisation without fully replacing legacy applications. There are databases that specialise in bringing legacy data forward with minimal effort and risk, such as c-treeACE by FairCom.
TRP: In what circumstances is it beneficial to integrate both SQL and NoSQL?
RH: Obviously you need the right tool for the right job, but sometimes the simple concept of looking towards the future will make it clear if NoSQL, SQL or the integration of both is right for you.
NoSQL has become a popular architecture for handling large data volumes, because they can be more efficient with regard to the processing power required to handle large files.
At the same time, it's important to consider whether data that will be stored must support immediate data consistency. In addition, you will want to ask yourself - How mission critical is the application and related database?
One issue some enterprises face when working with unstructured big data is that many Open Source NoSQL databases are not Atomicity, Consistency, Isolation and Durability (ACID) compliant, and cannot support real-time persistence. As a result, this lack of ACID compliance can result in data that is out of sync and inconsistent.
Additionally, SQL is typically the go-to language for business intelligence reports and in-depth analytics and SQL may not be easily supported with NoSQL implementations.
While the initial purpose for the data – structured or unstructured – may require a NoSQL solution for performance, that same data set may be needed for more structured analysis and business intelligence reports later, which is where SQL support can be a nice benefit.
Rather than limit the database architectural choice to a NoSQL or SQL database, a more prudent approach may be to consider databases that can support a NoSQL + SQL integration, to keep options open in the future.
Deploying a database architecture that plans for later NoSQL + SQL integration offers engineers more flexibility and control, providing a way to extract, store and manage data using the reduced overhead of NoSQL, but providing the ability to add SQL functionality when needed.
