タグ

関連タグで絞り込む (33)

タグの絞り込みを解除

sqlに関するsh19910711のブックマーク (56)

  • grouping sets機能の使い所とPostgreSQLにおける性能検証


    この記事は毎週必ず記事がでるテックブログ "Loglass Tech Blog Sprint" の12週目の記事です！1年間連続達成まで 残り41週 となりました！ ログラスの龍島︵りゅうしま︶です。今回はSQLのちょっとニッチな機能の紹介と簡単な性能検証をしてみたいと思います。紹介する機能はgrouping setsです。主にPostgreSQLを念頭に話します。 この記事でわかること grouping setsとはどういう機能なのか どのような場面で使うのか 性能面でどういった性質があるのか grouping setsとは SQL99で規定されているgroup byに関連する機能で、簡単に言うと﹁複数の組み合わせのgroup byを一度に実行できる﹂というものです。PostgreSQLの公式ドキュメントとしては下記ですが、正直パッと理解しにくいと思いますので簡単な例を見て
    grouping sets機能の使い所とPostgreSQLにおける性能検証
    sh19910711
    sh19910711 2024/04/13
    "grouping sets: SQL99で規定されているgroup byに関連する機能 + 組み合わせのgroup by / group by + union allの手法はgroup byの回数分対象のデータセットをスキャンする必要があるのに対し、grouping setsでは一度のスキャンで済む" 2023
    リンク

  • SQL on HadoopだったらDWHでよくね？ - 超ウィザード級ハッカーのたのしみ


    ちょっと前からモヤモヤしていたこと――HiveやPrestoのようなSQLでHadoop上のデータを集計できるというようなものを使うのだったら、昔からあるデータウェアハウス︵DWH︶でよくないか？ データを扱うにはSQLが、なんやかんやで向いているということが再確認されている。ビッグデータは大量の非構造データのことだとしばし前はいわれていたが、非構造データなんてゴミデータなわけで意味のあるデータは何かしらの構造がある。データがどういう構造をもっていたら整理しやすいかというのは、長年――人類が文字をもったときから――研究されてきた。その結果人類は関係モデルというものにたどり着いた。他にもKey-ValueだとかXMLだとかデータの持ち方は色々あるけれど、やっぱり関係モデルが未だ最強のデータモデルだと私は思う。慣れている人が多いという点と扱いやすいように整理されているという点で関係モデルに帰着
    SQL on HadoopだったらDWHでよくね？ - 超ウィザード級ハッカーのたのしみ
    sh19910711
    sh19910711 2024/03/15
    "データを扱うにはSQLが、なんやかんやで向いている / Hadoopで非構造データが分析できるといわれたが、分析をしたいなら整理されていなければ無理で、整理したければ関係モデルに落ち着く" 2016
    リンク

  • 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
    DBMSをC++で自作して、ついでに機械学習モデル用自作デバッガを動かしてみた - Qiita
    sh19910711
    sh19910711 2023/07/14
    arXiv:2004.05722 / "DBMSを作っただけでは物足りない気がしたので、以前から気になっていたRainというSQLクエリをインターフェースとして機械学習モデルのデバック & 異常な学習データの除去を行うシステムもフルスクラッチ"
    リンク

  • SQLが好きになれない


    たまにSQLを書くのだが、やはりSQLが好きになれない。 構文によって書き方が違うのがわかりにくい。 SELECTはまだいい。問題はINSERTとUPDATEである。 INSERTはVALUESで書くくせに、UPDATEになるとSETで=でつなげているのモヤモヤする。 さらに()が必要な構文だったり必要ではないものであったり統一感がないのが混乱する。 INTOで文章らしさを出しているのかしらないが、どちらにしろ文章にならないので中途半端なのでいらないのではないだろうか。 長ったらしいSQLを書かされるのがとてもクレイジー。 ちょっとした検索したい場合はいいかもしれないが、プログラムの一部としての長ったらしいSQLは可読性も悪ければ保守性も悪いで誰も得しない。 さらに解決される順番が未だによくわからない。特にGROUP BYを使う場合にどういったタイミングでされるのか非常にわかりにくい。 サ
    SQLが好きになれない
    sh19910711
    sh19910711 2023/06/02
    "問題はINSERTとUPDATE / INSERTはVALUESで書くくせに、UPDATEになるとSETで=でつなげているのモヤモヤする / ()が必要な構文だったり必要ではないものであったり統一感がないのが混乱する" / 2017
    リンク

  • 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 または

    SQL 2023 のグラフ構文を試す - Qiita
    sh19910711
    sh19910711 2023/05/19
    "次期 Oracle Database 開発者向け無料版「Oracle Database 23c Free」が 2023年4月3日 に提供開始 / SQL の最新仕様（SQL:2023）に含まれる Property Graph 文法をサポート"
    リンク

  • 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);

    Rollupちゃんと理解してる？ - Qiita
    sh19910711
    sh19910711 2022/12/09
    2018 / "SQLには、単純なGroup byによる集計計算に加え、Rollup, Cube, Grouping Setsなどの指定カラムに対して追加集計計算を行う便利な機能があります / CUBEは、与えられたカラムの全ての組み合わせで集計"
    リンク

  • 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のデータをクエリす
    SQLライクな「グラフ」クエリエンジンOpen SOQLを作ってみた - Qiita
    sh19910711
    sh19910711 2022/10/16
    2020 / "SOQL: Salesforceで使われている独自のクエリ言語 + 文法もSQLに近く + Group byによる集計もサポート / コード書かなくてもいいし、書くとなったら気持ちよく書けるプラットフォームがいい"
    リンク

  • 「等しい」と「重複している」の違い。それらと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ならば、それらは重複していると判定される。
    「等しい」と「重複している」の違い。それらとUNIQUE制約の関係 - 極北データモデリング
    sh19910711
    sh19910711 2022/09/30
    2012 / "NULLとNULLは等しくはないが「重複」はする / GROUP BYが複数のNULLを1行に集約するからといって、それは複数のNULLが「等しい」からではない。...ということらしい"
    リンク

  • 最近、クエリビルダーを使うのがだるい


    クエリビルダーやORMを使うのは基本的に良いこと。 特に開発初期とかはレビューの時間も足りず、クソみたいなクエリを書いてしまったりするので、それを防止するためにも、ライブラリでリスクを担保してあげるのは大事なこと。てか大体は慢心によってそういうの使わないって選択すると失敗すると思う。僕は失敗する自信がある。 自分もGoで開発する時、MySQLに対してのクエリを書く場合は、以下のクエリビルダーを使っている。一部ビルダーでJOINが使えなかったり、サブクエリの書き方が特殊だったりするが、それ以外はだいぶライトな実装で満足している。 ただ、最近サービスもすくすく育ち、レビュー体制が堅実になっていく動きの中で、クエリビルダーを使うのがダルくなってきた。 なんでかというと、多分以下の2つの理由でだるい。 サービス規模に応じて諸事情を孕んだ複雑な実装が生まれるが、その複雑さをクエリが吸収してしまい、メ
    最近、クエリビルダーを使うのがだるい
    sh19910711
    sh19910711 2022/08/07
    2018 / "レビュー時の視認性: 規模に応じて諸事情を孕んだ複雑な実装が生まれるが、その複雑さをクエリが吸収してしまい、メソッドがどちゃどちゃチェインしてコードを追ってもあんまクエリが頭に入ってこない"
    リンク

  • 僕なりのSQLスタイルガイドを定義してみる

    宗教戦争する気は毛頭ありません このスタイルガイドをそのまま使うもよし、たたきとするもよし ご自身の状況、組織に応じて柔軟にお使いください なぜ定義するか コードは書く時間より読む時間の方が長い、SQLも例外ではないと思っています、読みやすく(理解しやすく)するためにスタイルガイドを使いたいと思っています どういうクエリが「読みやすい」かは人によって差異があると思います、それぞれの「読みやすい」をチーム内ですり合わせるためにスタイルガイドを使いたいと思っています スタイルガイドで「ここまでは揃える」を定義すると、「ここからは個人の自由で」という部分を明確にできます、これは余計なレビューコストを下げるのに役立つはずだと思っています スタイルガイドを定義できればlinterに指摘してもらえます、人間に指摘されるより機械に指摘された方が心理的安全性が高いと思っています 指摘する方もストレスなんや

    僕なりのSQLスタイルガイドを定義してみる
    sh19910711
    sh19910711 2022/06/02
    表示するときにスタイルを読み手に応じて変化させて、ロジックに影響しない差分が表示されないようになると良さそう / "コードは書く時間より読む時間の方が長い、SQLも例外ではない"
    リンク

  • 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の文法がこう拡張されるとうれしい - C Sharpens you up
    sh19910711
    sh19910711 2022/05/21
    "カラム名のリストを読まされるんだけど何のテーブルだか分からないからそれがカラム名であるかさえよくわからないし型も当然わからない / 先を読まないと意味が確定しない記述なんてプログラミング言語として最低"
    リンク

  • SQL等価性検証ツールCosetteを使ってみた - Qiita


    はじめに 皆さん、SQLチューニングしてますか？︵唐突︶ 私は仕事柄RDBMSのSQLチューニングをすることが多いのですが、たまにチューニングの一環で SQL文の書き換え をすることがあります。 その際に問題になるのが、書き換えたSQL文が等価であるかどうかの確認が大変なことです。 SQL文を書き換えた場合には、想定通りの結果を取得できるか確認するために、テストをやり直す必要があります。 これが開発早期のフェーズならまだましなのですが、結合テスト以降だと手戻りも多くかなりコストがかかりますし、既に本番運用が始まったシステムともなると、テスト自体が困難なこともあります。 また、複雑なSQL文だと網羅的なテストケースを作成すること自体が困難であるため、完全に正しいと確信することはできません。 なので、SQL文の書き換えの正しさを証明する良い手段はないかと考えていました。 SQLチューニングとは
    SQL等価性検証ツールCosetteを使ってみた - Qiita
    sh19910711
    sh19910711 2021/12/24
    2018 / "Cosette: SQL文の等価性を自動的に検証してくれるツール / 検証により、等価/非等価/決定不能を判定。非等価の場合、反例も出力 / SELECT文のみ対応 + 現時点では検証できないパターンが多く、実用性は乏しい"
    リンク

  • 006　エニグマ・タイプライターの謎―リレーショナルデータベース誕生の時代背景

    EnterpriseZine（エンタープライズジン）編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。

    006　エニグマ・タイプライターの謎―リレーショナルデータベース誕生の時代背景
    sh19910711
    sh19910711 2021/11/20
    "RANDもMITもコッドも自然な英語体でデータをアクセスする言語に関して言及 / 1970年のコッドのリレーショナル・データモデル論の中では、Sort Merge JoinとNested Loop Joinの原案 / コッドはSQLの文法が気に入らなかったらしい"
    リンク

  • RDBMSの進化の歴史をおさらいしよう


    データベースは、現在の企業システムの基盤としてなくてはならないソフトウェアである。現在の主流であるリレーショナルデータベースが登場してから約30年経つが、その長い歴史はデータベースがいかにITにとって適合しているのかを物語っている。﹁枯れた技術﹂でありながら、今なお進化を続けるデータベースに求められる最新機能を、これまでのデータベースの進化を振り返りながら考えてみよう。 リレーショナルデータベースの進化 リレーショナルデータベースは、1970年にE.F.Codd氏によって提唱されたデータベースモデルで、列と行で構成される表にデータを格納するようになっている。列は項目を、行はデータのレコードを示し、データ定義およびデータ操作を行う言語のSQL︵Structured Query Language︶を利用し、自由な形式でデータベースを扱える。リレーショナルデータベースには、業務ソフトウェアのプロ
    RDBMSの進化の歴史をおさらいしよう
    sh19910711
    sh19910711 2021/11/20
    "最初のリレーショナルデータベースは、IBMが1970年代に開発した「System R」だと言われている / SQL > System Rを操作するために実装されていた「SEQUEL」をベースにANSIによって規格化 / 1980年代には、商用データベースが続々と"
    リンク

  • SQLとはどんな言語か - SQLは仕様書です - SQLer 生島勘富 のブログ


    SQLとはどんな言語かなぜ多くの人が違和感を持つかというと、多くの人が、﹁プログラミング言語とは手続き型言語である﹂︵オブジェクト指向言語も広義の手続き型言語︶という思い込みがあるからでしょう。 手続き型言語の中には 非構造化言語︵FORTRANなど︶ 構造化言語︵C言語など︶ オブジェクト指向言語︵Javaなど︶ などなどがあり、SQLを除けば、数十年前から現在に至るまで、手続き型言語のシェアは95％を超えるのではないでしょうか。関数型言語などは現場で見ることはほとんどありません。ですから、﹁プログラミング言語とは手続き型言語である﹂と思っても仕方がない。 SQLは多くの手続き型言語とは性質を異にするものです。﹁プログラミング言語とは手続き型言語である﹂と仮定すれば﹁SQLは仕様書である﹂と言えます。 SQLとは、その前進の名前 SEQUEL (Structured English Qu
    SQLとはどんな言語か - SQLは仕様書です - SQLer 生島勘富 のブログ
    sh19910711
    sh19910711 2021/11/20
    こういう経緯だったのか / "SQLとは、その前進の名前 SEQUEL (Structured English Query Language)が示すとおり、英語を目指して作られ / 名前の由来が SEQUEL であるため、英語圏の方は未だにSQLを"シークェル"と発音される方が多く"
    リンク

  • Sparkのクエリ処理系と周辺の話題


    2015-4-28に東北大学 乾・岡崎研究室でおこなったチュートリアルの資料です。 研究室にはHadoopクラスタ︵CDH5.3︶があります。実験や実験の前処理といったタスクでそのクラスタを利用するためのチュートリアル、という前提です。 (追記)PMIの計算はもっと実行効率がいい手順があります。という説明を入れ忘れてました。 (追記)PMI計算でIntと書いてある部分は全部Longの間違いでした。
    Sparkのクエリ処理系と周辺の話題
    sh19910711
    sh19910711 2020/12/27
    2016/12
    リンク

  • 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

    On GraphQL-to-SQL

  • GitHub - ronsavage/SQL: BNF Grammars for SQL-92, SQL-99 and SQL-2003

    This repository contains the BNF (Backus-Naur Form) grammars for three versions of standard SQL — SQL-92, SQL-99 and SQL-2003. You should be able to find a version of this site with 'active HTML' at: https://ronsavage.github.io/SQL/ It may not be the most recent release, but the technical content is mostly valid. The download link is not functional — you can obtain the material for the latest rele

    GitHub - ronsavage/SQL: BNF Grammars for SQL-92, SQL-99 and SQL-2003

  • SQLアンチパターン - ナイーブツリー

    より詳細なCQRSに関する資料はこちら https://little-hands.hatenablog.com/entry/2019/12/02/cqrs 参考資料：http://little-hands.hatenablog.com/entry/jjug2017fall 社内新規プロダクトでDDD, CQRSの思想をベースとしたアーキテクチャを構築し、コマンド(更新系処理)ではSpring Data JPA(Hibernate)を、クエリ(参照系処理)ではjOOQを採用しました。 結果としてそれぞれのORMの良いところを生かした組み合わせのアーキテクチャが構築できたので、その経緯と得られた知見についてお話ししたいと思います。 以下のようなトピックを考えています。 ・CQRSの定義とメリットデメリット ・DDD,CQRSを検討するにあたってのORMの選定ポイント ・構築したアーキテクチャ

    SQLアンチパターン - ナイーブツリー

  • 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

    AWS、SQL互換の新問い合わせ言語「PartiQL」をオープンソースで公開。RDB、KVS、JSON、CSVなどをまとめて検索可能
  • 1 2 3 次のページ

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2024 Hatena. All Rights Reserved.