Questions tagged «query»

假设我正在建立一个博客，希望发布和发表评论。因此，我创建了两个表，一个具有自动递增整数“ id”列的“ posts”表，以及一个具有外键“ post_id”的“ comments”表。 然后，我想运行可能是我最常见的查询，即检索帖子及其所有评论。对于关系数据库而言，它是相当新的东西，对我而言，最明显的方法是编写看起来像这样的查询： SELECT id, content, (SELECT * FROM comments WHERE post_id = 7) AS comments FROM posts WHERE id = 7 这会给我我想要的帖子的ID和内容，以及所有相关的注释行，它们整齐地打包在一个数组中（嵌套表示形式，就像您在JSON中使用的一样）。当然，SQL和关系数据库不是这样工作的，它们可以得到的最接近的结果是在“帖子”和“注释”之间进行联接，这将返回很多不必要的数据重复（重复相同的帖子信息）在每一行中），这意味着要花费大量的时间在数据库上以将它们放在一起，也需要花费我的ORM来解析和撤消所有内容。 即使我指示我的ORM急切地加载帖子的评论，最好的办法是调度一个对该帖子的查询，然后进行第二个查询以检索所有评论，然后将它们放到客户端，效率也不高。 我知道关系数据库是经过验证的技术（地狱，它们比我还旧），并且在过去的几十年中，对它们进行了大量研究，我敢肯定，它们（以及SQL标准）旨在按其功能运行，但我不确定为什么上面概述的方法不可行。在我看来，这是实现记录之间最基本关系之一的最简单，最明显的方法。为什么关系数据库不提供这样的功能？ （免责声明：我主要使用Rails和NoSQL数据存储来编写Web应用程序，但是最近我一直在尝试Postgres，我实际上非常喜欢它。我并不是要攻击关系数据库，只是感到困惑。） 我不是在问如何优化Rails应用程序，或如何在特定数据库中解决此问题。我在问为什么SQL标准在我看来违反直觉和浪费时会以这种方式工作。SQL的原始设计者希望他们的结果看起来像这样有一定的历史原因。

46 database  sql  rdbms  query 

我发现编写涉及多个（至少3-4个）表之间的联接并涉及多个嵌套条件的复杂SQL查询非常困难。我被要求编写的查询很容易用几句话来描述，但是可能需要大量的欺骗性代码才能完成。我发现自己经常使用临时视图来编写这些查询，这似乎有些曲折。您可以提供哪些提示以使这些复杂查询更容易？更具体地说，如何将这些查询分解为实际编写SQL代码所需的步骤？ 请注意，我是被要求编写的SQL，是数据库课程家庭作业的一部分，因此，我不希望有能够为我完成工作的软件。我想真正理解我正在编写的代码。 更多技术细节： 该数据库托管在本地计算机上运行的PostgreSQL服务器上。 数据库非常小：最多有七个表，最大的表少于50行。 SQL查询将通过LibreOffice Base不变地传递到服务器。

42 sql  tips  query 

那里有很多程序员，他们也是查询编写和数据库设计方面的专家。 这是成为专家程序员或软件工程师的核心要求吗？ 尽管查询和代码的开发方式有很多相似之处，但我个人认为，查询似乎与代码具有不同的结构，并且由于方法不同，很难同时掌握两者。

35 database  query 

对于ElasticSearch和图数据库之间的比较，我在网络上找不到任何深入的解释。 两者均经过优化以遍历数据。 ElasticSearch似乎已针对分析进行了优化。 但是Neo4j也基于Lucene来管理索引和一些全文功能。 如果已经使用图形数据库，为什么还要使用ElasticSearch？ 就我而言，我正在使用Neo4j建立社交网络。 ElasticSearch可以带来什么真正的好处？ 更新---------- 我刚刚找到了这一段： 在无数情况下，elasticsearch是有用的。一些用例比其他用例更明确地要求它。下面列出了一些特别适合Elasticsearch的任务。 在大量产品说明中搜索特定词组（例如“厨师的刀”）的最佳匹配，并返回最佳结果 以前面的示例为例，分解出现“厨师的刀”的各个部门（请参阅本书后面的分面） 在文本中搜索听起来像“季节”的单词 在考虑到拼写错误的情况下，根据先前发布的搜索结果，根据部分键入的单词自动完成搜索框 以分布式方式存储大量的半结构化（JSON）数据，并在整个计算机集群中具有指定级别的冗余 但是，应该注意的是，尽管Elasticsearch在解决上述问题方面很出色，但对于其他人来说并不是最佳选择。解决关系数据库已优化的问题尤其困难。问题如下。 计算库存中剩余多少物品 计算给定月份发出的所有发票上所有行项目的总和 通过回滚支持以事务方式执行两个操作 创建保证在多个给定条件下唯一的记录，例如电话号码和分机号 Elasticsearch通常非常擅长提供数据的近似答案，例如按质量对结果进行评分。虽然Elasticsearch可以执行精确的匹配和统计计算，但其主要搜索任务是固有的近似任务。 查找近似答案是一种将Elasticsearch与更多传统数据库区分开的属性。话虽这么说，传统的关系数据库在精度和数据完整性方面都非常出色，而Elasticsearch和Lucene对此几乎没有规定。 我是否可以断言，如果我不需要近似答案，那么与已经使用的图形数据库相比，ElasticSearch会毫无用处吗？

15 database  query  graph-databases  elasticsearch