grouping sets機能の使い所とPostgreSQLにおける性能検証
この記事は毎週必ず記事がでるテックブログ "Loglass Tech Blog Sprint" の 12 週目の記事です！ 1 年間連続達成まで 残り 41 週 となりました！ ログラスの龍島（りゅうしま）です。今回はSQLのちょっとニッチな機能の紹介と簡単な性能検証をしてみたいと思います。紹介する機能はgrouping setsです。主にPostgreSQLを念頭に話します。 この記事でわかること grouping setsとはどういう機能なのか どのような場面で使うのか 性能面でどういった性質があるのか grouping setsとは SQL99で規定されているgroup byに関連する機能で、簡単に言うと「複数の組み合わせのgroup byを一度に実行できる」というものです。 PostgreSQLの公式ドキュメントとしては下記ですが、正直パッと理解しにくいと思いますので簡単な例を見て
SQL on HadoopだったらDWHでよくね？ - 超ウィザード級ハッカーのたのしみ
ちょっと前からモヤモヤしていたこと――HiveやPrestoのようなSQLでHadoop上のデータを集計できるというようなものを使うのだったら、昔からあるデータウェアハウス（DWH）でよくないか？ データを扱うにはSQLが、なんやかんやで向いているということが再確認されている。ビッグデータは大量の非構造データのことだとしばし前はいわれていたが、非構造データなんてゴミデータなわけで意味のあるデータは何かしらの構造がある。データがどういう構造をもっていたら整理しやすいかというのは、長年――人類が文字をもったときから――研究されてきた。その結果人類は関係モデルというものにたどり着いた。他にもKey-ValueだとかXMLだとかデータの持ち方は色々あるけれど、やっぱり関係モデルが未だ最強のデータモデルだと私は思う。慣れている人が多いという点と扱いやすいように整理されているという点で関係モデルに帰着
DBMSをC++で自作して、ついでに機械学習モデル用自作デバッガを動かしてみた - Qiita
概要 以下の「DBMSをGoで実装してみた」という記事が面白かったので、C++でDBMSを自作してみた。元記事で開発したDBMS (bogoDBと呼ばれている)をベースにしつつ、B木ではなくB+木を使ったインデクスや複数ページの管理、Foat型、複数列・テーブルの同時選択、ファイル実行、範囲検索のなど様々な機能を追加した。 ただ、単にDBMSを作っただけでは物足りない気がしたので、以前から気になっていたRainというSQLクエリをインターフェースとして機械学習モデルのデバック & 異常な学習データの除去を行うシステムもフルスクラッチで構築してみた。 実際の使用例を先に示すと、以下のデータセットbankruptの顧客の年齢と負債に基づいて、各顧客が倒産するかどうかを分類するモデルを作りたいとき、 >>Select * From bankrupt id age debt y 1 40 0 0
SQLが好きになれない
たまにSQLを書くのだが、やはりSQLが好きになれない。 構文によって書き方が違うのがわかりにくい。 SELECTはまだいい。問題はINSERTとUPDATEである。 INSERTはVALUESで書くくせに、UPDATEになるとSETで=でつなげているのモヤモヤする。 さらに()が必要な構文だったり必要ではないものであったり統一感がないのが混乱する。 INTOで文章らしさを出しているのかしらないが、どちらにしろ文章にならないので中途半端なのでいらないのではないだろうか。 長ったらしいSQLを書かされるのがとてもクレイジー。 ちょっとした検索したい場合はいいかもしれないが、プログラムの一部としての長ったらしいSQLは可読性も悪ければ保守性も悪いで誰も得しない。 さらに解決される順番が未だによくわからない。特にGROUP BYを使う場合にどういったタイミングでされるのか非常にわかりにくい。 サ
SQL 2023 のグラフ構文を試す - Qiita
次期 Oracle Database 開発者向け無料版「Oracle Database 23c Free」が 2023年4月3日 に提供開始されました。このリリースは SQL の最新仕様（SQL:2023）に含まれる Property Graph 文法をサポートしているので、早速使ってみます。 ここでは、以前の記事「銀行の送金データをグラフで分析する」のデータを用います。以前の記事では SQL と別の言語である PGQL を用いてクエリを試していますが、この記事では SQL でグラフのパターンを記述します。 詳細は Oracle Database 23c Free のドキュメント の Property Graph Release 23.2 に解説されています。SQL Property Graphs の項をご参照ください。 Oracle Database 23c の起動 Docker または
Rollupちゃんと理解してる？ - Qiita
はじめに SQLには、単純なGroup byによる集計計算に加え、Rollup, Cube, Grouping Setsなどの指定カラムに対して追加集計計算を行う便利な機能があります。特にRollupは小計や総計を取得するのに便利で身近な存在ですが、動きをしっかり把握していないと集計対象が複雑になった場合にピンポイントで必要な集計を得るのが難しくなります。 例えば、以下の例では一つのカラムだけを対象にRollupを使用して総計を取得していますが、Group Byの対象が複数カラムになった場合に総計だけを取得するにはどう記述すればよいでしょうか？ また、4つの複合カラムで集計する場合に総計と特定のひとつのカラムの小計だけ取りたい場合はどうでしょう？ select item, sum(qty), count(*) from test_rollup group by rollup(item);
SQLライクな「グラフ」クエリエンジンOpen SOQLを作ってみた - Qiita
本日(2020-08-17)、Open SOQL 最初の安定版となる v0.1.0 をリリースしました🎉 Open SOQLはSalesforceで使われている独自のクエリ言語「SOQL」(Salesforce Object Query Language) のオープンソース実装版です。 オリジナルのSOQLは長い歴史を持ちますが (詳しい歴史を辿れないのですが、2008年には既に存在していたようです)、オブジェクトのグラフを利用者が必要な項目に絞って取得できる (つまり、オーバークエリしない) という、まるでGraphQLのような特徴を持っています。 (GraphQLの初版は2015年のようです) 文法もSQLに近く学習コストが抑えられており、さらにGroup byによる集計もサポートしています。 Open SOQLはオリジナルのSOQLとは異なり、Salesforceのデータをクエリす
「等しい」と「重複している」の違い。それらとUNIQUE制約の関係 - 極北データモデリング
SQLを使っていると、あたかもNULLがNULLに等しいかのように見える場面が多々ある。 例えば DISTINCT や GROUP BY で複数のNULLが1個に集約されるとか。あるいは集合演算子(UNION, EXCEPT, INTERSECT)でのNULLの扱いとか。 SQL92の解説書 標準SQLガイド (アスキーアジソンウェスレイシリーズ―Ascii Addison Wesley programming series) 作者: C.J.Date,Hugh Darwen,Quipu LLC出版社/メーカー: アスキー発売日: 1998/12メディア: 単行本購入: 1人 クリック: 10回この商品を含むブログ (2件) を見るによれば、NULLとNULLは等しくはないが「重複」はするのだそうだ。 列col1とcol2が等しいか、ともにNULLならば、それらは重複していると判定される。
最近、クエリビルダーを使うのがだるい
クエリビルダーやORMを使うのは基本的に良いこと。 特に開発初期とかはレビューの時間も足りず、クソみたいなクエリを書いてしまったりするので、それを防止するためにも、ライブラリでリスクを担保してあげるのは大事なこと。てか大体は慢心によってそういうの使わないって選択すると失敗すると思う。僕は失敗する自信がある。 自分もGoで開発する時、MySQLに対してのクエリを書く場合は、以下のクエリビルダーを使っている。一部ビルダーでJOINが使えなかったり、サブクエリの書き方が特殊だったりするが、それ以外はだいぶライトな実装で満足している。 ただ、最近サービスもすくすく育ち、レビュー体制が堅実になっていく動きの中で、クエリビルダーを使うのがダルくなってきた。 なんでかというと、多分以下の2つの理由でだるい。 サービス規模に応じて諸事情を孕んだ複雑な実装が生まれるが、その複雑さをクエリが吸収してしまい、メ
僕なりのSQLスタイルガイドを定義してみる
宗教戦争する気は毛頭ありません このスタイルガイドをそのまま使うもよし、たたきとするもよし ご自身の状況、組織に応じて柔軟にお使いください なぜ定義するか コードは書く時間より読む時間の方が長い、SQLも例外ではないと思っています、読みやすく(理解しやすく)するためにスタイルガイドを使いたいと思っています どういうクエリが「読みやすい」かは人によって差異があると思います、それぞれの「読みやすい」をチーム内ですり合わせるためにスタイルガイドを使いたいと思っています スタイルガイドで「ここまでは揃える」を定義すると、「ここからは個人の自由で」という部分を明確にできます、これは余計なレビューコストを下げるのに役立つはずだと思っています スタイルガイドを定義できればlinterに指摘してもらえます、人間に指摘されるより機械に指摘された方が心理的安全性が高いと思っています 指摘する方もストレスなんや
SQLの文法がこう拡張されるとうれしい - C Sharpens you up
SQLを書いていていろんな場面で「こんな文法であってくれたら！」と歯がゆい思いをすることは多々あります。 これまでに、こう拡張されてくれたらと思った内容をまとめてみました。 なお、この拡張は各社DBの“方言”とはまた別のものです。各社方言とは直交した拡張です。 また、純粋なテキスト変換処理で現行のSQLに変換できるようにというのも意図しています。 dangling comma, その他, カンマ区切りでカラムを列挙するときに、リストの最初と最後に無意味なカンマを許します。 SELECT col1, col2, -- ← これがdangling comma FROM some_table こういう書き方が許されるというもの。カラム構成を編集するときにコピペ操作がしやすくなります。また、gitの変更履歴が見やすくなります。 SELECT, ORDER BY, GROUP BYなどのカラム定義リ
SQL等価性検証ツールCosetteを使ってみた - Qiita
はじめに 皆さん、SQLチューニングしてますか？（唐突） 私は仕事柄RDBMSのSQLチューニングをすることが多いのですが、たまにチューニングの一環で SQL文の書き換え をすることがあります。 その際に問題になるのが、書き換えたSQL文が等価であるかどうかの確認が大変なことです。 SQL文を書き換えた場合には、想定通りの結果を取得できるか確認するために、テストをやり直す必要があります。 これが開発早期のフェーズならまだましなのですが、結合テスト以降だと手戻りも多くかなりコストがかかりますし、既に本番運用が始まったシステムともなると、テスト自体が困難なこともあります。 また、複雑なSQL文だと網羅的なテストケースを作成すること自体が困難であるため、完全に正しいと確信することはできません。 なので、SQL文の書き換えの正しさを証明する良い手段はないかと考えていました。 SQLチューニングとは
RDBMSの進化の歴史をおさらいしよう
データベースは、現在の企業システムの基盤としてなくてはならないソフトウェアである。現在の主流であるリレーショナルデータベースが登場してから約30年経つが、その長い歴史はデータベースがいかにITにとって適合しているのかを物語っている。「枯れた技術」でありながら、今なお進化を続けるデータベースに求められる最新機能を、これまでのデータベースの進化を振り返りながら考えてみよう。 リレーショナルデータベースの進化 リレーショナルデータベースは、1970年にE.F.Codd氏によって提唱されたデータベースモデルで、列と行で構成される表にデータを格納するようになっている。列は項目を、行はデータのレコードを示し、データ定義およびデータ操作を行う言語のSQL（Structured Query Language）を利用し、自由な形式でデータベースを扱える。リレーショナルデータベースには、業務ソフトウェアのプロ
SQLとはどんな言語か - SQLは仕様書です - SQLer 生島勘富 のブログ
SQLとはどんな言語かなぜ多くの人が違和感を持つかというと、多くの人が、「プログラミング言語とは手続き型言語である」（オブジェクト指向言語も広義の手続き型言語）という思い込みがあるからでしょう。 手続き型言語の中には 非構造化言語（FORTRANなど） 構造化言語（C言語など） オブジェクト指向言語（Javaなど） などなどがあり、SQLを除けば、数十年前から現在に至るまで、手続き型言語のシェアは95％を超えるのではないでしょうか。関数型言語などは現場で見ることはほとんどありません。ですから、「プログラミング言語とは手続き型言語である」と思っても仕方がない。 SQLは多くの手続き型言語とは性質を異にするものです。「プログラミング言語とは手続き型言語である」と仮定すれば「SQLは仕様書である」と言えます。 SQLとは、その前進の名前 SEQUEL (Structured English Qu
On GraphQL-to-SQL
GraphQL has a reputation for its N+1 problem which can often happen when implemented naively. This leads to a lot of us trying to solve the issue of data fetching with GraphQL in the most efficient way possible. Besides the popular Dataloader approach, another very common way of tackling this problem is by taking a GraphQL query, and coming up with the exact SQL needed to resolve it: // example fr
SQLアンチパターン - ナイーブツリー
社内勉強会資料 追記: 2013-10-31 ついったで指摘( https://twitter.com/akuraru/status/395822183777202176 )を受けたので入れ子集合のノード追加の説明の所を修正しました。
AWS、SQL互換の新問い合わせ言語「PartiQL」をオープンソースで公開。RDB、KVS、JSON、CSVなどをまとめて検索可能
Amazon Web Services（以下AWS）は、SQL互換の新しい問い合わせ言語およびそのリファレンス実装である「PartiQL」をオープンソースとして公開したことを発表しました。 PartiQLはSQL互換の構文に最小限の拡張を施すことで、リレーショナル形式のデータベースだけでなく、KVSやJSONなどを含むNoSQLデータベースやCSVファイルなど、さまざまなデータソースに対して横断的に検索できる問い合わせ言語およびそのリファレンス実装です。 下記はPartiQLを発表したブログからの引用です。 Today we are happy to announce PartiQL, a SQL-compatible query language that makes it easy to efficiently query data, regardless of where or in
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
006 エニグマ・タイプライターの謎―リレーショナルデータベース誕生の時代背景
Sparkのクエリ処理系と周辺の話題
GitHub - ronsavage/SQL: BNF Grammars for SQL-92, SQL-99 and SQL-2003
