質問: 私はDapper.NETと家族のサイトで仕事をする予定です。 データのような多くのツリーが構造内に存在します。どのデータベースが周期的/非循環的なツリー関係で動作するための最良のクエリを提供するか? 私は、階層クエリの容易さとパフォーマンスの比較を知りたい。すなわち、 SQL ServerのCTEのように、Connect By / StartをOracleなどで使用します。 このようなツリー構造のデータに対して、Micro ORMとしてdapperが最適ですか? 私は、正しいデータベースを選択し、これに対して正しいMicro ORMの意見が必要です。 私の悪い英語を申し訳ありません。
回答: 私の質問はまだあり**ません** : **どのくらいのデータを期待していますか?** しかしそれとは別に、あなたのデータのために選ぶデータベースのタイプだけでなく、テーブル構造もあります。階層ツリーは、必要に応じてさまざまな方法で格納できます。 テーブル構造 特定の構造は、トラバーサル読み取りでは非常に高速ですが、挿入/更新( ネストされたセット )、その他のもの(隣接リスト)は逆です。 99:1の読み込み:書き込みの比率(今日のアプリケーションの大部分は書き込みよりはるかに多くを読んでいます)では、左、右、深度、親を持つ変更ネストされたセット構造を選択する可能性があります。これにより、読み込みシナリオに最適な可能性が得られます。 データベースの種類 膨大な量のデータを目指しているのでなければ、あなたが知っているすべてのSQLデータベース(MSSQL、MySQL、Oracle)をお勧めします。しかし、データベースに膨大な数の階層ノードが含まれている場合は、 専用のグラフ指向のデータベースを使用するほうがよいでしょう。 80,000,000ノード 変更されたネストされたセットソリューションを選択する場合(負の値を使用して、挿入/更新の半分の更新が行われるため)、階層テーブルが`left`ます。 `right` 、 `ID`と`ParentID`約1.2ギガバイトのテーブルにつながるの列。しかし、それは少なくとも2年間の使用後のあなたの一番の評価です。 私のおすすめ **クイック&ライトに行く** - あなたの階層を保存するために可能な限り最良のデータベースを使用して、それが必要ではないことが判明した場合は、熟練しないでください。したがって、最初にリレーショナルDBを使用することをお勧めします。ソリューションが数百万のレコードの後に苦労し始めても、すぐに市場に出ることができます。しかし、あなたのデータベースが苦労し始める前に(ここで何年も話しています)、あなたは2つのことを得るでしょう: 1. あなたは、あなたの製品が最初に離陸するかどうかを確認します(すでに多くの系図サービスがあります)ので、新技術の学習に投資することはありません。実績のあるサポートされたテクノロジを使用しているため、すぐに市場に出るでしょう 2. あなたの製品が成功すれば(そして私は本当にそうなることを願っています)、それはあなたに別のストレージソリューションを学び実装するのに十分な時間を与えます。適切なコード層を使用して、後で必要に応じてストレージを切り替えるのは難しくありません