本篇内容主要讲解“在编写下一个SQL查询之前需要注意的问题有哪些”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“在编写下一个SQL查询之前需要注意的问题有哪些”吧!
成都创新互联服务项目包括潮阳网站建设、潮阳网站制作、潮阳网页制作以及潮阳网络营销策划等。多年来，我们专注于互联网行业，利用自身积累的技术优势、行业经验、深度合作伙伴关系等，向广大中小型企业、政府机构等提供互联网行业的解决方案，潮阳网站推广取得了明显的社会效益与经济效益。目前，我们服务的客户以成都为中心已经辐射到潮阳省份的部分城市，未来相信会继续扩大服务区域并继续获得客户的支持与信任！
当我在Airbnb时，我有很好的机会，可以在向Brian Chesky报告的新团队中工作。这是令人兴奋的 - 我们正在扮演一个新产品系列，所以我们必须每天制作更改游戏的决定。但作为团队的数据科学家，我始终负责采购数据以指导我们的产品方向，这意味着很多分析工作。
第一周是对我的上下文开关的能力的艰难测试：我不得不找到模糊的表格并编写大量查询，但甚至通过Beautifulsoup Scrapes和Veartrics API请求正则表达式。截至第三周，我开始累了，所以我需要一个系统来保持我的速度。我来实现，在使用数据时，只有两种可以搞砸的方式：
使用错误的数据。
错误的使用数据。
这两个都可以通过在数据周围具有更好的上下文来解决。
所以我自己做了一个清单来减轻这两个错误，以确保我不会将产品引导到遗忘。我会在这里分享我的，但是这对你来说究竟可能取决于你公司的特定筹码。将此作为一个示例指南，了解如何让自己一些好的语境，以使您使用表格的危险，但我鼓励您采取这个并使其成为自己的。
那么我需要什么背景，我如何得到它?
嗯，您需要任何和所有信息，这些信息将减少错误或使用错误数据的数据。在我的经验中，只需三个检查可以获得合理的覆盖：
检查基本表METAData.e.g。列名称，分区信息，如何生成。
检查您的假设。在本专栏中是什么?这是一个空列吗?什么是截然不同的价值?自上次我跑这个查询以来有这些改变吗?
与别人联系。其他人在做这张表做什么?你问谁有疑问吗?
1.检查基本表元数据
第一步是它找到一个表并弄清楚如何查询它。
You must woo your table before it will reveal its secrets(Reposted with permission from Olya Tanner)
对于最基本的信息，如列名，索引信息，分区信息，查看定义，您通常可以查询系统表。手头保留这些表的列表，以便您可以轻松查询它们。例如，对于符合ANSI SQL的数据库(其中大多数)，请记住以下表格通常有助于：
Information_schema.columnScolumn 名称，分区信息，列类型，无效。
Information_schema.tables和Information_schema.viewSnice列表所有表和视图。视图，您通常可以获得DDL语句。
您通常还可以获得其他人写的查询历史，这可以帮助弄清楚如何使用表格。您甚至可以通过语句类型进行过滤(例如，创建，插入，选择)以确定如何创建表：
Information_schema.jobs_by_project(bigquery)表(Information_schema.query_history())
2.检查您的假设。
记下您的假设并运行查询来检查它们。
A nice illustration of a person making a checklist, in case you haven’t seen one before.
此时您希望查看数据是否是您认为的。虽然我的典型方法是随意走过的选择*并选择不同的语句，但这是次优。更好的方法是首先弄清楚：
我需要回答什么问题，我制作了什么假设?
写下这些，然后写下回答这些问题的查询/验证这些假设。它可能听起来很简单，但如果你做出错误的假设，你必须重新开始。我们在使用数据时都做出假设 - 如果您没有明确到他们，这是一个灾难的配方。
最近项目的一些示例：
每次活动只有一行吗?
该字段的可能值是什么?
这个专栏是无数的吗?
如果为null，则对这些空值有任何系统模式?
我个人使用鲸鱼(CLI工具，如果我感到不耐烦)或运行的dataframe(甚至计划)这些快速检查，但无论您使用什么，只需确保将它们保持持久。
最后，是的，它很好 - 继续进行选择*。有时您只需要查看一片数据。
3.与其他人联系
既然你已经有一种感觉的数据的形式，只是潜入并建立你需要建立的东西。别。您需要尽可能多地获得各种社交环境和部落知识，并且在大型组织中尤其如此。
现在是时候收集部落知识了。
我知道这些人没有面孔，但是在获得一些其他社交环境之后，您难道不就让右边的家伙感到高兴吗?
不幸的是，只有这么多，您可以通过单独疏浚数据来获得。您需要与真实的人交谈(或找到一些最新的文件)。
通过查询日志(见上文)，通过Github的Slog(如果您的查询是版本控制的)，或者检查表的所有者是谁(您通常可以在数据上下文/发现工具中这样做，如dataframe) - 只是找一个人懈怠。
一般来说，我问以下问题：
这是维持吗?
这是用于{{你的场景}}的最佳数据吗?
迄今为止你所做的事情是开放的。你可能在错误的表上，但人们欣赏一些争议。
到此，相信大家对“在编写下一个SQL查询之前需要注意的问题有哪些”有了更深的了解，不妨来实际操作一番吧！这里是创新互联网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！
