0

私は、ユーザーがさまざまな都市で投稿したり商品を販売したりできるCraigslistに似たサイトで作業しています。私のサイトとCraigslistの違いの1つは、ページにすべての都市をリストする代わりに、郵便番号で検索できることです。

私はすでに、各都市のすべての都市、州、緯度、経度、および郵便番号情報を含む郵便番号データベースを持っています。さて、私が何をする必要があるのか​​、そして私が助けを必要としているのかを掘り下げるために：

  1. 私は郵便番号データベースを持っていますが、それは私の使用のために完全にセットアップされていません。（インターネットからhttp://zips.sourceforge.net/から無料でダウンロードしました）

  2. データベース構造の設定についてサポートが必要です（たとえば、使用するテーブルの数やそれらをリンクする方法など）。

PHPとMySQLを使用します。

これらは、データベースのセットアップ方法に関するこれまでの私の考えです:(これが機能するかどうかはわかりませんが）。

シナリオ

誰かがホームページにアクセスすると、「郵便番号を入力してください」と表示されます。たとえば、「17241」と入力した場合、この郵便番号はペンシルベニア州にあるニュービルという名前の都市のものです。現在のデータベース設定では、クエリは次のようになります。

SELECT city FROM zip_codes WHERE zip = 17241;

クエリの結果は「Newville」になります。私が今ここで見ている問題は、彼らがサイトのニュービルセクションに何かを投稿したいときです。ニュービル市の投稿のためだけにテーブル全体を設定する必要があります。42,000を超える都市があります。つまり、42,000を超えるテーブル（各都市に1つ）が必要になるため、そのようにするのは非常識です。

私が考えていた方法の1つは、郵便番号データベースに「city_id」という列を追加することでした。これは、各都市に割り当てられた一意の番号になります。たとえば、ニュービル市のcity_idは83になります。したがって、誰かがニュービル市にリストを投稿した場合、もう1つのテーブルのみが必要になります。もう1つのテーブルは、次のように設定されます。

CREATE TABLE postings (
posting_id INT NOT NULL AUTO_INCREMENT,
for_sale LONGTEXT NULL,
for_sale_date DATETIME NULL,
for_sale_city_id INT NULL,
jobs LONGTEXT NULL,
jobs_date DATETIME NULL,
jobs_city_id INT NULL,
PRIMARY KEY(posting_id)
);

（for_saleおよびjob_列名は、ユーザーがリストできる投稿のタイプのカテゴリーです。これら2つだけではなく、さらに多くのカテゴリーがありますが、これは単なる例です。）

したがって、誰かがWebサイトにアクセスして、販売ではなく購入するものを探している場合、たとえば、郵便番号17241を入力できます。これは、実行されるクエリです。

SELECT city, city_id FROM zip_codes WHERE zip = 17241; //Result: Newville 83

（私はPHPを使用して、ユーザーがSESSIONSとCookieに入力した郵便番号を保存し、サイト全体でそれらを記憶します）

これで、「カテゴリを選択してください」と表示されます。カテゴリ「販売アイテム」を選択した場合、これは結果を実行およびソートするためのクエリです。

SELECT posting_id, for_sale, for_sale_date FROM postings WHERE for_sale_city_id = $_SESSION['zip_code'];

だから今私の質問は、これはうまくいくでしょうか？きっとそうなると思いますが、これを設定したくなくて、何かを見落としていて、最初からやり直さなければならないことに気づきました。

4

3 に答える 3

0

すべてのタイプのリストの列のグループはありませんが、「posting_type」列は次のようになります。

CREATE TABLE postings (
posting_id INT NOT NULL AUTO_INCREMENT,
posting_type char(1),             <<<"J"=job,"S"=for sale, etc.
posting_text LONGTEXT NULL,
posting_date DATETIME NULL,
posting_city_id INT NULL,
PRIMARY KEY(posting_id)
于 2010-05-10T19:42:42.020 に答える
0

ここでは、mongodbのようなnosqlソリューションを検討します。シティとジッパーの関係以外に、ここでキャプチャしたい実際の関係の制約はありますか？

答えはここではないようです。

@Konerakは正しいです。何かを始めて、そこから構築してください。

于 2010-05-10T20:16:07.380 に答える
0 
CREATE TABLE postings ( 
posting_id INT NOT NULL AUTO_INCREMENT, 
for_sale LONGTEXT NULL, 
for_sale_date DATETIME NULL, 
for_sale_city_id INT NULL, 
jobs LONGTEXT NULL, 
jobs_date DATETIME NULL, 
jobs_city_id INT NULL, 
PRIMARY KEY(posting_id)

これはあなたが尋ねたものではありませんが、この構造を見ると、このようにするのではなく、関連するテーブル（および選択する値のルックアップテーブル）を作成する必要があることがわかります。同じものをテーブルに繰り返しリストする場合は、関連するテーブルが必要です。私はpostingsとPosting_typeを持っているでしょう（投稿ごとにリストしたいタイプが複数あるので。この構造のようなものです。

CREATE TABLE postings ( 
posting_id INT NOT NULL AUTO_INCREMENT, 
posting_description LONGTEXT NULL, 
Posting_date DATETIME NULL, 
PRIMARY KEY(posting_id) 

CREATE TABLE posting_categories ( 
posting_id INT NOT NULL, 
Category_id int
Primary Key (posting_id, Category_id)

CREATE TABLE Categories ( 
category_id INT NOT NULL AUTO_INCREMENT, 
category_description LONGTEXT NULL, 
PRIMARY KEY(category_id)

これにより、テーブル構造を変更せずに、必要な数のカテゴリを自由に追加できます。

于 2010-05-11T19:29:43.987 に答える