SQL 基础！！指向前后（训练、复习、SELECT 语句）

介绍

这是我作为没有实践经验的网络工程师加入公司后两个月内接受的内部培训的回顾。

SQL 数据检索(选择语句) 并比较 SQL 语句的前后。


文章的目的

同时，（其他公司的）没有实践经验的成为Web工程师并进行互动的人，

“我很想听听其他人的早期进展。”

正如我所说，我只有机会在培训期间对我编写的代码进行审查，但我想分享一下审查教会了我什么。

通过回顾，我会检查我是否在当下而不忘记。

目标读者

目标读者是没有实践经验的初学者。 （我写这个假设我过去的自我）

什么样的内部培训？

内部培训通常是关于 Web 开发的基本培训，并具有以下课程。

  1. PHP 基础知识（PHP，面向对象）
  2. 数据库基础知识（SQL、MySQL）
  3. Web 应用程序基础（HTML、CSS、CRUD、Cookie、会话）

    解决这些内容的问题，在GitLab上提出合并请求，内部工程师这是从人们那里获得评论的流程。

    * PHP 基础相关文章



    例如，SQL 问题类似于以下内容。

    创建一个输出产品表所有内容的 SQL


    这样一来，大概有20道题，询问对SQL基本语法的理解，我们会改正，直到获得OK为止。

    * 存在数据获取、数据操作、表操作、事务等问题。


    目录

    这次，关于“数据库基础”的主题，SQL 数据检索(选择语句），我想以评论内容为重点来组织它（因为第一次评论中有各种各样的点）。

    我们收集了以下 8 条评论。

    1. “确定你的 SQL 编码风格”

    2. “如果你能得到不止一个，请养成写ORDER BY的习惯。”

    3. “使用IN将条件写在一行中”

    4. “在count函数中，将条件写在WHERE子句中，不写条件。”

    5. “基本上，使用JOIN ON 进行表连接。”

    6. “请给我另一个名字AS”

    7. “与加入无关的条件应写在JOIN之后”

    8. “使用 GROUP BY 更改为 SQL”

      * 由“回答前”→“复习”→“回答后”→“备忘录”组成。
      * 获取的数据前后一致。

      1.“确定你的 SQL 编码风格”

      审查

      我在缺少 SQL 编码规则时遇到了麻烦。让我们统一一下。

      在实践中，首先检查现场的编码风格。

      备忘录

      • 或者更确切地说，在审查之前先审查。我在网上搜了一下，不知道主流的SQL编码风格是哪一种，感觉每个人都不一样，但是实际的网站呢？

      2.“如果你能得到不止一个，请养成写ORDER BY的习惯。”

      前

      SELECT
    product_id,
    product_name,
    color,
    price,
    delete_flag,
    created_at,
    updated_at
FROM
    products
;

      审查

      如果您可以获得多个，请务必包含ORDER BY。养成这样做的习惯。

      后

      SELECT
    product_id,
    product_name,
    color,
    price,
    delete_flag,
    created_at,
    updated_at
FROM
    products
ORDER BY
    product_id ASC
;

      备忘录

      • 如果你想一想为什么你应该总是包含ORDER BY，你会发现如果你不指定任何排序顺序，对于得到的显示顺序，并不能保证它会如何显示。 . 实践中会指定，所以让我们养成指定的习惯。

      3.“使用IN将条件写在一行中”

      前

      SELECT
    product_id,
    product_name,
    color,
    price,
    delete_flag,
    created_at,
    updated_at
FROM
    products
WHERE
    color = '赤'
    OR
    color = '青'
ORDER BY
    product_id ASC
;

      审查

      使用IN 将条件写在一行中。

      后

      SELECT
    product_id,
    product_name,
    color,
    price,
    delete_flag,
    created_at,
    updated_at
FROM
    products
WHERE
    color
    IN
    (
        '赤',
        '青'
    )
ORDER BY
    product_id ASC
;

      （由于我的编码风格，我无法将其写在一行中，但是...）

      备忘录

      • 当我想到为什么使用IN更好的原因时，我认为这意味着即使有更多诸如’黒’,'白’之类的元素，也可以简洁地写出来。

      4.“在WHERE子句中写条件而不在count函数中写条件”

      前

      SELECT
    COUNT(
        gender = '男'
        OR
        NULL
    ) AS '男性の人数'
FROM
    members
WHERE
    delete_flag = 0
;

      审查

      在WHERE 子句中写入条件，而不在count 函数中写入条件。 count(*) 对于使用简单计数的 SQL 很常见。

      后

      SELECT
    COUNT(*) AS '男性の人数'
FROM
    members
WHERE
    delete_flag = 0
    AND
    gender = '男'
;

      * OR NULL 已被删除，因为在更改的写作风格中不再需要它。

      备忘录

      • 我简单想过为什么在count函数中没有写条件，而写在WHERE子句中的原因，但目前还不是很明白。 SQL 语句似乎易于编写和阅读。我将从“一般”的写作方式开始。

      5.“使用JOIN ON 进行表连接”

      前

      SELECT
    SUM(sales.quantity * products.price)
FROM
    sales, products
WHERE
    sales.product_id = products.product_id
;

      审查

      SQL/编码风格在

      JOIN ON 子句

      Join 基本使用JOIN ON to FROM multiple + WHERE 子句没有描述join条件

      请按照说明进行更正。

      后

      SELECT
    SUM(sales.quantity * products.price)
FROM
    sales
INNER JOIN
    products
    ON
        sales.product_id = products.product_id
;

      备忘录

      • 当我查看为什么``为什么FROM在FROM + WHERE子句中没有被描述为连接条件，但基本上使用JOIN ON进行连接？写多个@987654355的方法@ + WHERE 子句称为简单连接，返回所有sales 和products 表组合的记录，导致数据量很大。”我想就是这个意思。

      6.“请给我另一个名字AS”

      前

      SELECT
    SUM(sales.quantity * products.price)
FROM
    sales
INNER JOIN
    products
    ON
        sales.product_id = products.product_id
;

      审查

      请给一个别名AS。

      后

      SELECT
    SUM(s.quantity * p.price) AS '売り上げの合計'
FROM
    sales AS s
INNER JOIN
    products AS p
    ON
        s.product_id = p.product_id
;

      备忘录

      • 我认为“为什么要使用AS 别名的原因是为列和表提供别名使它们更易于阅读和简洁”。

      7.“与合并无关的条件请发JOIN。”

      前

      SELECT
    SUM(s.quantity * p.price) AS '非会員の売り上げの合計'
FROM
    sales AS s
INNER JOIN
    products AS p
    ON
        s.product_id = p.product_id
        AND
        s.member_id IS NULL
;

      审查

      如果INNER JOIN 的ON 子句中包含销售条件，则很难阅读，所以请在JOIN 后面写上销售条件（s.member_id IS NULL）。

      后

      SELECT
    SUM(s.quantity * p.price) AS '非会員の売り上げの合計'
FROM
    sales AS s
INNER JOIN
    products AS p
    ON
        s.product_id = p.product_id
WHERE
    s.member_id IS NULL
;

      备忘录

      • 至于原因，作为sales表和products表的连接条件，“如果有sales条件就很难读取”。
      • 我不知道执行成本是否保持不变。

      8.“使用GROUP BY更改为SQL”

      前

      SELECT
    SUM(
        CASE WHEN m.gender = '男'
        THEN s.quantity * p.price
        ELSE 0 END
    ) AS '男性会員の売り上げの合計'
    ,
    SUM(
        CASE WHEN m.gender = '女'
        THEN s.quantity * p.price
        ELSE 0 END
    ) AS '女性会員の売り上げの合計'
FROM
    sales AS s
INNER JOIN
    products AS p
    ON
        s.product_id = p.product_id
INNER JOIN
    members AS m
    ON
        s.member_id = m.member_id
;

      审查

      请使用GROUP BY 更改为SQL。

      后

      SELECT
    m.gender,
    SUM(s.quantity * p.price) AS '売り上げの合計'
FROM
    sales AS s
INNER JOIN
    products AS p
    ON
        s.product_id = p.product_id
INNER JOIN
    members AS m
    ON
        s.member_id = m.member_id
GROUP BY
    m.gender
;

      备忘录

      • 想想原因，比CASE公式更清楚，而且我认为GROUP BY在你想按类型聚合的时候比较好。
      • 我希望能够考虑SQL语句的可读性和执行成本，即使得到的结果相同。

      综上所述

      由于我在实践中还没有接触过SQL，所以我有一种危机感，感觉自培训以来我对SQL的理解并没有太大的变化。do...

      另外，当我被告知最好在评论中这样写时，没有附上原因，所以我认为有必要了解原因，所以我在恢复文章时添加了一个备忘录。稻田。

      我们期待您对本文的反馈！


      非常感谢！


原创声明：本文系作者授权爱码网发表，未经许可，不得转载;

原文地址：https://www.likecs.com/show-308627768.html

相关文章：

  • 2021-09-11
  • 2022-12-23
  • 2021-10-01
  • 2021-08-31
  • 2022-02-16
  • 2022-01-27
  • 2021-12-01
  • 2022-12-23
猜你喜欢
  • 2021-07-10
  • 2021-11-15
  • 2021-12-30
  • 2022-12-23
  • 2022-12-23
  • 2021-12-15
相关资源
相似解决方案
热门标签
Java Python linux javascript Mysql C# Docker 算法 前端 SpringBoot Redis Vue spring 设计模式 .net core .net kubernetes c++ 数据库 数据结构 大数据 js 机器学习 微服务 Android Go 程序员 面试 JVM ASP.net core 云原生 人工智能 后端 PHP git CSS golang k8s Nginx Django mybatis 深度学习 多线程 React 架构 devops 爬虫 云计算 Spring Boot LeetCode