Relational DBをたくさん使って、利用可能な他のタイプに挑戦することにしました。
この特定の製品は見栄えが良く、有望です：http : //neo4j.org/
グラフベースのデータベースを使用した人はいますか？ユーザビリティの観点からの長所と短所は何ですか？
これらを本番環境で使用しましたか？それらを使用するように促した要件は何でしたか？
回答:
私は前の仕事でグラフデータベースを使用しました。私たちはneo4jを使用していませんでした。それはBerkeley DBの上に構築された社内のものでしたが、それは似ていました。それは生産で使用されました（まだ使用されています）。
グラフデータベースを使用した理由は、システムによって格納されているデータと、システムがデータに対して行った操作が、リレーショナルデータベースの弱点であり、グラフデータベースの強みであったためです。システムは、固定スキーマがなく、関係によってリンクされているオブジェクトのコレクションを格納する必要がありました。データを推論するために、システムは、グラフデータベースでの2、3のトラバーサルである多くの操作を実行する必要がありましたが、SQLでは非常に複雑なクエリになります。
グラフモデルの主な利点は、迅速な開発時間と柔軟性でした。既存の展開に影響を与えることなく、新しい機能をすばやく追加できました。潜在的な顧客が独自のデータの一部をインポートし、それをモデルの上に移植したい場合、通常、営業担当者が現場で行うことができます。また、新しい機能を設計するときに柔軟性が役立ち、新しいデータを厳密なデータモデルに詰め込む必要がなくなりました。
奇妙なデータベースがあれば、他の多くの奇妙なテクノロジーを構築でき、競合他社の製品と製品を区別するための多くの秘密のソースが得られます。
主な欠点は、標準のリレーショナルデータベーステクノロジを使用していないことでした。これは、顧客がエンタープライズの場合に問題になる可能性があります。私たちの顧客は、なぜ巨大なOracleクラスターでデータをホストできないのかと尋ねるでしょう（私たちの顧客は通常、大規模なデータセンターを持っていました）。チームの1つが実際にデータベースレイヤーを書き直してOracle（またはPostgreSQL、またはMySQL）を使用しましたが、元のデータベースよりも少し時間がかかりました。少なくとも1つの大企業がOracleのみのポリシーさえ持っていましたが、幸運にもOracleはBerkeley DBを購入しました。また、追加のツールをたくさん作成する必要がありました。たとえば、Crystal Reportsだけを使用することはできませんでした。
グラフデータベースのもう1つの欠点は、自分で作成したことです。つまり、問題（通常はスケーラビリティに関する問題）が発生したときに、自分で解決する必要がありました。リレーショナルデータベースを使用した場合、ベンダーはすでに10年前に問題を解決しているはずです。
企業顧客向けの製品を構築していて、データがリレーショナルモデルに適合している場合は、可能であればリレーショナルデータベースを使用してください。アプリケーションがリレーショナルモデルには適合しないが、グラフモデルには適合している場合は、グラフデータベースを使用します。それが他の何かにしか適合しない場合は、それを使用してください。
アプリケーションが現在のblubアーキテクチャに適合させる必要がない場合は、グラフデータベース、CouchDB、またはBigTable、またはアプリケーションに適合するものを使用してください。それはあなたにアドバンテージを与えるかもしれません、そして新しいものを試すのは楽しいです。
選択したものは何でも、データベースエンジンの構築が本当に好きでない限り、自分でデータベースエンジンを構築しないようにしてください。
私たちは1年以上にわたってNeoチームと協力しており、非常に満足しています。学術成果物とそれらの関係をグラフ化し、グラフデータベースにスポットを当て、ネットワーク上で推奨アルゴリズムを実行します。
すでにJavaで作業している場合、Neo4jを使用したモデリングは非常に単純であり、R / Wで試した他のどのソリューションよりもフラット/最速のパフォーマンスであると思います。
正直に言うと、私は苦労していない、それはそんなに簡単にホールドオブジェクトのプロパティとの関係に複雑なテーブル構造を設計するよりもだからグラフ/ネットワークの観点で考えると。
そうは言っても、単にSQLクエリを実行する方がビジネス側の方が簡単だからといって、MySQLにいくつかの情報を保存します。Neoで同じ機能を実行するには、今のところ帯域幅を持たないコードを記述する必要があります。でもすぐに、すべてのデータをNeoに移動します！
幸運を。
2つのポイント：
まず、SQL Serverで過去5年間使用していたデータについて、最近、実行する必要があるクエリのタイプ（ネストされたリレーションシップ...ご存知...グラフ）。私はneo4jをいじってみましたが、この種のルックアップが必要な場合、ルックアップ時間は数桁速くなります。
第2に、グラフデータベースが古くなっていることです。いいえ。初期の頃、人々はデータを効率的に保存および検索する方法を見つけようとしていたので、グラフとネットワークスタイルのデータベースモデルを作成して操作しました。これらは、物理モデルが論理モデルを反映するように設計されているため、効率はそれほど高くありませんでした。このタイプのデータ構造は、半構造化データには適していますが、構造化された高密度データには適していません。そのため、Coddという名前のこのIBMの男は、構造化データを配置および格納する効率的な方法を研究していて、リレーショナルデータベースモデルのアイデアを思いつきました。そしてそれは良かった、そして人々は幸せだった。
ここには何がありますか？2つの異なる目的のための2つのツール。グラフデータベースモデルは、半構造化データおよびエンティティ間の関係（存在する場合としない場合がある）を表すのに非常に適しています。リレーショナルデータベースは、非常に静的なスキーマがあり、結合の深さがそれほど深くない構造化データに適しています。1つは1種類のデータに適しており、もう1つは他の種類のデータに適しています。
フレーズを作り出すために、シルバー・ブレットはありません。グラフデータベースモデルは時代遅れであり、1つを使用すると、40年の進歩をもたらすと言うのは非常に短命です。それは、Cを使用することで、JavaやC＃などを取得するために経験したすべての技術的進歩をあきらめていると言うようなものです。それは本当ではありません。Cは、特定のタスクに必要なツールです。そしてJavaは他のタスクのためのツールです。
私は何年もMySQLを使用してエンジニアリングデータを管理してきましたが、うまく機能しましたが、私たちが抱えていた問題の1つ（ただし、気付いていなかった）は、常にスキーマを事前に計画する必要があったことです。私たちが知っていたもう1つの問題は、データをドメインオブジェクトにマッピングして戻すことでした。
これで、neo4jを試してみたところ、両方の問題が解決されたようです。各ノード（およびリレーション）に異なるプロパティを追加する機能により、データへのアプローチ全体を再考することができました。これは動的言語と静的言語（RubyとJava）に似ていますが、データベース用です。データベースでのデータモデルの構築は、はるかに俊敏で動的な方法で行うことができ、これによりコードが大幅に簡素化されます。
また、コード内のオブジェクトモデルは一般的にグラフ構造であるため、データベースからのマッピングも単純で、コードが少なく、結果としてバグが少なくなります。
さらに追加のボーナスとして、データをneo4jにロードするための最初のプロトタイプコードは、実際には以前のMySQLバージョンよりも高速に実行されます。（まだ）これについて明確な数字はありませんが、それは素晴らしい追加機能でした。
しかし結局のところ、選択はおそらくドメインモデルの性質に基づいているはずです。テーブルやグラフにうまくマッピングできますか？いくつかのプロトタイプを作成して決定し、データをロードして、それで遊んでください。ネオクリップを使用して、データのさまざまなビューを確認します。それを終えたら、うまくいけば、あなたが良いことをやっているかどうかを知っているでしょう。
会社でイントラネットを構築しています。
テーブル（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サイトでますます多くのデータを処理し始めており、そのリレーショナルデータベースはスケーリングしません。これらのニーズのために。