彼のデータモデルが有向非巡回グラフであることを理解しているクライアントがいます。ノードのコレクションとエッジの中間テーブルを使用して作業してきましたが、パフォーマンスはかなり良好です。現在の実装では、データノードは100,000未満ですが、1桁または2桁大きくなる可能性があります。彼は最近、グラフがあるので、グラフデータベース（Neo4JやTitanなど）の方が「優れている」と確信しています。
グラフ指向データベースが実際に解決する問題のうち、SQLでは解決できない問題、またはSQLクライアントからのより多くの負担が必要な問題は何ですか？私が見ることができることから、パスの発見はそれであるように見えます、しかしそれは全体の話ではありえません。
リレーショナルデータベースでは、ノードとエッジは、共通の値によって関連付けられます。ノードまたはエッジの検索には、通常、この値のインデックスのクエリが含まれます。
グラフデータベースでは、ノードとエッジは、リレーショナルデータベースがインデックスの内部構造を維持するために使用するのと同じ種類の内部データベース構造によって直接関連付けられます。したがって、ノードからエッジを見つけること、またはエッジからノードを見つけることは、ノードの数に関係なく、リレーショナルインデックスの1レベル深くなることに似ています。一方、リレーショナルデータベースに数百万のノードがある場合、インデックスは数レベルの深さになります。
実際には、mongoに「geospacial」データベース機能が組み込まれているのと同じように、mysqlで実行したい場合ほど処理する必要はありません。あなたが言及した2つのデータベース（iveはtitanで動作しました）はグラフ化にちょうど優れており、phpまたはdbステートメントにそれほど厳しいものではありません。
要するに、壊れていなければ直さないでください。利点があなたやあなたのクライアントにとって明確でない場合は、グラフデータベースのこの不明確な利点に対して移行のコストを比較検討してください。
前述のグラフデータベースの経験がないので、そのようなデータベースから得られるものは、データベースがあなたの持っているデータのタイプにより適しているので、より速い開発であると私は推測することができます。私はMongoDBを頻繁に使用してきましたが、データベースへのクエリ/書き込みが簡単なため、開発速度が向上し、スキーマを定義しなくてもはるかに豊富なドキュメント構造が得られます。また、非常に単純なレプリケーション、自動フェイルオーバー、自動シャーディングなどのすばらしい機能も利用できますが、ドキュメントが10万個しかない場合は、この種の問題についてすぐに考えることはないでしょう。すべての主流のリレーショナルデータベースは小さなサーバーで実行でき、その量のドキュメントでうまく機能します。