FrankenQueries：SQLとNoSQLが衝突するとき

IBM pureXMLは、リレーショナル（SQL / XML）と非構造化（XQuery）の両方のクエリ言語を提供するリレーショナルメカニズム（パン用に設計）に基づいて構築された独自のXMLデータベースであり、MarkLogicはから構築されたデータベースです非構造化データを理解し、非構造化クエリ言語（XQuery）を提供する新しいデータベースパラダイム（必要に応じてNoSQLと呼びます）に基づいてスクラッチします。

もう1つの重要な情報は、SQL（またはSQLのようなインターフェイス）を実装するためのNoSQLデータベースプロバイダー間の新しいトレンドです。例としては、CQLまたはHadoopに基づくさらに成熟したSQLインターフェイスを使用したCassandraの最近のプロモーションがあります。

2つの世界が衝突するとき

NoSQL aboutNoSQL。私にとって、これは、データベースへのさまざまなインターフェースを探求する可能性がある（そして政治的正しさを気にしない）非リレーショナルデータベースの代替案に重点を移すことを意味します。これは良いことです！ビジネス向けSQLの弱点を盲目的に認めますか？ええと、SQLがあなたの製品にとって正しい選択であるとしても、あなたはそれでも結果について考え、物事が2つの世界の間でうまく整合していることを確認する必要があります。言い換えれば、それは「ブラインド」部分を取り除き、「ラメ」を開発者にとって許容できる最小限に減らすことを意味します。

データモデル

リレーショナルでは：

RowSet-> SQL-> RowSet

RowSetは次のようなものです：

RowSet-> Item +
アイテム->INT| VARCHAR n | ...

XPathデータモデルについて説明します：

XDM-> XPath / XQuery-> XDM

そしてXDMはそのようなものです：

XDM->アイテム+
アイテム->AtomicType|ツリー
AtomicType->整数|文字列| ...
...

 
 （どちらも単純化されていますが、目的を果たします）。
 
 ドキュメントのデータモデルの特徴は、木が平らではないことです。
  
 { 
  "namespace"： "person-2.0"、 
  "comments"： "この男は私に恐竜のステッカーを求めました。なんてこった！"、 
  "person"：{ 
  "handle"： "dscape"、 
  "comments"："迷惑メールを送信しないでください。" 
 } 
 } 
 
 
 したがって、これが何を意味するかについては多くの解釈があります。
  
  SELECT comment from PERSON where handle ="dscape"  
 
 
 リクエストは「コメント」のどの要素を参照していますか？ SQL / XMLを見ると、クエリは次のようになります。
  
  SELECT XMLQuery（'$ person / projects'） 
  FROM PERSON  
  WHERE XMLExists（'$ person / person / handle'） 
 
 
 これは、この明らかな結論につながります。木にはナビゲートする方法が必要です。 XMLではXPath、JSONではJSONSelect、あるいは他の何かである可能性があります。ただし、そもそも標準のナビゲーション方法が必要です。
 
 このタスクをさらに面白くするのは、バージョン管理と回路開発です。 これはリレーショナルの世界では長年無視されてきたという事実にもかかわらず（テーブル変更のこれらの面白い瞬間のダウンタイムのためにビジネスに深刻な結果をもたらします）。 、これは確かにドキュメントでは無視されるべきではありません。 Microsoft Wordについて考えてみてください–それらはいくつの異なるバージョンのドキュメントをサポートしていますか？ Word 2003、2005など
 
 スキーマ、柔軟性、構造化されていないものはありません。単語を選択してください。ただし、それらはすべてデータ形式の急速な進化の影響を受けます。このクエリでは、記述子が人間の子であり、私がばかであるというコメントがツリーの直接の子孫であると想定しています。 これは確かに変わるでしょう。また、SQLはドキュメントのバージョン管理をサポートしていないため、SQLを機能させるには拡張する必要があります。 
 
 非構造化データの実際のクエリ言語では、バージョンを考慮に入れる必要があります。 XQueryでは、このクエリを次のように表現できます。
  
  declare namespace p ="person-2.0";  
 
  for $ person in collection（'person'） 
  let $ comments-on-person：=$ person / p：comments  
  where $ person / p：handle ="dscape"  
  return $ comments-on-person  
 
 フランケンクエリ、たとえば
 
 誰かが私を（SQL / XMLについて話している）これらのフランケンクエリとして言及したことがあります。これまでのところ、この用語は頭に残っています。 この例えをもう少し詳しく見て、有機部品とボルトが一緒になる場所を探しましょう。
 
 ジョー用とメアリー用の2つのショッピングリストを提示しましょう。
  
  marys-shopping.json  
  {"fruit"：{ 
  "apples"：2  
 }、 "apples"：5}  
 
  joes-shopping.json  
  {"fruit"：{ 
  "apples"：6、 
  "oranges"：1  
 }}  
 
 
 「架空の」SQL/JSON拡張機能を使用して、次のことを行います。
  
  SELECT apples  
  FROM LISTS  
 
 
 それは何を返しますか？ RowSetが入り、RowSetが出るのを覚えていますか？
  
  2、5  
 --- 
  6  
 
 
 したがって、アップルの番号のリストを明示的に要求した場合でも、3つではなく2つの行のセットを取得し、行のセットの1つに番号のリストが含まれます。代わりに3つを返すことを選択した場合、2つのRowSetセットと3つのRowSetセットを取得します。 私は数学者ではありませんが、それは良くありません。 
 
 繰り返しになりますが、非構造化情報を処理する可能性のあるものを使用する場合は問題ありません。 javascriptではこの問題は発生せず、もちろんXQueryでも発生しません。 javascriptとXQueryの両方で、それはすべて有機的です。
 結論：非構造化データ、ユニコーン、ピクシーダストのための素晴らしい言語！
 
  XQueryは非構造化情報のための優れた言語ですが、ここでの私の見解はその使用を保護していません。 私が強調しようとしているのは、どのように（開発者が）選択したとしても、非構造化データ用の実際の言語の必要性です。
 
 しかし、私はあなた（開発者）に「不完全なSQL」を取り戻さないようにお願いします。彼女は去りました、そしてあなたはNoSQLと呼ばれる新しい暑い日を持っています。少し時間をとってください。そうすれば、それはあなたの上で成長します。また、データベースで機能するJavaScriptコードを作成するのも非常に楽しいです。データベースにコードを奪わせないでください。
 
 非構造化データのSQLは失敗します。そうすると、非構造化データのPL-SQLは失敗します。 したがって、ベンダーが必要なものを主張する場合は、完全なプログラミング言語以外のものを受け入れないでください。完全なアプリケーションをjavascriptで記述してCouchAppに保存するか、完全なアプリケーションをXQueryで記述してMarkLogicに保存することができます。 。そしてそうあるべきです！
 
 非構造化情報のクエリ言語で何を探すべきかについてのチェックリストは次のとおりです。
  ナビゲーションの言語
 データモデル
 通常の表現
 ラムダ
 高次の機能
 機能的な香り
 優れたライン処理
 独自のライブラリを作成できるようにするためのモジュール
 アプリケーションサーバーは認識しています：RESTを提供する機能があります
 
 
 このアドバイスは無視してもかまいませんが、最終的には、Silverlight開発者に不満を感じるかもしれません。そして、データベースの革新を好む私たち、開発者が戻ることを決めたことに失望するでしょう！
 SQLとNoSQLの説明