パスワードを忘れた? アカウント作成
13975676 story
データベース

AWSがSQL互換の新言語「PartiQL」を公開、RDB/KVS/JSON/CSV等を検索可能 46

ストーリー by hylom
どうでしょう 部門より

Anonymous Coward曰く、

Amazon Web ServicesがSQLと互換性のあるデータクエリ言語「PartiQL」を発表した(Publickey)。

KVSやJSONでも使えるというのは便利そうである。SQL界隈の地殻変動となるか?

構文はSQLをベースにしているが、さまざまなデータソースに対応し、JSONのような構造化データも扱えるのが特徴。仕様はGitHubで公開されている

  • by Anonymous Coward on 2019年08月06日 19時09分 (#3665032)

    SQLと互換性のあるってどういう意味?

    ここに返信
    • by Anonymous Coward

      難しくない文章だから読めるでしょ [partiql.org]

      PartiQL is backwards compatible with SQL-92.
      ...中略...
      the following SQL query
      ------------------------------

      SELECT e.id,
              e.name AS employeeName,
              e.title AS title
      FROM hr.employees e
      WHERE e.title = 'Dev Mgr'

      ------------------------------
      is also a valid PartiQL query. As we know from SQL, when this query operates on the table hr.employees it will return the result

      つまり、SQL92に対して、後方互換があり、
      SQL92に準拠し

      • by Anonymous Coward on 2019年08月06日 19時51分 (#3665058)

        日本語でおk

        • Re:いや読めよ (スコア:3, すばらしい洞察)

          by Anonymous Coward on 2019年08月06日 19時59分 (#3665063)

          お前にクエリ言語は要らない

        • by Anonymous Coward

          日本語だよ

        • by Anonymous Coward

          えっ?日本語でSQL文が記述できるんですか?

          • by Anonymous Coward

            仮に作ったとして需要はあるのだろうか?
            # 試験勉強そっちのけで、PEGについて勉強してたのでAC

          • by Anonymous Coward

            集合論の用語を使えば行けるでしょ?

            select 1 from dualは無理かもしれん。

      • by Anonymous Coward

        「PartiQLはSQLに最小限の拡張を行うものとする」という、乱暴に例えれば、ドラクエ3 → 4 みたいなものかな(たぶん違う)。
        NoSQL的な使い方もできる(拡張されている)ので、JSONとかCSVからも検索できる。
        でも、サーバーは使うみたいですね。だから、(C#の)LINQみたいなものとは違う。

        SQLはゴテゴテと色々付け加えすぎた気がするので、SQLを拡張するよりもむしろあまり使わない機能を削って整理してもらった方が個人的には嬉しかったかな。SQLiteでさえ、まだシンプルさに欠ける。

        個人的に一番欲しいのは、スマホ上で動かせるNoSQL。
        MongoDB Mobile はよ。

        • by Anonymous Coward on 2019年08月06日 23時51分 (#3665219)

          ...

          NoSQL的な使い方もできる(拡張されてる)
          =>バックエンドに関しては中立と言ってるだけで拡張云々は関係ない。
              もちろんSQLでもADODB や PostgreSQL の外部データCSVのように検索できるアダプタを作る事は出来る。

          でも、サーバーは使うみたいですね。
          =>言語仕様と実装を混同してる。そもそもGitHubにあるのはドキュメントだけ。
              バックエンドへのコンバートレイヤをプロセスにLink出来ないとは言ってない。

          SQLite さえ…
          => SQLite の Lite は言語仕様ではなく、クラサバではないプロセス埋め込みという意味のLite。

          スマホ上で動かせるNoSQL
          => サーバじゃないんだからアプリ上のMapを永続化すればいいだけ。

        • by Anonymous Coward

          > でも、サーバーは使うみたいですね。だから、(C#の)LINQみたいなものとは違う。

          LINQ はAPIでしかないので、ローカルデータに対しても使うし、サーバー経由の操作にも使うよ。

          > あまり使わない機能を削って整理してもらった方が個人的には嬉しかったかな。SQLiteでさえ、まだシンプルさに欠ける。

          SQL はシンプルである必要はないんですよ。
          リレーショナル完全な演算能力があることが存在価値の全てなんだから。

        • by Anonymous Coward

          androidのなかでSQLite動いてませんでしたっけ?

  • by Anonymous Coward on 2019年08月06日 19時46分 (#3665056)

    エロいな

    ここに返信
    • by Anonymous Coward

      ???

    • by Anonymous Coward

      パーティクルでしょ

      • by Anonymous Coward

        あれな、なんかシャンプーでツヤツヤして復活するやつだろ?

    • by Anonymous Coward

      パチモン [weblio.jp]のSQLやからパチキューエルやで。

      #本日の大喜利スレはここですか?

  • by Anonymous Coward on 2019年08月06日 20時24分 (#3665080)

    ので、セキュア第一だとどうなんだろ?

    ここに返信
  • by Anonymous Coward on 2019年08月06日 21時01分 (#3665107)

    SQLはクソ言語だし、今さら互換性を維持して色々するのは悪手だとは思う。
    まぁみんな使えるから価値はあるかな。
    が、現代風にクエリ言語を再設計するならどうすればいいだろうか。

    データベース側の処理を考えるとJsonやらXMLやらで命令文が記述できた方が処理しやすいだろうがさすがにそれは人間側が困る。
    各言語側でJavaのStreamやC#のLinq的な何かを実装するとして問い合わせは機械処理しやすい言語ってのもありかもな(現在もだけど名前を微妙に変えたりせずAPIは統一してほしい)。
    あんまり高度で表現性が高いとキャッシュやら高速化やらで困るのは目に見えてるのも難点。

    とりあえずいろんなデータで扱えるクエリ言語ってのは便利かもしれないな。
    良い普及したのがあればJavaScriptで標準で使えるようになりそうで便利な感じ。
    XMLならXPathあたりが…近いようで全然違うな。

    ここに返信
    • Re:SQLねぇ (スコア:2, 参考になる)

      by Anonymous Coward on 2019年08月06日 22時24分 (#3665168)

      AppleのCore Dataってのがあって、困ったことにSQLと似てない。
      学習しても他で使えるわけでもなく。
      SQL互換ってのは悪くない手だと思う。

    • by kmc55 (39216) on 2019年08月07日 3時39分 (#3665293) 日記

      伺いたいのですが、SQLってどの辺がクソ言語ですかね?

      いや、基本のSQL構文に各DBが好き勝手に色々やっててごちゃごちゃしてるのはありますが、
      データの取り扱いにおいて、シンプルな実装だと思ってるので。

      まあ、もう少し記号等でシンプルに表記できたりしてもいい気もしますが、自分も大分慣らされちゃったってことなのかな。

      • by Anonymous Coward

        とりあえず語順。fromを先にしてくれれば…。

        あとプログラム方面に振れるけど、一つ前のデータを使って計算したいとか度々あるので簡単に使用できる構文なり関数なり欲しい。
        サブクエリ作って行番号発行すればできるけど面倒。

        • Re:SQLねぇ (スコア:4, 参考になる)

          by kmc55 (39216) on 2019年08月07日 5時45分 (#3665309) 日記

          語順は、「普通の英語の構文」っぽいんですよね。
          Select [columns] from [Table]とUpdate [Table] set はたしかに昔よく間違えたかも。
          で、UpdateとInsertの文法も、まあ違う。

          英語だと考えれば、やりたいことが一番前に来るのはナチュラルだと思うんですよね。
          で、やりたいことの対象が目的語として次にくる。

          どうしても語順に馴染めない場合、配列やら構造体やらで事前にデータセット作って、SQL文は手で書かないような工夫をしたり、なんてのもいいかもです。
          (なんかこんな事言うとクソ言語を認めるみたいになってますが)

          「一つ前のデータ」のイメージがはっきり湧きませんが、DBって、データの順序とか気にして(保証されて)格納されてないイメージですけどね。(そういう開発したことないだけかな・・・)

          前後の行と連携させた処理の場合、AWKっぽい発想になっちゃいますね、自分は。

          • by albireo (7374) on 2019年08月07日 11時57分 (#3665532) ホームページ 日記

            BASICなんかもそうなんだけど英語構文に近い記述を目指すことに価値がないとは思わないですが、やりたいことが複雑になるとどんどんめんどくさくわかりにくくなるのは避けられないと思います。
            個人的には構文を自然言語に近づけることはあまり目指さない方がすっきりするし、かっこなどによって関係性や依存関係などがわかりやすいので好きですね。
            数式的な箇所ならともかく、サブクエリのようにかっこを使わないと書けない構文というのは「自然言語に近い構文」というポリシーを破壊して結局中途半端になってるという印象です。

            --
            うじゃうじゃ
          • by Anonymous Coward

            並び順が保証されないのはあくまでデータベースの話なので、並び順を指定したクエリならその並び方を利用して何か出来てもいい。
            日付順に並べたときの累計とかデータ変更されたときの強調表示(用のフラグ)とか。
            プログラム側で行えばいいのですけど、世の中にはデータを(SQLで)問い合わせて結果を表示するだけのアプリケーションというのがある。

            語順については、最近のシステムではインテリセンスが効くので問い合わせるターゲットを先に指定した方が便利。
            GUIタイプのシステムも、先にターゲットを指定してから列を指定するし。
            言語的には自然かもしれないけれど、開発とか分析とかには向かないよね。

          • by Anonymous Coward

            > 語順は、「普通の英語の構文」っぽいんですよね。

            普通の英語って、
            否定形の疑問に対する解答が「Is't it? → No. 」だろ?
            コンピュータで扱う文法として不適切な言語だよ。

            というか fromが先じゃないせいでクエリエディタの補完ができないのがクソだわ。

            • by Anonymous Coward

              > コンピュータで扱う文法として不適切な言語だよ。
              まったくです。

              「語順や文法が自然言語っぽい」というのは、
              コンピュータで扱う言語としては欠陥でしかない。

              サブルーチンなどが記述しにくく(できない?)、入れ子構造が巨大化し易いなどの問題もあるかも。
              #細かいことをいうなら、「DELETEでWHEREを忘れると……」というのはなんとかしてほしかった。

              ところで、SQLできちんとオートインデントが機能するエディタってありますか?
              それが実現しにくい(或いは不可能)だというのも、問題と言えば問題なアア.

              • by Anonymous Coward

                >ところで、SQLできちんとオートインデントが機能するエディタってありますか?
                >それが実現しにくい(或いは不可能)だというのも、問題と言えば問題なアア.

                クエリ書いて実行してくれるようなツールだと大抵補完してくれますよ。
                DB繫いでる前提ですが。

                補完したかったらselect * from xxxx as aみたいにまず書いてから直してけばselectの後ろも保管してくれます。

              • by Anonymous Coward

                > 補完したかったらselect * from xxxx as aみたいにまず書いてから直してけばselectの後ろも保管してくれます。

                多分、補完について書いてる奴はだいたいわかってると思うよ

                それが構造的欠陥だって話なんだよなぁ
                前から書いて補完が素直に効くほうが合理的じゃん

              • by Anonymous Coward

                > 前から書いて補完が素直に効くほうが合理的

                この主張は正しいけど、欠陥というほどでもないかな。query書くときはどうしてもfrom以降の内容 (whereとかgroup byとかjoinとか) に注意が行ってるから、とりあえず select * from まで書くのをすでに手が覚えてるし。

        • by Anonymous Coward

          > 一つ前のデータを使って計算したい

          window function はどう?

          • by Anonymous Coward

            だよね。元コメの人、ウィンドウ関数も知らないでSQLの批判してるんだ…と思っちゃった。

            • by Anonymous Coward

              MySQLには窓関数無かった時期が外より長かったので……

        • by Anonymous Coward

          fromが先のほうが補完機能を活用しやすいとは思います。

          しかしリレーショナルDBで1つ前のデータを使って計算が度々あるというのは感じたことはないですね。

          具体的にはどんなときでしょうか?

          • by Anonymous Coward

            ある順でソートしたレコードの1つ前との差分を計算するような場合って確かにありますけど、カーソル使えば普通にできるし、そんなに頻繁にそんなシチュエーションないと思う。

            • by Anonymous Coward

              window functionで簡単にできることをカーソルを使って書くとか勘弁して

          • by Anonymous Coward

            あまり具体的なことはかけないけど、例えばテーブルにユーザーの履歴が記録されているときに、それぞれのユーザーの変化を計算するときとかですかね。データ解析やっている人ならそういう計算が必要な機会がそこそこあるかと。

        • by Anonymous Coward

          サブクエリってそんな面倒なことしなきゃならんDBMSってまだあるの?
          そういう要求にはウィンドウ関数使うだろ。SQLiteだって対応してるのに。

          • by Anonymous Coward

            あるかないかで言ったらあるよ。古いバージョンのMariaDBとか。

      • by Anonymous Coward

        そのむかし SQLの構文はCより複雑なのだと書いてあるSQLの本かなにかがあった。

        Cを覚えたての自分はそのころCモドキをつくる修行中だったのだが、
        typedefの実装方法がまったく思いつかず音をあげていた。

        どう考えてもSQLのほうが簡単だよなと思う。

      • by Anonymous Coward

        SQL的構文でコレクションからデータを抽出できるLINQは可読性高くて良いと思うけどSQLそのものはいまいち読みづらい気がする。
        VBのソースでありがちなのはSQLで取ってきたデータを構造体の配列に詰めなおして、それをループで回して、VBのIf文で条件判断して、、、てやつ。SQLが真に可読性高くて使い勝手良かったらこんなことはしないと思うんだよね。

    • by Anonymous Coward

      SQLだけでシステムが組めないから汎用言語も使わないといけないのでは、と思うことがあります。
      ドメインロジックを表現できるだけの抽象化能力を持ったクエリ言語があれば、インピーダンスミスマッチだとかに頭を悩ませたり、プロジェクト毎に変わる「僕の考えた最強のアーキテクチャ」を読み込まなくても良くなるんじゃ、と思ったり。

      • by Anonymous Coward

        抽象化は性能や互換性で色々出ては消えた記憶が

        結局データにアクセスする根幹的な処理は
        枯れた普遍的な手法の方がいい
        他の箇所に労力を費やしたい

        • by Anonymous Coward

          いつまでも枯れた普遍的な手法を使い続けるのが多大な労力なんだが

          • by Anonymous Coward

            SQLを書くのが多大な苦労だという状況は、SQLだけで多くのことをやろうとしすぎなのでは?

    • by Anonymous Coward

      XPathは木構造の深い階層も簡単に掬える点がかなり強力だと思う。
      SQLベースだとそういうのは無理だろうな。JSONはそこまで深くするものじゃないのかもしれないが。

      まあ俺はデータ処理にはせっかくだからこの青いPowerShellを選ぶぜ。

typodupeerror

物事のやり方は一つではない -- Perlな人

読み込み中...