アカウント名:
パスワード:
SQLはクソ言語だし、今さら互換性を維持して色々するのは悪手だとは思う。まぁみんな使えるから価値はあるかな。が、現代風にクエリ言語を再設計するならどうすればいいだろうか。
データベース側の処理を考えるとJsonやらXMLやらで命令文が記述できた方が処理しやすいだろうがさすがにそれは人間側が困る。各言語側でJavaのStreamやC#のLinq的な何かを実装するとして問い合わせは機械処理しやすい言語ってのもありかもな(現在もだけど名前を微妙に変えたりせずAPIは統一してほしい)。あんまり高度で表現性が高いとキャッシュやら高速化やらで困るのは目に見えてるのも難点。
とりあえずいろんなデータで扱えるクエリ言語ってのは便利かもしれないな。良い普及したのがあればJavaScriptで標準で使えるようになりそうで便利な感じ。XMLならXPathあたりが…近いようで全然違うな。
伺いたいのですが、SQLってどの辺がクソ言語ですかね?
いや、基本のSQL構文に各DBが好き勝手に色々やっててごちゃごちゃしてるのはありますが、データの取り扱いにおいて、シンプルな実装だと思ってるので。
まあ、もう少し記号等でシンプルに表記できたりしてもいい気もしますが、自分も大分慣らされちゃったってことなのかな。
とりあえず語順。fromを先にしてくれれば…。
あとプログラム方面に振れるけど、一つ前のデータを使って計算したいとか度々あるので簡単に使用できる構文なり関数なり欲しい。サブクエリ作って行番号発行すればできるけど面倒。
fromが先のほうが補完機能を活用しやすいとは思います。
しかしリレーショナルDBで1つ前のデータを使って計算が度々あるというのは感じたことはないですね。
具体的にはどんなときでしょうか?
あまり具体的なことはかけないけど、例えばテーブルにユーザーの履歴が記録されているときに、それぞれのユーザーの変化を計算するときとかですかね。データ解析やっている人ならそういう計算が必要な機会がそこそこあるかと。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
SQLねぇ (スコア:0)
SQLはクソ言語だし、今さら互換性を維持して色々するのは悪手だとは思う。
まぁみんな使えるから価値はあるかな。
が、現代風にクエリ言語を再設計するならどうすればいいだろうか。
データベース側の処理を考えるとJsonやらXMLやらで命令文が記述できた方が処理しやすいだろうがさすがにそれは人間側が困る。
各言語側でJavaのStreamやC#のLinq的な何かを実装するとして問い合わせは機械処理しやすい言語ってのもありかもな(現在もだけど名前を微妙に変えたりせずAPIは統一してほしい)。
あんまり高度で表現性が高いとキャッシュやら高速化やらで困るのは目に見えてるのも難点。
とりあえずいろんなデータで扱えるクエリ言語ってのは便利かもしれないな。
良い普及したのがあればJavaScriptで標準で使えるようになりそうで便利な感じ。
XMLならXPathあたりが…近いようで全然違うな。
Re: (スコア:2)
伺いたいのですが、SQLってどの辺がクソ言語ですかね?
いや、基本のSQL構文に各DBが好き勝手に色々やっててごちゃごちゃしてるのはありますが、
データの取り扱いにおいて、シンプルな実装だと思ってるので。
まあ、もう少し記号等でシンプルに表記できたりしてもいい気もしますが、自分も大分慣らされちゃったってことなのかな。
Re: (スコア:0)
とりあえず語順。fromを先にしてくれれば…。
あとプログラム方面に振れるけど、一つ前のデータを使って計算したいとか度々あるので簡単に使用できる構文なり関数なり欲しい。
サブクエリ作って行番号発行すればできるけど面倒。
Re: (スコア:0)
fromが先のほうが補完機能を活用しやすいとは思います。
しかしリレーショナルDBで1つ前のデータを使って計算が度々あるというのは感じたことはないですね。
具体的にはどんなときでしょうか?
Re:SQLねぇ (スコア:0)
あまり具体的なことはかけないけど、例えばテーブルにユーザーの履歴が記録されているときに、それぞれのユーザーの変化を計算するときとかですかね。データ解析やっている人ならそういう計算が必要な機会がそこそこあるかと。