Introduzindo SQL
Introduzindo SQL / SQL 简介
O que é SQL? SQL (Structured Query Language) é uma linguagem de programação utilizada para gerenciar e manipular dados armazenados em sistemas de gerenciamento de bancos de dados relacionais (RDBMS). Ela permite recuperar, inserir, atualizar e excluir dados, bem como definir esquemas de banco de dados e controlar o acesso aos dados. A compreensão básica de SQL é fundamental para interagir com praticamente qualquer banco de dados.
什么是 SQL？ SQL（结构化查询语言）是一种用于管理和操作关系型数据库管理系统（RDBMS）中存储数据的编程语言。它允许用户检索、插入、更新和删除数据，以及定义数据库架构和控制数据访问。掌握 SQL 的基础知识对于与几乎任何数据库进行交互都至关重要。
Bancos de dados Relacionais Em 1970, o cientista da computação Edgar F. Codd publicou um artigo que mudaria para sempre a forma como armazenamos e consultamos dados. Nele, propunha organizar informações em estruturas tabulares — linhas e colunas — conectadas entre si por meio de relacionamentos lógicos. Nascia ali o modelo relacional, base de praticamente todo sistema de software corporativo que conhecemos hoje.
关系型数据库 1970 年，计算机科学家 Edgar F. Codd 发表了一篇论文，永远改变了我们存储和查询数据的方式。他在文中提出将信息组织成表格结构（行和列），并通过逻辑关系相互连接。关系模型由此诞生，它构成了我们今天所知的几乎所有企业软件系统的基础。
Um banco de dados relacional armazena dados em tabelas. Cada tabela representa uma entidade do mundo real: clientes, pedidos, produtos. Cada linha é um registro individual, e cada coluna descreve um atributo desse registro. O que torna o modelo poderoso não é apenas a organização em tabelas, mas a capacidade de relacioná-las — uma tabela de pedidos pode referenciar a tabela de clientes por meio de uma chave estrangeira, evitando duplicação e garantindo que os dados permaneçam consistentes.
关系型数据库将数据存储在表中。 每个表代表一个现实世界的实体：客户、订单、产品。每一行是一个单独的记录，每一列描述该记录的一个属性。该模型强大的原因不仅在于表格组织，还在于关联它们的能力——订单表可以通过外键引用客户表，从而避免重复并确保数据的一致性。
Essa consistência é garantida por um conjunto de propriedades conhecido pela sigla ACID: As operações são atômicas (ou tudo acontece, ou nada acontece), o banco sempre transita entre estados válidos, transações concorrentes não interferem entre si, e dados confirmados persistem mesmo diante de falhas. São essas garantias que tornam os SGBDRs a escolha natural para sistemas financeiros, hospitalares e qualquer domínio onde a integridade dos dados não é negociável. PostgreSQL, MySQL, Oracle Database e SQL Server são os representantes mais conhecidos dessa família. Cada um com suas particularidades, mas todos falando a mesma língua: o SQL.
这种一致性由一组称为 ACID 的属性保证： 操作是原子的（要么全部发生，要么什么都不发生），数据库始终在有效状态之间转换，并发事务互不干扰，且已确认的数据即使在发生故障时也能持久保存。正是这些保证使得关系型数据库管理系统（RDBMS）成为金融、医疗系统以及任何对数据完整性有严格要求的领域的首选。PostgreSQL、MySQL、Oracle Database 和 SQL Server 是该家族中最著名的代表。它们各有特点，但都使用同一种语言：SQL。
Benefícios e Limitações dos SGBDRs Por décadas, o modelo relacional foi sinônimo de banco de dados. E com razão: ele resolve de forma elegante um problema difícil, que é manter grandes volumes de dados organizados, íntegros e acessíveis de forma eficiente. A linguagem SQL, padronizada e amplamente dominada pela indústria, permite expressar consultas complexas com poucas linhas. Um JOIN entre três tabelas que retorna exatamente os dados necessários, filtrados e ordenados, é algo que o modelo relacional faz com naturalidade. Somado a décadas de otimização dos engines, ferramentas maduras de administração e uma comunidade enorme, o SGBDR é uma das tecnologias mais confiáveis que existem.
RDBMS 的优势与局限性 几十年来，关系模型一直是数据库的代名词。这是有道理的：它优雅地解决了一个难题，即如何高效地保持海量数据的组织性、完整性和可访问性。SQL 语言作为行业标准并被广泛掌握，只需几行代码即可表达复杂的查询。通过 JOIN 连接三个表并返回精确过滤和排序后的数据，是关系模型自然而然就能做到的。再加上数十年的引擎优化、成熟的管理工具和庞大的社区，RDBMS 是目前最可靠的技术之一。
Mas toda escolha tem um custo. O modelo relacional exige que o esquema seja definido antes de armazenar os dados — e alterar esse esquema em produção pode ser uma operação delicada e cara. Em sistemas que evoluem rápido, ou cujos dados não têm forma bem definida, essa rigidez vira um obstáculo. Há também uma questão de escala. SGBDRs foram projetados para crescer verticalmente: quando o banco fica lento, você coloca mais memória, mais CPU, um disco mais rápido. Essa estratégia tem um limite físico e financeiro. Distribuir um banco relacional entre dezenas de servidores — escala horizontal — é tecnicamente possível, mas complexo, e vai contra a natureza do modelo. Para aplicações que precisam atender centenas de milhões de usuários com latência mínima, essa limitação se torna crítica.
但每一个选择都有代价。 关系模型要求在存储数据之前定义架构，而在生产环境中更改该架构可能是一项微妙且昂贵的操作。在快速发展的系统或数据结构不明确的系统中，这种刚性会成为障碍。此外还有扩展性问题。RDBMS 设计为垂直扩展：当数据库变慢时，你需要增加内存、CPU 或更快的磁盘。这种策略有物理和财务上的极限。将关系型数据库分布在数十台服务器上（水平扩展）在技术上是可能的，但很复杂，且违背了该模型的本质。对于需要以极低延迟服务数亿用户的应用来说，这一局限性变得至关重要。
SQL vs. NoSQL À medida que a internet cresceu, ficou evidente que o modelo relacional não era a resposta para todos os problemas. O ponto de virada aconteceu nos anos 2000, quando empresas como Google e Amazon começaram a enfrentar volumes de dados que nenhum SGBDR tradicional suportava adequadamente. Em 2006, o Google publicou o paper do Bigtable. Em 2007, a Amazon publicou o paper do Dynamo. Em 2008, o Facebook abriu o código do Cassandra, desenvolvido internamente para gerenciar a caixa de entrada de seus usuários. O termo “NoSQL” foi popularizado em uma meetup em San Francisco, em junho de 2009 — e a partir daí o movimento tomou forma.
SQL 与 NoSQL 随着互联网的发展，显而易见，关系模型并不能解决所有问题。转折点发生在 2000 年代，当时 Google 和 Amazon 等公司开始面临传统 RDBMS 无法妥善处理的数据量。2006 年，Google 发布了 Bigtable 论文。2007 年，Amazon 发布了 Dynamo 论文。2008 年，Facebook 开源了 Cassandra，这是其内部开发的用于管理用户收件箱的系统。“NoSQL”一词在 2009 年 6 月旧金山的一次聚会上被普及，从此该运动初具规模。
A motivação era clara: estima-se que cerca de 80% de todos os dados gerados hoje são não estruturados — mensagens, imagens, logs, dados de sensores, eventos de clique. Esse tipo de dado não cabe naturalmente em linhas e colunas de uma tabela relacional. Surgiu então o NoSQL, que mais do que uma negação do SQL, significa “Not Only SQL”: uma expansão do repertório de soluções disponíveis. NoSQL não é um único tipo de banco de dados, mas uma família de abordagens. Os bancos de documentos, como MongoDB, armazenam dados em formato JSON sem esquema fixo — ideais para catálogos e perfis de usuário. Os bancos de chave-valor, como Redis, operam como dicionários extremamente rápidos, perfeitos para cache e sessões. Os bancos de coluna larga, como Cassandra, foram construídos para escalar horizontalmente: o Netflix, por exemplo, usa Cassandra para processar mais de 1 trilhão de operações por dia. E os bancos de grafo, como Neo4j, modelam entidades e relacionamentos de forma nativa — a base de qualquer sistema de recomendação ou rede social.
动机很明确：据估计，今天产生的所有数据中约有 80% 是非结构化的——包括消息、图像、日志、传感器数据和点击事件。这类数据无法自然地放入关系表的行和列中。于是 NoSQL 应运而生，它不仅仅是对 SQL 的否定，更意味着“不仅仅是 SQL”（Not Only SQL）：它是可用解决方案库的扩展。NoSQL 不是单一类型的数据库，而是一系列方法。文档数据库（如 MongoDB）以 JSON 格式存储数据，无需固定架构，非常适合目录和用户资料。键值数据库（如 Redis）作为极速字典运行，非常适合缓存和会话。宽列数据库（如 Cassandra）专为水平扩展而构建：例如，Netflix 使用 Cassandra 每天处理超过 1 万亿次操作。而图数据库（如 Neo4j）以原生方式建模实体和关系，是任何推荐系统或社交网络的基础。
A grande concessão do NoSQL está na consistência. O teorema CAP, formulado por Eric Brewer em 2000, estabelece que um sistema distribuído não pode garantir simultaneamente consistência, disponibilidade e tolerância a partições de rede — é preciso abrir mão de um. A maioria dos sistemas NoSQL escolhe disponibilidade e tolerância a partições, adotando o modelo BASE: a consistência é eventual, podendo levar alguns milissegundos até que todos os nós do cluster reflitam o novo valor. Para uma rede social, isso é aceitável. Para um sistema bancário, não. A escolha entre SQL e NoSQL, portanto, não é uma questão de qual é melhor — é de qual serve melhor ao problema. O Stack Overflow Developer Survey de 2023 mostra PostgreSQL como banco de dados mais utilizado no mundo, com 45% dos desenvolvedores, enquanto MongoDB lidera entre os NoSQL.
NoSQL 的重大妥协在于一致性。 Eric Brewer 在 2000 年提出的 CAP 定理指出，分布式系统无法同时保证一致性、可用性和分区容错性——必须放弃其中之一。大多数 NoSQL 系统选择可用性和分区容错性，采用 BASE 模型：一致性是最终的，可能需要几毫秒才能使集群中的所有节点反映出新值。对于社交网络，这是可以接受的。但对于银行系统，则不行。因此，在 SQL 和 NoSQL 之间进行选择，不是哪个更好的问题，而是哪个更适合当前问题的问题。2023 年 Stack Overflow 开发者调查显示，PostgreSQL 是全球使用最广泛的数据库，占开发者的 45%，而 MongoDB 在 NoSQL 中处于领先地位。