0

米国内のすべてのアドレス範囲を含む大量のテキスト ファイル (合計 8​​ GB) を取得しました。このセットは次のもので構成されています。

  • 929 個の ZIP+4 ファイルで、それぞれに固有の 3 桁の郵便番号の住所が含まれています。たとえば、ファイル 606 には、606 で始まる 5 桁の郵便番号を持つ住所のみが含まれます。これらのファイルの合計レコード数は、約 3,000 万です。

  • 郵便番号とそれに対応する市と州の包括的なリストを含む市州ファイル。

City State Key を使用して、City State ファイルを ZIP+4 ファイルに結合できます。

データベースのサイズと経験不足を考えると、この取り組みを始める前に、ある程度の洞察を得たいと思いました。ZIP+4 ファイルを 1 つのモンスター ファイルにマージしてから、郵便番号を使用してインデックスを作成する必要がありますか、それとも 3 桁の郵便番号ファイル名をブロックの一致基準として使用できるように、3 桁の郵便番号で区切って残す必要がありますか? もし後者なら、これは階層データベースモデルではないでしょうか? 階層モデルを使用して都市状態ファイルとの関係を調整できますか?

上記のデータ セットの説明は大幅に簡略化したものですが、この質問の目的上、詳細な説明は不要です。完全な説明はここにあります。

私は Python を使用していますが、まだ RDBMS を決定していません。どんな助けでも大歓迎です！

4

1 に答える 1

1

RDBMS を使用する場合は、最終的に 929 個のファイルすべての内容を 1 つのデータベース (ほとんどの場合複数のテーブル) に格納することになります。これらの各ファイルの内容について十分な詳細を提供していないため、このようなデータベースの設計についてこれ以上説明することはできません。正確なレイアウトは、おそらく少数のテーブルにある 3,000 万行の正規化された形式になります。最新の RDBMS のパフォーマンスは、インデックスが適切に設定されている場合にのみ、その規模のデータを処理するのに十分です。

そのデータを RDBMS に入れない理由はほとんどありません。私が考えることができる唯一の理由は、そのようなサブシステムの必要性を完全に排除することです。たとえば、ソリューションの展開を簡素化するためです。実際にそれを行うことを検討している場合は、そうです。929 個のファイルのセットが階層型データベースとして機能する可能性があります。RDBMS ソリューションとの主な違いは、このような一連のフラット ファイルでは、1 つのキー (郵便番号 (またはその一部)) によってのみ合理的にデータをクエリできることです。

于 2013-06-13T22:13:29.683 に答える