AWSがSQL互換の新言語「PartiQL」を公開、RDB/KVS/JSON/CSV等を検索可能 46
ストーリー by hylom
どうでしょう 部門より
どうでしょう 部門より
Anonymous Coward曰く、
Amazon Web ServicesがSQLと互換性のあるデータクエリ言語「PartiQL」を発表した（Publickey）。
KVSやJSONでも使えるというのは便利そうである。SQL界隈の地殻変動となるか？
構文はSQLをベースにしているが、さまざまなデータソースに対応し、JSONのような構造化データも扱えるのが特徴。仕様はGitHubで公開されている。
記事読まずにすまん (スコア:0)
SQLと互換性のあるってどういう意味？
いや読めよ (スコア:0)
難しくない文章だから読めるでしょ [partiql.org]
つまり、SQL92に対して、後方互換があり、
SQL92に準拠し
Re:いや読めよ (スコア:1)
日本語でおk
Re:いや読めよ (スコア:3, すばらしい洞察)
お前にクエリ言語は要らない
Re: (スコア:0)
日本語だよ
Re: (スコア:0)
えっ？日本語でSQL文が記述できるんですか？
Re: (スコア:0)
仮に作ったとして需要はあるのだろうか？
# 試験勉強そっちのけで、PEGについて勉強してたのでAC
Re: (スコア:0)
集合論の用語を使えば行けるでしょ？
select 1 from dualは無理かもしれん。
Re: (スコア:0)
「PartiQLはSQLに最小限の拡張を行うものとする」という、乱暴に例えれば、ドラクエ3 → 4 みたいなものかな(たぶん違う)。
NoSQL的な使い方もできる(拡張されている)ので、JSONとかCSVからも検索できる。
でも、サーバーは使うみたいですね。だから、(C＃の)LINQみたいなものとは違う。
SQLはゴテゴテと色々付け加えすぎた気がするので、SQLを拡張するよりもむしろあまり使わない機能を削って整理してもらった方が個人的には嬉しかったかな。SQLiteでさえ、まだシンプルさに欠ける。
個人的に一番欲しいのは、スマホ上で動かせるNoSQL。
MongoDB Mobile はよ。
Re:いや読めよ (スコア:1)
...
NoSQL的な使い方もできる（拡張されてる)
=>バックエンドに関しては中立と言ってるだけで拡張云々は関係ない。
もちろんSQLでもADODB や PostgreSQL の外部データCSVのように検索できるアダプタを作る事は出来る。
でも、サーバーは使うみたいですね。
=>言語仕様と実装を混同してる。そもそもGitHubにあるのはドキュメントだけ。
バックエンドへのコンバートレイヤをプロセスにLink出来ないとは言ってない。
SQLite さえ…
=> SQLite の Lite は言語仕様ではなく、クラサバではないプロセス埋め込みという意味のLite。
スマホ上で動かせるNoSQL
=> サーバじゃないんだからアプリ上のMapを永続化すればいいだけ。
Re: (スコア:0)
> でも、サーバーは使うみたいですね。だから、(C＃の)LINQみたいなものとは違う。
LINQ はAPIでしかないので、ローカルデータに対しても使うし、サーバー経由の操作にも使うよ。
> あまり使わない機能を削って整理してもらった方が個人的には嬉しかったかな。SQLiteでさえ、まだシンプルさに欠ける。
SQL はシンプルである必要はないんですよ。
リレーショナル完全な演算能力があることが存在価値の全てなんだから。
Re: (スコア:0)
androidのなかでSQLite動いてませんでしたっけ？
パンチラ？ (スコア:0)
エロいな
Re: (スコア:0)
？？？
Re: (スコア:0)
パーティクルでしょ
Re: (スコア:0)
あれな、なんかシャンプーでツヤツヤして復活するやつだろ？
Re: (スコア:0)
パチモン [weblio.jp]のSQLやからパチキューエルやで。
#本日の大喜利スレはここですか？
使いやすい≒攻撃ベクターが広い (スコア:0)
ので、セキュア第一だとどうなんだろ？
SQLねぇ (スコア:0)
SQLはクソ言語だし、今さら互換性を維持して色々するのは悪手だとは思う。
まぁみんな使えるから価値はあるかな。
が、現代風にクエリ言語を再設計するならどうすればいいだろうか。
データベース側の処理を考えるとJsonやらXMLやらで命令文が記述できた方が処理しやすいだろうがさすがにそれは人間側が困る。
各言語側でJavaのStreamやC#のLinq的な何かを実装するとして問い合わせは機械処理しやすい言語ってのもありかもな(現在もだけど名前を微妙に変えたりせずAPIは統一してほしい)。
あんまり高度で表現性が高いとキャッシュやら高速化やらで困るのは目に見えてるのも難点。
とりあえずいろんなデータで扱えるクエリ言語ってのは便利かもしれないな。
良い普及したのがあればJavaScriptで標準で使えるようになりそうで便利な感じ。
XMLならXPathあたりが…近いようで全然違うな。
Re:SQLねぇ (スコア:2, 参考になる)
AppleのCore Dataってのがあって、困ったことにSQLと似てない。
学習しても他で使えるわけでもなく。
SQL互換ってのは悪くない手だと思う。
Re:SQLねぇ (スコア:2)
伺いたいのですが、SQLってどの辺がクソ言語ですかね？
いや、基本のSQL構文に各DBが好き勝手に色々やっててごちゃごちゃしてるのはありますが、
データの取り扱いにおいて、シンプルな実装だと思ってるので。
まあ、もう少し記号等でシンプルに表記できたりしてもいい気もしますが、自分も大分慣らされちゃったってことなのかな。
Re: (スコア:0)
とりあえず語順。fromを先にしてくれれば…。
あとプログラム方面に振れるけど、一つ前のデータを使って計算したいとか度々あるので簡単に使用できる構文なり関数なり欲しい。
サブクエリ作って行番号発行すればできるけど面倒。
Re:SQLねぇ (スコア:4, 参考になる)
語順は、「普通の英語の構文」っぽいんですよね。
Select [columns] from [Table]とUpdate [Table] set はたしかに昔よく間違えたかも。
で、UpdateとInsertの文法も、まあ違う。
英語だと考えれば、やりたいことが一番前に来るのはナチュラルだと思うんですよね。
で、やりたいことの対象が目的語として次にくる。
どうしても語順に馴染めない場合、配列やら構造体やらで事前にデータセット作って、SQL文は手で書かないような工夫をしたり、なんてのもいいかもです。
（なんかこんな事言うとクソ言語を認めるみたいになってますが)
「一つ前のデータ」のイメージがはっきり湧きませんが、DBって、データの順序とか気にして（保証されて）格納されてないイメージですけどね。(そういう開発したことないだけかな・・・）
前後の行と連携させた処理の場合、AWKっぽい発想になっちゃいますね、自分は。
Re:SQLねぇ (スコア:1)
BASICなんかもそうなんだけど英語構文に近い記述を目指すことに価値がないとは思わないですが、やりたいことが複雑になるとどんどんめんどくさくわかりにくくなるのは避けられないと思います。
個人的には構文を自然言語に近づけることはあまり目指さない方がすっきりするし、かっこなどによって関係性や依存関係などがわかりやすいので好きですね。
数式的な箇所ならともかく、サブクエリのようにかっこを使わないと書けない構文というのは「自然言語に近い構文」というポリシーを破壊して結局中途半端になってるという印象です。
うじゃうじゃ
Re: (スコア:0)
並び順が保証されないのはあくまでデータベースの話なので、並び順を指定したクエリならその並び方を利用して何か出来てもいい。
日付順に並べたときの累計とかデータ変更されたときの強調表示(用のフラグ)とか。
プログラム側で行えばいいのですけど、世の中にはデータを(SQLで)問い合わせて結果を表示するだけのアプリケーションというのがある。
語順については、最近のシステムではインテリセンスが効くので問い合わせるターゲットを先に指定した方が便利。
GUIタイプのシステムも、先にターゲットを指定してから列を指定するし。
言語的には自然かもしれないけれど、開発とか分析とかには向かないよね。
Re: (スコア:0)
> 語順は、「普通の英語の構文」っぽいんですよね。
普通の英語って、
否定形の疑問に対する解答が「Is't it? → No. 」だろ？
コンピュータで扱う文法として不適切な言語だよ。
というか fromが先じゃないせいでクエリエディタの補完ができないのがクソだわ。
Re: (スコア:0)
＞ コンピュータで扱う文法として不適切な言語だよ。
まったくです。
「語順や文法が自然言語っぽい」というのは、
コンピュータで扱う言語としては欠陥でしかない。
サブルーチンなどが記述しにくく（できない？）、入れ子構造が巨大化し易いなどの問題もあるかも。
＃細かいことをいうなら、「DELETEでWHEREを忘れると……」というのはなんとかしてほしかった。
ところで、SQLできちんとオートインデントが機能するエディタってありますか？
それが実現しにくい（或いは不可能）だというのも、問題と言えば問題なアア.
Re: (スコア:0)
>ところで、SQLできちんとオートインデントが機能するエディタってありますか？
>それが実現しにくい（或いは不可能）だというのも、問題と言えば問題なアア.
クエリ書いて実行してくれるようなツールだと大抵補完してくれますよ。
DB繫いでる前提ですが。
補完したかったらselect * from xxxx as aみたいにまず書いてから直してけばselectの後ろも保管してくれます。
Re: (スコア:0)
> 補完したかったらselect * from xxxx as aみたいにまず書いてから直してけばselectの後ろも保管してくれます。
多分、補完について書いてる奴はだいたいわかってると思うよ
それが構造的欠陥だって話なんだよなぁ
前から書いて補完が素直に効くほうが合理的じゃん
Re: (スコア:0)
> 前から書いて補完が素直に効くほうが合理的
この主張は正しいけど、欠陥というほどでもないかな。query書くときはどうしてもfrom以降の内容 (whereとかgroup byとかjoinとか) に注意が行ってるから、とりあえず select * from まで書くのをすでに手が覚えてるし。
Re: (スコア:0)
> 一つ前のデータを使って計算したい
window function はどう？
Re: (スコア:0)
だよね。元コメの人、ウィンドウ関数も知らないでSQLの批判してるんだ…と思っちゃった。
Re: (スコア:0)
MySQLには窓関数無かった時期が外より長かったので……
Re: (スコア:0)
fromが先のほうが補完機能を活用しやすいとは思います。
しかしリレーショナルDBで１つ前のデータを使って計算が度々あるというのは感じたことはないですね。
具体的にはどんなときでしょうか？
Re: (スコア:0)
ある順でソートしたレコードの1つ前との差分を計算するような場合って確かにありますけど、カーソル使えば普通にできるし、そんなに頻繁にそんなシチュエーションないと思う。
Re: (スコア:0)
window functionで簡単にできることをカーソルを使って書くとか勘弁して
Re: (スコア:0)
あまり具体的なことはかけないけど、例えばテーブルにユーザーの履歴が記録されているときに、それぞれのユーザーの変化を計算するときとかですかね。データ解析やっている人ならそういう計算が必要な機会がそこそこあるかと。
Re: (スコア:0)
サブクエリってそんな面倒なことしなきゃならんDBMSってまだあるの？
そういう要求にはウィンドウ関数使うだろ。SQLiteだって対応してるのに。
Re: (スコア:0)
あるかないかで言ったらあるよ。古いバージョンのMariaDBとか。
Re: (スコア:0)
そのむかし SQLの構文はCより複雑なのだと書いてあるSQLの本かなにかがあった。
Cを覚えたての自分はそのころＣモドキをつくる修行中だったのだが、
typedefの実装方法がまったく思いつかず音をあげていた。
どう考えてもSQLのほうが簡単だよなと思う。
Re: (スコア:0)
SQL的構文でコレクションからデータを抽出できるLINQは可読性高くて良いと思うけどSQLそのものはいまいち読みづらい気がする。
VBのソースでありがちなのはSQLで取ってきたデータを構造体の配列に詰めなおして、それをループで回して、VBのIf文で条件判断して、、、てやつ。SQLが真に可読性高くて使い勝手良かったらこんなことはしないと思うんだよね。
Re: (スコア:0)
SQLだけでシステムが組めないから汎用言語も使わないといけないのでは、と思うことがあります。
ドメインロジックを表現できるだけの抽象化能力を持ったクエリ言語があれば、インピーダンスミスマッチだとかに頭を悩ませたり、プロジェクト毎に変わる「僕の考えた最強のアーキテクチャ」を読み込まなくても良くなるんじゃ、と思ったり。
Re: (スコア:0)
抽象化は性能や互換性で色々出ては消えた記憶が
結局データにアクセスする根幹的な処理は
枯れた普遍的な手法の方がいい
他の箇所に労力を費やしたい
Re: (スコア:0)
いつまでも枯れた普遍的な手法を使い続けるのが多大な労力なんだが
Re: (スコア:0)
SQLを書くのが多大な苦労だという状況は、SQLだけで多くのことをやろうとしすぎなのでは？
Re: (スコア:0)
XPathは木構造の深い階層も簡単に掬える点がかなり強力だと思う。
SQLベースだとそういうのは無理だろうな。JSONはそこまで深くするものじゃないのかもしれないが。
まあ俺はデータ処理にはせっかくだからこの青いPowerShellを選ぶぜ。