What does “relational” mean in “relational database” for us?

Question

I know a relational database is a database where the fields in one table are related to the rows in others, something like this.

But I can’t understand what this means for me as a web developer!

As I know, a query with joins and nested choices can reduce performance (especially drupal-style queries with dozens of joins). Moreover, any database queries are bottlenecks, and then you have many users who need to cache each query of their choice.

If you cache every request of your choice, it is better to cache simple requests rather than complex ones. You can either cache "select * from tbl1 where id = 123" and "select * from tbl2 where id = 456", or "select * from tbl1, tbl2 where ...", but if you choose the second method, you need to cache every combination of objects is not cool.

So, now we use only very simple queries, such as "select * from tbl1 where id = 123" "select id from tbl1 order by id limit 0, 30" and cache them (or we can cache only the first type of queries, whatever ) Queries and the equally simple INSERT, DELETE, and UPDATE are all we need and all we use!

As we can see, all relational logic is in the main language of the application, and not in SQL. So why do we need all these relational things? What do they mean? What is a "relational" type, what other type is not, but is it necessary? If we do not use relational functions, why are they still using MySQL or any relational database, even if it cares about performance?

This type of database has become the standard. What for? I have no idea. I almost never heard that someone uses a non-relational database, with the exception of inclusion in GAE.

Did I miss something?

Answer 1

If you want to know what relational tools are, I recommend the book " SQL and Relational Theory " by CJ date.

Relational in this context does not apply to relationships. It refers to relationships , which mainly relate to tables in mathematical theories that led to the relational model .

The reason that relational databases have become ubiquitous is that they are the most versatile solution for organizing data with minimal redundancy.

There are good reasons to use non-relational solutions. They often solve specific data management tasks very well, but are weak in other areas. While SQL and relational databases are compromising, solving a wider range of problems is adequate, with fewer weaknesses.

Other currently available technologies that are not based on the relational model are listed in the Next Generation Databases .

Answer 2

This allows you to normalize your data and remove remapping. Instead of storing all the data in a flat table (for example, Excel spreadsheets), you store disparate data in separate tables, and then relate them to each other.

For example, you can store users in the Users table and Products in the Products table, and then use the relationship table to link which user ordered which products.

UserA → ProductA

UserA → ProductB

UserB → ProductA

UserC → ProductB

With normalized data, this means that if the data changes, they need to be updated only in one place. If a user changes his name, only that user's record is changed. If the price of a product is to be increased, only this product record is changed. You do not need to scour a flat table to find duplicate data.

Answer 3

I am confused by your question. How else do you suggest you keep track of how different tables relate to each other?

For example, I have a list of cars and a list of people, and I need to link who owns each car, so I have the car_ID column in the person’s database. As will offer to track these relationships.

In addition, you say that you want to cache “all requests are bottlenecks,” and you only want to cache “simple” requests. However, I'm 90% sure that creating a few small queries will be more resource intensive than doing a few small queries. you also do not need to cache each combination, only those that actually exist. in my example, what is wrong with such a request?

SELECT person.*, car.* from person left join on car where person.car_ID = car.ID 

Answer 4

Relational databases have become a factual database for a number of reasons.

• Setting primary, external and unique constraints ensures compliance with certain business rules at the lowest levels, helps ensure data integrity and makes relations with the database understandable to almost any level of IT professionals.

• A well-designed relational database is actually faster behind the scenes for many processes (not all).

• Relational database queries are pretty fast to learn and easy to execute.

• Relational databases help limit data duplication, and in terms of data, this is a great thing.

and many others, but few.

Answer 5

If you are not using relationships, you need to store everything in a giant table with lots of columns. Or you can use datacube (I think?)

Answer 6

Valya, if the data in your application is not added, updated or deleted, then the cache is the fastest way to search and display. I am curious to know what kind of data is that everyone is in a hurry to see, but will not be updated? Perhaps some details will help. I know someone who stores their entire database in memory using a write cache, and yes, it flew! He is the only developer I know who can do this. Perhaps you need to reinvent the rocket engine, and perhaps you will not.

Answer 7

Relation is a mathematical word for a table. Columns are connected to each other, otherwise they were not in the same table.

For example, two numbers are related to each other if they differ by a multiple of 3. Let several of them be written: (0,0), (1,4), (2, -1), etc. You see a rowset, which is a table.