1

ショッピングカートの場合、運送業者が発送できる郵便番号のデータベースを構築したいと思います。

私はいくつかのキャリアを持っているかもしれないので、私は柔軟な解決策を探しています。また、お支払い方法は、代金引換（現金）とプリペイド（ネットバンキング）の2つです。

いずれかの運送業者からの配送郵便番号のリストには、COD方式の場合は2,775エントリ、前払いの場合は4,139エントリがあります。

デザイン＃1（この回答のおかげで）

ストレートリストを範囲（{1,2,3,5,8,9} => {（1,3）、（5,5）、（8,9）}など）に変換し、スキーマを作成します-

carrier
        id(int) | name (varchar)

cod_zipcodes
        start(int) | end(int) | carrier(fk::carrier.id)

prepaid_zipcodes
        start(int) | end(int) | carrier(fk::carrier.id)

範囲に変換すると、プリペイドの郵便番号は1,593（38％）に縮小され、タラの郵便番号は842（30％）に縮小されました。

デザイン＃2

cod_zipcodes
    zipcode(int)

prepaid_zipcodes
    zipcode(int)

基本的に、このデザインにはリストがそのままあります。複数のキャリアがある場合は、リストをマージします。そのため、特定の郵便番号についてどの運送業者が出荷しているのかという情報が失われます。しかし、これは問題ではありません（しかし、それが整理されていれば、それも問題ではありません！）。データベースを検索したいのですが、顧客が入力した郵便番号が許可リストに含まれていることを確認します。

ライブデータベースの経験は限られています。どちらのデザインが優れているかを示すか、独自のデザインを提案してください。

ありがとう！

4

1 に答える 1

1

最初の設計はおそらく最もコンパクトです。startとにまたがるインデックスを追加することで最適化できますend。次のように、両方の支払いタイプを組み合わせることもできます。

zipcodes
    start(int) | end(int) | carrier(fk::carried.id) | cod (0, 1) | prepaid (0, 1)

このcarrierフィールドはオプションですが、後で 1 つの配送業者の郵便番号範囲を更新する必要がある場合に使用できます。

codとprepaidが利用可能かどうかに基づいて範囲をまとめてマージしようとしないでください。さまざまなキャリアと支払いタイプの利用可能性を使用して、複数の範囲を入力できます。それらを照会するには、次を使用します。

SELECT COUNT(cod), COUNT(prepaid) 
FROM zipcodes 
WHERE start <= :start AND :end <= end

codこれにより、特定の郵便番号の可用性および/または可用性を含む単一の行が得られprepaidます (複数のデータベース行に一致する場合でも.

運送業者が郵便番号の範囲と支払いの利用可能性を変更した場合、最も簡単な方法は、その運送業者のすべての行を削除し、(テーブル ロックを使用して) 再入力することです。そのデータベース フィールドを保持することにした場合、これは非常に簡単です。

2 番目のデザインは、運送業者から郵便番号リストを受け取る方法に似ており、管理がより単純化されています。ただし、それらを1つのテーブルに再度配置します。

zipcodes
    zipcode | cod (0, 1) | prepaid(0, 1)

データ型を選択ENUMすることで、かなり優れたデータ圧縮も得られます。配送業者が配送データを変更したときにこのテーブルを更新することはそれほど簡単ではありません。carrierフィールドが欠落しているためです。つまり、特定の郵便番号の追加、削除、更新を検出するスクリプトを作成するか、両方の配送業者データで完全にやり直す必要があります。 .

更新がめったになく、更新が発生したときにテーブル全体を削除してもかまわない場合は、2 番目のオプションをお勧めします。2 つの個別のテーブルではなく、各行にcodとタイプを追加することで、主キーを使用して、範囲ソリューションと比較してより高速に検索できます。prepaid

柔軟性と、特定の範囲でどのキャリアがサポートされているかを知ることができるという事実が好きなら、私は最初のオプションを選びます。ほとんどの場合、インデックスは依然として十分に高速であり、テーブル サイズは 2 番目のオプションと同等である可能性があります。

于 2012-06-28T08:27:14.160 に答える