“关系”是什么意思?在“关系数据库”中;对我们来说意味着什么?

发布于 2024-08-10 12:15:42 字数 779 浏览 2 评论 0原文

我知道,关系数据库是一种数据库,其中一个表中的字段链接到其他表中的行,类似这样。

但我不明白这对我作为一个网络开发者来说意味着什么!

据我所知,具有联接和嵌套选择的查询会降低性能(尤其是具有数十个联接的 drupal 样式查询)。更重要的是,对数据库的任何查询都是瓶颈,然后你有很多用户,你必须缓存每个选择请求。

如果缓存每个选择请求,最好缓存简单的请求而不是复杂的请求。您可以缓存“select * from tbl1 where id = 123”和“select * from tbl2 where id = 456”或“select * from tbl1, tbl2 where ...”,但如果您选择第二种方式,您将需要缓存对象的每个组合 - 这并不酷。

好的,现在我们只使用非常简单的查询,例如“select * from tbl1 where id = 123”或“select id from tbl1 order by id limit 0, 30”并缓存它们(或者我们可以只缓存第一种类型的查询,无论如何)。这些查询以及同样简单的 INSERT、DELETE 和 UPDATE 都是我们所需要和使用的!

正如我们所看到的,所有关系逻辑都使用应用程序的主要语言,而不是 SQL。那么,为什么我们需要所有这些相关的东西呢?它们是什么意思? “关系”类型具有哪些其他类型没有但又是必需的?如果我们不使用关系型功能,为什么每个人仍然使用 MySQL 或任何关系型数据库,即使他关心性能?

这种类型的数据库已成为一种标准。为什么?我不知道。除了 GAE 中的之外,我几乎从未听说过有人使用非关系数据库。

我错过了什么吗?

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

But I can't understand what does it mean for me as a web developer!

As I know, a query with joins and nested select can reduce perfomance (especially drupal-style queries with dozens of joins). Even more, any queries to DB are bottlenecks, and then you have lots of users you have to cache every select request.

If you cache every select request, it's better to cache simple requests rather than complicated. 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 way, you'll need to cache every combination of objects - it isn't cool.

Ok, now we use only very simple queries like "select * from tbl1 where id = 123" of "select id from tbl1 order by id limit 0, 30" and cache them (or we can cache only the first type of queries, whatever). There queries and not less simple INSERT, DELETE and UPDATE are all what we need and all what we use!

As we can see, all the relational logic are in the main language of the application, not in SQL. So, why do we need all this relational things? What do they mean? What do "relational" type has what another types hasn't but it is needed? If we don't use relational features, why do everyone still use MySQL or whatever relational databases, even if he care about the perfomance?

This type of databases has become a standard. Why? I have no clue. I've hardly ever heard about somebody using non-relational database, except for the on in GAE.

Am I missing something?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(7

長街聽風 2024-08-17 12:15:42

如果您想了解关系的含义,我推荐这本书“SQL 和关系理论”,作者:CJ Date。

在这种情况下,关系并不是指的是关系。它指的是关系,这基本上就是数学理论中所谓的表格,导致了关系模型

关系数据库之所以变得普遍,是因为它们是以最小冗余度组织数据的最通用的解决方案。

使用非关系解决方案有充分的理由。他们通常能够很好地解决数据管理的特定任务,但在其他领域却很薄弱。而 SQL 和关系数据库则达成了妥协,可以充分解决更多的问题,同时减少弱点。

下一代”中列出了当前可用的不基于关系模型的其他技术数据库。”

If you want to learn about what relational means, I recommend the book "SQL and Relational Theory" by C. J. Date.

Relational in this context doesn't refer to relationships. It refers to relations which are basically what tables are called in the mathematical theories that led to the relational model.

The reason that relational databases have become ubiquitous is that they are the most general-purpose solution for organizing data with minimum redundancy.

There are valid reasons to use non-relational solutions. They often solve specific tasks of data-management extremely well, but are weak in other areas. Whereas SQL and relational databases strike a compromise, solving a larger set of problems adequately, with fewer areas of weakness.

Other technologies currently available that are not based on the relational model are listed in "The Next-Gen Databases."

不气馁 2024-08-17 12:15:42

我对你的问题感到困惑。您还建议如何跟踪各个表之间的相互关系?

例如,我有一个汽车列表和一个人员列表,我需要连接哪个人拥有每辆车,因此我在人员数据库中有一个 car_ID 列。建议如何跟踪这些关系

此外,您说您想要缓存“所有查询都是瓶颈”,而您只想缓存“简单”查询。但是,我 90% 确信进行多个小型查询比进行多个较小的查询更耗费资源。您也不必缓存每个组合,只需缓存实际存在的组合。在我的示例中,这样的查询有什么问题?

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

I'm confused by your question. How else to you propose you keep track of how various tables relate to each other?

for example, I have a list of cars, and a list of people, and I need to connect which person owns each car, so I have a car_ID column in the person database. How would propose keeping track of these relations

Also, you say that you want to cache 'all queries are bottlenecks' and you only want to cache 'simple' queries. However, I'm 90% sure that making multiple small queries will be more resource intensive than making several smaller queries. you also don't have to cache every combination, only the ones that actually exist. in my example, what's wrong with a query like this?

SELECT person.*, car.* from person left join on car where person.car_ID = car.ID
和我恋爱吧 2024-08-17 12:15:42

由于多种原因,关系数据库已成为事实上的数据库。

  1. 、外部和唯一约束可以在最低级别强制实施某些业务规则,有助于确保数据完整性,并使数据库关系易于任何级别的 IT 专业人员理解。

  2. 正确设计的关系数据库实际上对于许多进程(不是全部)来说在幕后速度更快。

    正确

  3. 关系数据库的查询学起来相当快,而且很容易做。

  4. 关系数据库有助于限制数据重复,从数据工程的角度来看,这是一件很棒的事情。

还有很多其他的,但这些只是少数。

Relational Databases have become the de-facto database for a number of reasons.

  1. Setting up primary, foreign and unique constraints enforces certain business rules at the lowest levels, helps ensure data integrety, and makes the database relationships easily understandable to just about any level of IT professional.

  2. A properly designed relational database is in fact faster behind the scenes for many process (not all).

  3. The querying of relational database is fairly quick to learn, and easy to do.

  4. Relational databases help limit data duplication, and from a data engineering standpoint, that is a wonderful thing.

and many others, but these are a few.

霞映澄塘 2024-08-17 12:15:42

如果不使用关系,则需要将所有内容存储在一个具有大量列的巨大表中。或者你可以使用数据立方体(我认为?)

If you don't use relations, you need to store everything in a giant table with numerous number of columns. Or you can use a datacube (I think?)

怀中猫帐中妖 2024-08-17 12:15:42

它允许您标准化数据并消除冗余。您不是将所有数据存储在一张平面表(如 Excel 电子表格)中,而是将不同的数据存储在单独的表中,然后将它们相互关联。

例如,您可以将用户存储在“用户”表中,将产品存储在“产品”表中,然后使用关系表来关联哪个用户订购了哪些产品。

用户A->产品A

用户A->产品B

用户B->产品A

用户C->产品B

数据标准化,意味着如果数据发生变化,只需要在一处进行更新。如果用户更改其姓名,则只有该用户记录发生更改。如果需要提高产品价格,则仅该产品记录会发生变化。您不必在平面表中搜索以查找要替换的重复数据。

It allows you to normalize your data and remove redanancy. Rather than store all data in a flat table (like an excel spreadsheet), you store disparate data in separate tables and then relate them to one another.

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

UserA -> ProductA

UserA -> ProductB

UserB -> ProductA

UserC -> ProductB

With normalized data, it means if data changes, it only needs to be updated in one place. If a user changes their name, only that user record changes. If a product price needs to be raised, only that product record changes. You don't have to scour your flat table looking for duplicate data to replace.

挽心 2024-08-17 12:15:42

Valya,如果您的应用程序中的数据不会被添加、更新或删除,那么缓存是搜索和显示它的最快方式。我很好奇大家这么着急看到却不会更新的这个数据到底是什么?也许一些细节会有所帮助。
我认识一个人,他用直写式缓存将整个数据库存储在内存中,是的,它飞了起来!他是我所知道的唯一能够实现这一目标的开发人员。也许您需要重新发明火箭发动机,也许您不需要。

Valya, if the data in your application will not be added to, updated or deleted, then a cache is the fastest way to search and display it. I am curious to know what this data is that everyone is in such a hurry to see, but will not be updating? Maybe some details would help.
I know someone who stored his entire database in memory with a write-through cache, and yes, it flew! He is the only developer I know of who could pull this off. Maybe you need to reinvent the rocket engine, and maybe you don't.

酷炫老祖宗 2024-08-17 12:15:42

关系是表的数学词。列彼此相关,否则它们不在同一个表中。

例如,如果两个数字相差 3 的倍数,则它们彼此相关。让我们写下其中的几个:(0,0)、(1,4)、(2,-1) 等。你看出现行的集合,这是一个表。

Relation is the mathematical word for table. Columns are in relation with each other, otherwise they were not in the same table.

For example, two numbers are in relation with each other if they differ a multiple of 3. Let's write a few of them down: (0,0), (1,4), (2,-1), etc. You see a collection of rows appear, which is a table.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文