为什么要使用SQL数据库？ [英] Why use SQL database?
问题描述
我不太确定stackoverflow是这样一个一般问题的地方，但让我们试试。
暴露于需要存储应用程序数据在某个地方，我一直使用MySQL或sqlite，只是因为它总是这样做。由于看起来整个世界正在使用这些数据库（大部分是软件产品，框架等等），像我这样的开发者很难开始考虑这是否是一个好的解决方案。
好吧，假设我们在应用程序中有一些面向对象的逻辑，并且对象以某种方式相互关联。我们需要将这个逻辑映射到存储逻辑，因此也需要数据库对象之间的关系。这导致我们使用关系数据库，我确定 - 简单，我们的数据库表行有时需要引用其他表的行。 但是为什么要使用SQL语言与这样的数据库进行交互？
SQL查询是一条短信。我可以理解这是很酷的实际理解它的作用，但不是愚蠢的使用文本表和列名称的部分应用程序的部分之后没有见过的一部分？如果你不得不从头开始写一个数据存储，你从来没有使用过这种解决方案。就个人而言，我将使用一些编译的数据库查询字节码，它们将在客户端应用程序中组装并传递到数据库。并且它肯定会通过id号而不是ascii字符串来命名表和冒号。在更改表结构的情况下，这些字节查询可以根据新的数据库模式重新编译，存储在XML或类似的东西中。
我的想法有什么问题？我有任何理由不让自己写，并改用SQL数据库？
EDIT 为了使我的问题更清楚。大多数答案声称SQL，作为一个文本查询，帮助开发人员更好地了解查询本身和调试更容易。就我个人而言，我还没有看到有人用手写SQL查询了一段时间。我知道的每个人，包括我，都在使用ORM。这种情况下，我们建立一个新的抽象级别隐藏SQL，导致思考，如果我们需要SQL或不。我非常感谢你能给出一些例子，其中没有ORM有意使用SQL，以及为什么。
EDIT2 SQL是一个接口在人和数据库之间。问题是为什么我们必须将它用于应用程序/数据库交互？我仍然要求人类编写/调试SQL的示例。
如果你需要做的是将某些应用程序数据存储在某个地方，那么一个通用的RDBMS甚至SQLite可能是过度的。在一些情况下，将对象序列化并将其写入文件可能更简单。 SQLite的一个优点是，如果你有很多这样的信息，它都包含在一个文件中。缺点是更难读。例如，如果您将数据序列化为YAML，您可以使用任何文本编辑器或shell读取该文件。
使用一些
'编译的db查询'字节码，
将在
客户端应用程序中汇编一次并传递给
数据库。
< blockquote>
这是一些数据库API的工作原理。查看静态SQL和预编译的语句。
有没有理由让我不去
自己写和使用SQL
数据库？
如果你需要很多功能，在某些时候，使用现有的RDMBS从头开始编写自己的数据库。如果你不需要很多功能，一个更简单的解决方案可能更聪明。
数据库产品的重点是避免为每个新程序编写数据库层。是的，现代的RDMBS可能并不总是适合每个项目。这是因为它们被设计为非常通用的，因此在实践中，您将总是获得不需要的附加功能。这并不意味着有更好的定制解决方案。
blockquote>
但为什么要使用SQL语言
与这样的数据库交互？
。
这个问题的答案可以在描述关系模型的原始文件中找到大型共享数据库的数据关系模型，由IBM在1970年发布的EF Codd。本文介绍了现有数据库技术的问题。
使用关系模型，因此像SQL这样的逻辑查询语言的原因是数据独立性。
数据独立性在本文中定义为：
应用程序和终端的独立性活动从数据类型的增长和数据表示的变化。
在关系模型之前，数据库的主导技术被称为网络模型。在这个模型中，程序员不得不知道数据的磁盘结构，并手动遍历树或图形。关系模型允许人们针对独立于磁盘上数据的物理表示的概念或逻辑方案编写查询。逻辑方案与物理模式的这种分离是为什么我们使用关系模型。有关此问题的更多信息，此处是数据库中的一些幻灯片类。在关系模型中，我们使用基于逻辑的查询语言（如SQL）来检索数据。
Codd的文章详细介绍了关系模型的好处。给它读。
SQL是一种查询语言，与研究论文中通常使用的查询语言形成对比，易于输入到计算机中。研究论文通常使用关系代数或关系演算来编写查询。
总而言之，我们使用SQL，因为我们恰巧对数据库使用关系模型。 / strong>
如果你理解关系模型，不难看出为什么SQL是这样的。所以基本上，你需要更深入地研究关系模型和数据库内部，以真正理解我们为什么使用SQL。
SQL是人类
和数据库之间的接口。问题是为什么do
我们必须使用它
应用程序/数据库交互？ I
仍然要求人类的例子
编写/调试SQL。
因为数据库是关系型数据库，它只理解关系查询语言。在内部，它使用关系代数语言来指定查询，然后将其转换为查询计划。因此，我们以我们可以理解的形式（SQL）编写我们的查询，DB采用我们的SQL查询并将其转换为其内部查询语言。然后它接受查询并且尝试找到用于执行查询的查询计划。然后它执行查询计划并返回结果。
在某些时候，我们必须以数据库理解的格式编码我们的查询。数据库只知道如何将SQL转换为其内部表示，这就是为什么在链中的某一点总是存在SQL。这是不能避免的。
当你使用ORM，你只是在SQL上添加一个图层。 SQL仍然存在，它只是隐藏。如果您有一个更高级别的层将您的请求转换为SQL，那么您不需要直接写SQL，这在某些情况下是有益的。有些时候，我们没有这样的层能够做我们需要的查询类型，所以我们必须使用SQL。
I'm not quite sure stackoverflow is a place for such a general question, but let's give it a try.
Being exposed to the need of storing application data somewhere, I've always used MySQL or sqlite, just because it's always done like that. As it seems like the whole world is using these databases (most of all software products, frameworks, etc), it is rather hard for a beginning developer like me to start thinking about whether this is a good solution or not.
Ok, say we have some object-oriented logic in our application, and objects are related to each other somehow. We need to map this logic to the storage logic, so relations between database objects are required too. This leads us to using relational database, and I'm ok with that - to put it simple, our database table rows sometimes will need to have references to other tables' rows. But why use SQL language for interaction with such a database?
SQL query is a text message. I can understand this is cool for actually understanding what it does, but isn't it silly to use text table and column names for a part of application that no one ever seen after deploynment? If you had to write a data storage from scratch, you would have never used this kind of solution. Personally, I would have used some 'compiled db query' bytecode, that would be assembled once inside a client application and passed to the database. And it surely would name tables and colons by id numbers, not ascii-strings. In the case of changes in table structure those byte queries could be recompiled according to new db schema, stored in XML or something like that.
What are the problems of my idea? Is there any reason for me not to write it myself and to use SQL database instead?
EDIT To make my question more clear. Most of answers claim that SQL, being a text query, helps developers better understand the query itself and debug it more easily. Personally, I haven't seen people writing SQL queries by hand for a while. Everyone I know, including me, is using ORM. This situation, in which we build up a new level of abstraction to hide SQL, leads to thinking if we need SQL or not. I would be very grateful if you could give some examples in which SQL is used without ORM purposely, and why.
EDIT2 SQL is an interface between a human and a database. The question is why do we have to use it for application/database interaction? I still ask for examples of human beings writing/debugging SQL.
If all you need to do is store some application data somewhere, then a general purpose RDBMS or even SQLite might be overkill. Serializing your objects and writing them to a file might be simpler in some cases. An advantage to SQLite is that if you have a lot of this kind of information, it is all contained in one file. A disadvantage is that it is more difficult to read it. For example, if you serialize you data to YAML, you can read the file with any text editor or shell.
Personally, I would have used some 'compiled db query' bytecode, that would be assembled once inside a client application and passed to the database.
This is how some database APIs work. Check out static SQL and prepared statements.
Is there any reason for me not to write it myself and to use SQL database instead?
If you need a lot of features, at some point it will be easier to use an existing RDMBS then to write your own database from scratch. If you don't need many features, a simpler solution may be wiser.
The whole point of database products is to avoid writing the database layer for every new program. Yes, a modern RDMBS might not always be a perfect fit for every project. This is because they were designed to be very general, so in practice, you will always get additional features you don't need. That doesn't mean it is better to have a custom solution. The glove doesn't always need to be a perfect fit.
UPDATE:
But why use SQL language for interaction with such a database?
Good question.
The answer to that may be found in the original paper describing the relational model A Relational Model of Data for Large Shared Data Banks, by E. F. Codd, published by IBM in 1970. This paper describes the problems with the existing database technologies of the time, and explains why the relational model is superior.
The reason for using the relational model, and thus a logical query language like SQL, is data independence.
Data independence is defined in the paper as:
"... the independence of application programs and terminal activities from the growth in data types and changes in data representations."
Before the relational model, the dominate technology for databases was referred to as the network model. In this model, the programmer had to know the on-disk structure of the data and traverse the tree or graph manually. The relational model allows one to write a query against the conceptual or logical scheme that is independent of the physical representation of the data on disk. This separation of logical scheme from the physical schema is why we use the relational model. For a more on this issue, here are some slides from a database class. In the relational model, we use logic based query languages like SQL to retrieve data. Codd's paper goes into more detail about the benefits of the relational model. Give it a read.
SQL is a query language that is easy to type into a computer in contrast with the query languages typically used in a research papers. Research papers generally use relation algebra or relational calculus to write queries.
In summary, we use SQL because we happen to use the relational model for our databases.
If you understand the relational model, it is not hard to see why SQL is the way it is. So basically, you need to study the relation model and database internals more in-depth to really understand why we use SQL. It may be a bit of a mystery otherwise.
UPDATE 2:
SQL is an interface between a human and a database. The question is why do we have to use it for application/database interaction? I still ask for examples of human beings writing/debugging SQL.
Because the database is a relational database, it only understands relational query languages. Internally it uses a relational algebra like language for specifying queries which it then turns into a query plan. So, we write our query in a form we can understand (SQL), the DB takes our SQL query and turns it into its internal query language. Then it takes the query and tries to find a "query plan" for executing the query. Then it executes the query plan and returns the result.
At some point, we must encode our query in a format that the database understands. The database only knows how to convert SQL to its internal representation, that is why there is always SQL at some point in the chain. It cannot be avoided.
When you use ORM, your just adding a layer on top of the SQL. The SQL is still there, its just hidden. If you have a higher-level layer for translating your request into SQL, then you don't need to write SQL directly which is beneficial in some cases. Some times we do not have such a layer that is capable of doing the kinds of queries we need, so we must use SQL.
这篇关于为什么要使用SQL数据库？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
