グラフベースのデータベース（http://neo4j.org/）の使用例は何ですか？
リレーショナルDBを頻繁に使用し、利用可能な他のタイプに挑戦することにしました。
この特定の製品は見栄えが良く、有望です： http://neo4j.org/
誰かがグラフベースのデータベースを使用しましたか？ユーザビリティの観点からの長所と短所は何ですか？
これらを実稼働環境で使用しましたか？それらを使用するように促した要件は何でしたか？
前の仕事でグラフデータベースを使用しました。 neo4jは使用していませんでした。これはBerkeley DBの上に構築された社内のものですが、似ていました。本番環境で使用されました（現在も使用されています）。
グラフデータベースを使用した理由は、システムによって保存されているデータと、システムがデータに対して行った操作が、リレーショナルデータベースの弱点であり、グラフデータベースの強点であったためです。システムは、固定スキーマがなく、関係によってリンクされているオブジェクトのコレクションを保存する必要がありました。データについて推論するために、システムは、グラフデータベースでの2回のトラバーサルになりますが、SQLでの非常に複雑なクエリになる多くの操作を行う必要がありました。
グラフモデルの主な利点は、迅速な開発時間と柔軟性でした。既存の展開に影響を与えることなく、新しい機能をすばやく追加できます。潜在的な顧客が自分のデータの一部をインポートし、それをモデルの上に移植したい場合、通常は営業担当者が現場で行うことができます。柔軟性は、新しい機能を設計するときにも役立ち、新しいデータをリジッドデータモデルに詰め込む手間を省くことができました。
奇妙なデータベースを持つことで、他の多くの奇妙な技術を構築し、製品を競合他社のものと区別するための秘密のソースをたくさん得ることができます。
主な欠点は、標準のリレーショナルデータベーステクノロジを使用していないことでした。これは、顧客が企業の場合に問題になる可能性があります。顧客は、なぜ巨大なOracleクラスターでデータをホストできないのかと尋ねます（通常、顧客は大規模なデータセンターを所有していました）。チームの1人は、実際にデータベースレイヤーを書き換えてOracle（またはPostgreSQL、MySQL）を使用しましたが、元のデータベースレイヤーよりも少し遅かったです。少なくとも1つの大企業でもOracleのみのポリシーがありましたが、幸いなことにOracleはBerkeley DBを購入しました。また、多くの追加ツールを作成する必要がありました。たとえば、Crystal Reportsを使用することはできませんでした。
グラフデータベースのもう1つの欠点は、それを自分で構築したことです。つまり、問題にぶつかったとき（通常はスケーラビリティ）、自分で解決する必要がありました。リレーショナルデータベースを使用した場合、ベンダーは10年前にすでに問題を解決していたでしょう。
企業顧客向けの製品を構築していて、データがリレーショナルモデルに適合する場合は、可能であればリレーショナルデータベースを使用します。アプリケーションがリレーショナルモデルに適合していないが、グラフモデルに適合している場合は、グラフデータベースを使用します。他の何かにしか当てはまらない場合は、それを使用します。
アプリケーションが現在のblubアーキテクチャに適合する必要がない場合は、グラフデータベース、CouchDB、BigTable、またはアプリに合ったものを使用してください。それはあなたに利点を与え、新しいことを試すのが楽しいかもしれません。
選択したものが何であれ、データベースエンジンの構築が本当に好きでない限り、データベースエンジンを自分で構築しないでください。
Neoチームとは1年以上働いており、非常に満足しています。学術成果物とそれらの関係をモデル化し、グラフdbにスポットを当て、ネットワーク上で推奨アルゴリズムを実行します。
すでにJavaで作業している場合、Neo4jを使用したモデリングは非常に簡単で、私たちが試した他のソリューションのR/Wに対して最も平坦で最速のパフォーマンスがあると思います。
正直に言うと、グラフ/ネットワークの観点から考えるのは難しいnotです。オブジェクトプロパティを保持するために、複雑なテーブル構造を設計するよりもはるかに簡単だからです。と関係。
そうは言っても、ビジネス側が簡単なSQLクエリを実行しやすいという理由だけで、MySQLにいくつかの情報を保存します。 Neoで同じ機能を実行するには、現在の帯域幅を持たないコードを記述する必要があります。ただし、すぐにすべてのデータをNeoに移動します！
がんばろう。
2つのポイント：
まず、過去5年間SQL Serverで作業してきたデータについて、最近、実行する必要のあるクエリの種類（ネストされた関係...グラフ... ）。私はneo4jで遊んでいますが、この種の検索が必要な場合、検索時間は数桁速くなります。
第二に、グラフデータベースが古くなっている点まで。いいえ。早い段階で、人々はデータを効率的に保存および検索する方法を見つけようとしていたため、グラフおよびネットワークスタイルのデータベースモデルを作成し、それを使用しました。これらは、物理モデルが論理モデルを反映するように設計されたため、効率はそれほど大きくありませんでした。このタイプのデータ構造は、半構造化データには適していましたが、構造化密集データには適していません。そのため、Coddという名前のこのIBM男は、構造化データを効率的に配置および保存する方法を研究しており、リレーショナルデータベースモデルのアイデアを思いつきました。そしてそれは良かったし、人々は幸せだった。
ここには何がありますか？ 2つの異なる目的のための2つのツール。グラフデータベースモデルは、半構造化データとエンティティ間の関係（存在する場合と存在しない場合）を表すのに非常に適しています。リレーショナルデータベースは、非常に静的なスキーマを持ち、結合の深さがあまり深くならない構造化データに適しています。 1つは1種類のデータに適し、もう1つは他の種類のデータに適しています。
フレーズを作成するために、Silver Bulletはありません。グラフデータベースモデルは時代遅れであり、それを使用することは40年の進歩をあきらめると言うのは非常に目が見えません。これは、Cを使用すると、JavaやC＃のようなものを取得するために行ったすべての技術的進歩をあきらめるということです。しかし、それは真実ではありません。そしてJavaは他のタスクのためのツールです。
私は何年もMySQLを使用してエンジニアリングデータを管理してきましたが、うまくいきましたが、私たちが抱えていた問題の1つは、スキーマを事前に計画しなければならないことでした。私たちが知っていたもう1つの問題は、データをドメインオブジェクトにマッピングし、逆にマッピングすることでした。
今、neo4jを試し始めたばかりで、両方の問題を解決しているようです。各ノード（および関係）に異なるプロパティを追加する機能により、データへのアプローチ全体を再考することができました。動的言語と静的言語（Ruby対Java）に似ていますが、データベース用です。データベースでのデータモデルの構築は、はるかに機敏で動的な方法で実行できます。これにより、コードが大幅に簡素化されます。
また、コード内のオブジェクトモデルは一般にグラフ構造であるため、データベースからのマッピングもより簡単で、コードが少なくなり、結果としてバグが少なくなります。
また、追加のボーナスとして、neo4jにデータをロードするための初期プロトタイプコードは、実際には以前のMySQLバージョンよりも高速に実行されます。これについてはまだはっきりした数字はありませんが、それはニースの追加機能でした。
しかし、結局のところ、選択は主にドメインモデルの性質に基づいている必要があります。テーブルやグラフにうまくマッピングできますか？いくつかのプロトタイプを実行して決定し、データをロードして、それを試してください。 neoclipseを使用して、データのさまざまなビューを確認します。それが終わったら、良いことをしているかどうかを知っていることを願っています。
会社でイントラネットを構築しています。
テーブル（Oracle、MySQL、SQL Server、Excel、Access、さまざまなランダムリスト）に保存されたデータをロードし、Neo4Jまたは他のグラフデータベースにロードする方法を理解することに興味があります。具体的には、共通のデータがシステムに既に存在する既存のデータと重複する場合に何が起こるか。
はい、一部のデータはRDBMSで最適にモデル化されていますが、いくつかの異なるテーブルを重ね合わせる必要がある場合、グラフモデルはテーブル構造よりも優れているという考えがあります。
たとえば、私は製造環境で働いています。私たちが取り組んでいる主要なプロジェクトがあり、複雑さのために、各部門は、左側の列に BOM（Bill Of Materials） 階層があり、次にいくつかの列がある個別のExcelスプレッドシートを作成しましたこれらのシートを作成した個人によって作成されたメモとチェックの。
したがって、問題の1つは、特定の部分で対処する必要があるすべての問題を誰かが見ることができるように、これらすべてのメモを1つの「ビュー」にマージすることです。
2番目の問題は、共通のコンポーネントが複数のサブアセンブリで使用されている場合、Excelスプレッドシートが階層BOMを表すのが面倒であることです。つまり、誰かがイグニッションサブアセンブリのP34リレーに関するメモを書いた場合、同じコメントをモータードライバーサブアセンブリで使用されるP34リレーに関連付ける必要があります。これは、Excelスプレッドシートでは発生しません。
会社のイントラネットでは、何でも簡単に検索できるようにしたいと考えています。部品番号、BOM構造、電話番号、電子メールアドレス、会社のポリシー、または手順に関連するデータなど。これを拡張して、コンピューターのハードウェア資産とインストールされたソフトウェアを管理したいです。
情報ネットワークにデータが入力され始めたら、「XYZプロジェクトに取り組んでいる全員にメールを書きたい」などのクールなトラバースを開始できると思います。 XYZプロジェクト内のデータの作成および変更としてタグ付けされるため、人々はプロジェクトに関連付けられます。したがって、XYZプロジェクトを検索キーとして使用することにより、XYZプロジェクトに関連するすべてのものを含む巨大なセットが作成されます。 XYZプロジェクトを構築した人々へのリンクを含みます。ユーザーのリンクはメールアドレスに接続します。したがって、XYZプロジェクトへの関与により、彼らは私のメールに含まれます。これは、プロジェクトで働いている人々のリストを維持しようとしている秘書とはまったく対照的です。多くのリストを生成します。リストを維持し、リストが最新であることを確認するのに多くの時間を費やしています。そして、そのほとんどは当社の製品に価値を追加しません。
別のクールなトラバーサルでは、特定のソフトウェアがインストールされているすべてのコンピューターをバージョンごとに報告できます。そのレポートを使用して、古いソフトウェアの余分なコピーを削除し、最新のコピーを必要とするユーザーを更新するタスクを生成できます。また、ライセンスの追跡にも役立ちます。
以下は、非リレーショナルデータベースが満たすニーズについて説明する良い記事です。 http://www.readwriteweb.com/enterprise/2009/02/is-the-relational-database-doomed.php
（名前は別として）リレーショナルデータベースには欠陥や誤りがないことを指摘するのに良い仕事をしており、最近は人々が主流のソフトウェアやWebサイトでますます多くのデータを処理し始めており、これらのニーズに応えます。