OrientDBユーザーズマニュアルのSQL Query on a NoSQL database
2956 ワード
前節では、OrientDBの基本概念をいくつか参照し、SQL言語をサポートする議論が最も多かったことについて説明しました.Is not a contradiction for a DBMS that is defined NoSQL embrace this standard?Maybe not.
くだらないことをたくさん言って、ひっくり返すのがおっくうで、时間を浪費して、私もあまり理解していません.
We defined in the introductory movement NoSQL not as something contrary to SQL itself, but as the warning "use the DBMS right for your use case. So why support its SQL ? Incidentally the relational model is very different from the graph and very far from the concepts of schema-less document database.
The answer is simple: anyone reading this know SQL because it has been the predominant technology in the last 30 years. Rather than inventing Yet Another Language I thought from ancient SQL would be a good idea to allow anyone to use OrientDB from day one.
Obviously the standard SQL language has no concept of schema-less, trees or graphs because it was designed for a model that does not cover this kind of structures, if not purely through adaptation applications. To support these new paradigms are created for new entrants and an extended syntax.
では、バインドされたプレゼンテーションデータベースを使用します.コンソール(前の章を参照)を開き、コンピュータのデータベースdemoに接続します.実行:select*from city(リレーショナル・データベースでCityテーブルのすべてのレコードを検索するように).
次に、複数の接続のレコードを含む条件付きクエリーを作成します.関係世界ではマルチテーブル間のjoin,but the links are directly OrientDB waterwaysである.次に、その実装方法を示します.
この例では、このクエリは「Italy」という名前の都市を返します.簡単で、迅速で、簡潔です.より複雑なクエリーを想像し、その条件はより多くのレコードに関連しています.等価な関係クエリーは非常に長く、読みにくいが、OrientDBを使うと、すべてのことが簡単で読みやすい.Projections(キーワード「SELECT」と「FROM」の間の、この例では「*」)を省略すると、OrientDBは常にすべてのレコードを返します.例:
E 'can also navigate through records in the projections, useful if you do affect, not as a result the current class, but connected elements.例えば、Addressタイプの記録からイタリアの最初の3つの都市の名前を抽出したい場合は、次のようにします.
limit句3は、コンストレイント結果が3つの要素であることに注意してください.接続(LINK)については、Collectionなどの複雑なタイプを使用して、リストやコレクションとして設計する方法を見てみましょう.この2つの違いは、リストが位置順に並べられた要素の順序を維持し、重複を許容することであるが、集合中に重複があってはならず、ソートは任意である【くだらない話の山、実はリストは秩序正しく重複しており、Setは無秩序で重複している】.次の例では、複数のアドレスを含むアカウントを試してみたいと思います.「addresses」プロパティは、1-N(1対複数)の関係を記述するAddressタイプレコードを含む集合です.リレーショナル・データベースには外部キーが必要で、OrientDBは参照セット(または接続)を使用します.
size()操作は、使用可能な操作の1つです.次のセクションでは、他のより詳細なコレクションとマッピング操作について説明します.ここでは、このセクションをより複雑な例で終わります.すべてのアドレスが「Washington」のアカウント(addressesはAddressのcollection)であることを検索します.
この例ではcontainsで動作し、collection内のすべての要素にかっこ内の条件を実行し、最終的に1つ(以上)の要素が条件を満たすとTRUEに戻る.flatten()操作は、すべての結果のcollectionを抽出し、すべて1つのcollectionに配置して、より簡単にします.
くだらないことをたくさん言って、ひっくり返すのがおっくうで、时間を浪費して、私もあまり理解していません.
We defined in the introductory movement NoSQL not as something contrary to SQL itself, but as the warning "use the DBMS right for your use case. So why support its SQL ? Incidentally the relational model is very different from the graph and very far from the concepts of schema-less document database.
The answer is simple: anyone reading this know SQL because it has been the predominant technology in the last 30 years. Rather than inventing Yet Another Language I thought from ancient SQL would be a good idea to allow anyone to use OrientDB from day one.
Obviously the standard SQL language has no concept of schema-less, trees or graphs because it was designed for a model that does not cover this kind of structures, if not purely through adaptation applications. To support these new paradigms are created for new entrants and an extended syntax.
では、バインドされたプレゼンテーションデータベースを使用します.コンソール(前の章を参照)を開き、コンピュータのデータベースdemoに接続します.実行:select*from city(リレーショナル・データベースでCityテーブルのすべてのレコードを検索するように).
> select * from city次に、複数の接続のレコードを含む条件付きクエリーを作成します.関係世界ではマルチテーブル間のjoin,but the links are directly OrientDB waterwaysである.次に、その実装方法を示します.
> select * from city where country.name = 'Italy'この例では、このクエリは「Italy」という名前の都市を返します.簡単で、迅速で、簡潔です.より複雑なクエリーを想像し、その条件はより多くのレコードに関連しています.等価な関係クエリーは非常に長く、読みにくいが、OrientDBを使うと、すべてのことが簡単で読みやすい.Projections(キーワード「SELECT」と「FROM」の間の、この例では「*」)を省略すると、OrientDBは常にすべてのレコードを返します.例:
> select from cityE 'can also navigate through records in the projections, useful if you do affect, not as a result the current class, but connected elements.例えば、Addressタイプの記録からイタリアの最初の3つの都市の名前を抽出したい場合は、次のようにします.
> select city.name from address where city.country.name = 'Italy' limit 3limit句3は、コンストレイント結果が3つの要素であることに注意してください.接続(LINK)については、Collectionなどの複雑なタイプを使用して、リストやコレクションとして設計する方法を見てみましょう.この2つの違いは、リストが位置順に並べられた要素の順序を維持し、重複を許容することであるが、集合中に重複があってはならず、ソートは任意である【くだらない話の山、実はリストは秩序正しく重複しており、Setは無秩序で重複している】.次の例では、複数のアドレスを含むアカウントを試してみたいと思います.「addresses」プロパティは、1-N(1対複数)の関係を記述するAddressタイプレコードを含む集合です.リレーショナル・データベースには外部キーが必要で、OrientDBは参照セット(または接続)を使用します.
> select from account where addresses.size() > 0size()操作は、使用可能な操作の1つです.次のセクションでは、他のより詳細なコレクションとマッピング操作について説明します.ここでは、このセクションをより複雑な例で終わります.すべてのアドレスが「Washington」のアカウント(addressesはAddressのcollection)であることを検索します.
> select flatten(addresses) from Account where addresses contains ( city.country.name = 'Washington' )この例ではcontainsで動作し、collection内のすべての要素にかっこ内の条件を実行し、最終的に1つ(以上)の要素が条件を満たすとTRUEに戻る.flatten()操作は、すべての結果のcollectionを抽出し、すべて1つのcollectionに配置して、より簡単にします.