Shulou(Shulou.com)06/01 Report--

In the 47 years since the introduction of SQL, it has experienced the birth and demise of many databases, as well as the birth and demise of many data processing methods.

The following is the translation:

47 years ago, two young IBM researchers proposed a new language in the database, a relational language that adheres to the idea that all data can be manipulated declaratively and easily. In the years since Don Chamberlin and Ramond Boyce published SEQUEL: structured English query language, relational model and SQL have been extended and adopted by a large number of technologies, such as OLTP, OLAP, object database, object relational database, and even NoSQL. SQL also inspired the design of query languages for non-relational databases, such as SQL for Object-Database (SQL for object databases), SQL for Object-Relational (SQL for object relational databases), SQL for XML, SQL for Spatial, SQL for Search, SQL for JSON, SQL for Timeseries, SQL for Streams and so on. Each BI tool uses a variety of SQL to interact with data. In fact, SQL is the most successful fourth-generation language. "SQL is a mysterious means that only its own power can surpass it." -- Lukas Eder as Don said recently, SQL is based on relational algebra and aims to more easily achieve the following goals by providing a query language similar to English:

Declarative languages and processes (rather than procedural) enable languages to be combined to help easily write complex queries and relational models developed by Edger F Codd work together although big data tries to extend and replace relational systems for the data warehouse, they try to use the same SQL language. The languages used by Hive, Impala, Drill, and BigSQL are all inspired by SQL, optimizer and MPP execution similar to SQL. They also add new SQL features on a regular basis. All of this happens to every type of data store and model you can think of. The separation of data storage format, data model, and query processing in SQL brings significant benefits. In the 45 years since the introduction of SQL, it has experienced the birth and demise of many databases, as well as the birth and demise of many data processing methods. Some supporters of the NoSQL campaign suggest that SQL and SQL databases cannot die, even unintentionally. But the SQL camp has moved forward, and Don Chamberlin recently said: "when a language is so widely accepted that other languages begin to define themselves as not that language, it has to do very well." On the other hand, the database just turns to No-SQL. Although No-SQL is currently defined as "Not Only SQL", the original idea was not to use SQL and to replace it with other languages and frameworks, such as map-reduce. Ten years later, however, every popular NoSQL database has a SQL variant: such as Couchbase's N1QL Magi Cassandra's CQL,Elastic 's ElasticSearch. You would say, "MongoDB doesn't have SQL." I would say, "squint! you'll see a very simple SQL implementation." By using a simple, somewhat programmatic, special design in MongoDB, some loosely combined queries, optimizations, and many innovations can be done using SQL. Although the relational model is very successful, the database supports a variety of data models: JSON, Graph, XML, Timeseries, Spatial, Wide-column, Columnar, Document, and so on. Most, if not all, databases have their own version of SQL. Such as N1Q1 (SQL for Jason), SQL/XML, SQL from InfluxDB, SQL/Spatial, CQL in Cassandra, and so on, and even NoSQL databases implement SQL and SQL-inspired query languages. Even in the new cool world of "data science", SQL skills are highly recommended. Lukas Eder made this point in his "must-see" conversation. For his conversation, please see the related link. Today, there are more SQL projects related to the NoSQL database than the SQL database.

Why is SQL successful?

Declarative: you just need to declare the output and the query engine will find out the best way to execute the query. Optimizers, especially the cost-based optimizer invented by Pat Selinger et al in 1979, help continuously improve performance. This provides a high standard for every new entrant. A recent paper on Apache Hive is an example of complexity and refinement. Why is SQL so successful?

SQL is used not only for "queries", but also for updating data and performing transactions. Stored procedures, UDF extends access by combining procedural language with declarative SQL. SQL has plasticity. It has been standardized many times, each with a fully functional book, a store full of grammar, and a dictionary full of keywords. Of course, not all SQL are the same. Even traditional SQL implementations on RDBMS are not fully compatible unless you carefully write SQL to make them compatible. Through all this, the original spirit of SQL is preserved. An evolutionary example of SQL is SQL++. Professors Don Chamberlin and Mike Carey discussed the need to support complex data models so that users and developers can easily access data in JSON. Don's book, SQL++ for SQL users:A Tutorial, introduces the latest developments in SQL++, a language designed for data processing on the flexible JSON data model that maintains compatibility with SQL. Like the English it borrows, SQL is open to new ideas and extensions for new data types, access methods, and use cases. The independence of SQL and data representation makes it available for non-relational data: CSV, JSON and all big data formats. Some people confuse the rigidity represented by the relational model with the rigidity of SQL. In fact, for any given Schema,SQL, you are allowed to select-join-group-aggregate-project any data format

Evaluate SQL support

Since SQL is ubiquitous, you need to do due diligence at the support level. Identify the characteristics and goals of each workload. For example, interactive applications, or interactive analysis, or batch analysis, or BI workloads, and so on. The declaration of support reflects operational capabilities. Language skills in expressions (scalars, aggregations, Boolean values), joins (inline, left / right / all), subqueries, derived tables, sorting and paging (LIMIT / OFFSET). Index: SQL without a correct index is just a prototype of a Turing machine. Optimizer: query rewriting, choosing the correct access path, and creating the best execution path are the reasons that make SQL a successful fourth-generation language. Some have rule-based optimizers, some have cost-based optimizers, and some have both. It is important to evaluate the quality of the optimizer. Typical benchmarks (TPC-C, TPC-DS, YCSB, YCSB-JSON) don't help you here. As we often say, "there are three important aspects of a database: performance, performance, and performance." It is important to measure the performance of the workload. YCSB and extended YCSB-JSON will make it easier to evaluate. SDK: rich SDK and language support to speed up your development. BI tool support: for large data analysis, it is often important to support BI tools through standard database connection drivers. Gerald Sangudi, the creator of N1QL, once said that SQL is successful because it represents the basic operation of data processing. SQL supports a rich set of operations: select-join-nest-unnest-group-aggregate-having-window-order-paginate-set-ops. Is this what we (or machines) think when specifying data operations? While it remains to be seen, languages like Python and Java are adding operators to these operations on the data. Maybe others will follow suit. SQL has entered an area where the relational database model has not been involved. It is no exaggeration to say: SQL is dead, but SQL will last forever!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.