Pros and cons of Relational Databases
Everywhere you see someone speaking passionately about the advantages of this or that database. The problem is that technology cannot be analyzed without a passion because we need to make sure when and how it will be suitable for us.
Make your WordPress site’s Load Blazing Fast Just by moving to Nestify. Migrate your WooCommerce Store or WordPress Website NOW.
How?
The idea of the RDB is recording the information in the minimal possible in order to avoid redundancy, reduce the risk of inconsistencies and thus reduce the total volume of stored data.
Among the best-known products in this category are SQL Server, MySQL, PostgreSQL, Oracle and IBM DB2.
Read also: MySQL SQL Server x x x MongoDB PostgreSQL: which database to choose?
If you have never seen an RDB, you can imagine it as a collection of small “spreadsheets” that relate to each other. We call these “sheets” of tables. The columns of the spreadsheets are called fields and its lines, those that contain the data, are called records.
Take the example of a simple model of the structure of a database that deals with inventory and sales (i.e., description of the tables and fields involved).
With this structure is not necessary, for example, write the client’s name in the table of invoices (here called tblInvoice). Just only write your code because there is a table that contains all the information about the customer (tblCustomer). As can be seen, these two tables related through the field codCustomer which exists in both.
Strengths
RDBs dominate the market for at least 20 years. This has a number of consequences, among them:
- Mature technology.
- There are products for all “pockets”: There are open source options, the free license, and obviously commercial products.
- There are many qualified professionals: It is easy to find technical information on the internet or even get support in specialized forums.
- It is the technology most widely used in mission critical applications around the world.
- Enjoy fine disk space (because it came at a time when data storage was very expensive).
- There is absolutely no evidence to suggest that the RDBs will not remain on the market for at least another 20 years.
There is so much free information on the internet that is quite likely to find a project template like the one you want to build. Take a look at the site DatabaseAnswers.org. There you will find about a thousand free templates RDB facing the most diverse business areas.
Negative Points
I’m a fan of BDRs, but they have some serious limitations that can cause major problems in some situations.
First, they are not good for storing data with special formats such as GIS data and binary large objects (or BLOBs ), which include all types of file (PDF, XML, XLS, DOC , etc.). Almost all of the RDB have “extensions” that help the relational mechanism to deal with these data, but these solutions generally create a kind of Frankenstein.
But the limitation that I consider most important comes from the fact that the BDRs treat data in a very formal way, specifying the type of data in each field (text, dates, numbers, etc.) and the table position which should get recorded (or is, which field). This results in a series of demands, for example:
Data are not recorded individually but in a set called “registration”.
- The record includes obligatorily all the fields provided in the table;
- Registration necessarily must contain data on the types of appropriate data for each field (if the field is integer, you cannot write letters there);
- Registrations necessarily have to follow the sequence of the fields in the table (if the programmer prefers a different sequence, it obliged to inform what sequence are considering).
These requirements may not seem much, but have a very big impact in the life cycle of an information system. Currently, companies are very dynamic and often the systems need to be changed to reflect new needs.
For the database, these new requirements usually involve creating new tables or new fields in existing tables. Also, applications must also be corrected and the “alignment” between the bank changes and the application needs to get tested. This whole process is time consuming and expensive, two extremely negative features in the IT world and the world of business.
It is quite likely that your application has no major requirements in terms of update frequency. This limitation, however, should not be a problem for you.
Conclusion
You mean RDBs are always the most appropriate solution?
No. It depends on the characteristics of each project.
For more versatile than are the RDBs, there are situations where other options are more appropriate. Among them are NoSQL databases, but that’s a topic for the next article.
Until then!