すばやく検索するために保存したいデータのセット（ソートされていない）があるとします。データをロードする前にサイズがわからないので、すぐにルックアップを実行できるように、一度にすべてをロードする必要があります。
さらに、プログラムの実行中はいつでも、選択したデータ構造に保存するために、より多くのデータが表示される場合があります。
このデータを格納するためにハッシュテーブルまたはソートされた配列を使用する必要がありますか？明らかに、静的ハッシュテーブルは、提示されたデータのサイズに応じて実行時に作成する必要があります-これは、O（ N）？または、動的ハッシュの方法を検討する必要がありますか？
明確化：任意のサイズのデータをロードしてから、データに対して検索と挿入を実行する必要があります。検索/挿入の量について明確な順序やアイデアがありません。
これは本当に一般的なことですが、データの読み込み後に検索よりも多くの挿入を行う必要がある場合はどうなりますか？挿入よりも多くの検索はどうですか？
これは実際には操作の頻度に依存します。
ルックアップの数に対して多くの挿入を行う場合、ソートされた配列への挿入にはコストがかかるため（O（n）時間）、ソートされた配列はおそらく適切なオプションではありません。ここでは、二分探索木またはハッシュテーブルが適切な場合があります。
挿入の数に比べて膨大な数のルックアップを実行する場合は、ハッシュテーブルの方が高速である可能性がありますが、並べ替えられた配列を使用することをお勧めします。範囲検索や最近傍ルックアップなどの操作を実行するためにデータを並べ替える必要がある場合は、通常、並べ替えられた配列が適していますが、それが必要ない場合は、おそらく適切ではありません。
キーが特定のタイプ（整数、文字列など）の場合、トライやファンエムデボアスツリーなどのより具体的なデータ構造を使用して、パフォーマンスを向上させることができる場合があります。これらは、データの詳細を利用できるため、ハッシュテーブルや並べ替えられた配列よりも優れた選択肢となる場合があります。
何が起こるか正直にわからない場合は、最初の実装としてハッシュテーブルを使用します。代わりに使用できる、より微調整されたデータ構造があるかもしれませんが、それが悪い選択である可能性は低いです。事前に使用パターンがわからない場合は、ソートされた配列は適切ではありません。
お役に立てれば！
Templatetypedefの答えは的確ですが、両方のオプションの間で適切な妥協点を提供するRedBlackTreesに関する情報をさらに追加します。彼は、試行とvEBツリーについて言及しました（後者については聞いたことがないので、便利に聞こえます！）RedBlackツリーは、これらのオプションよりも最適ではありませんが、おそらくより一般的な解決策です。確かに、これらのよりエレガントなツリー構造オプションやリストまたはハッシュマップを調べる価値があります。
RedBlack Tree:
Insertion: O(log n)
Key Lookup: O(log n)
Key Search: O(log n)
Iteration: O(n)
Sorted List:
Insertion: O(n log n)
Index Lookup: O(1)
Sorted Search: O(log n)
Iteration: O(n)
Hash Table:
Insertion: O(1)
Key Lookup: O(1)
Key Search: O(n)
Iteration: O(n)