Как разработать этот макет базы данных?

Question

Я работаю над сайтом, похожим на Craigslist, где пользователи могут делать публикации и продавать товары в разных городах. Одно из различий между моим сайтом и Craigslist заключается в том, что вы сможете выполнять поиск по почтовому индексу вместо того, чтобы перечислять все города на странице.

У меня уже есть база данных почтовых индексов, в которой есть информация о городе, штате, широте, долготе и почтовом индексе для каждого города. Итак, чтобы погрузиться в то, что мне нужно сделать, и в чем мне нужна помощь:

1. Хотя у меня есть база данных почтовых индексов, она не настроена идеально для моего использования. (Я скачал его из интернета бесплатно с http://zips.sourceforge.net/)

2. Мне нужна помощь в настройке структуры моей базы данных (например, сколько разных таблиц я должен использовать и как их связать).

Я буду использовать PHP и MySQL.

Вот наши мысли о том, как настроить базу данных: (хотя я не уверен, что это будет работать.)

Сценарий

Кто-то заходит на домашнюю страницу и говорит им: «Пожалуйста, введите ваш почтовый индекс». Например, если они вводят «17241», этот почтовый индекс предназначен для города Ньювилль, расположенного в штате Пенсильвания. Запрос будет выглядеть так с текущей настройкой базы данных:

SELECT city FROM zip_codes WHERE zip = 17241;

Результатом запроса будет "Newville". Проблема, которую я вижу здесь сейчас, заключается в том, что когда они хотят что-то опубликовать в разделе сайта в Ньювилле, мне нужно будет настроить весь стол только для постов в Ньювилле. Есть более 42 000 городов, что означает, что мне нужно иметь более 42 000 таблиц (по одной на каждый город), поэтому было бы безумно делать это таким образом.

Один из способов, которым я думал об этом, - добавить в базу данных почтовых индексов столбец с именем " city_id ", который будет уникальным номером, назначенным каждому городу. Например, в городе Ньювилле city_id будет равен 83. Так что теперь, если кто-то придет и разместит объявление в городе Ньювилле, мне понадобится только еще одна таблица. Эта еще одна таблица будет настроена так:

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_ являются категориями типов публикаций, под которыми пользователи смогут перечислять. Будет гораздо больше категорий, чем только эти две, но это только для примера.)

Так что теперь, когда кто-то заходит на сайт и ищет что-то, чтобы купить, а не продать, он может ввести свой почтовый индекс, например, 17241, и этот запрос будет выполняться:

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

(я буду использовать PHP для хранения почтового индекса, который пользователь вводит в СЕССИЯХ, и файлы cookie, чтобы запомнить их по всему сайту)

Теперь он скажет им: «Пожалуйста, выберите вашу категорию». Если они выбирают категорию «Товары для продажи», то это запрос для запуска и сортировки результатов:

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

Итак, теперь мой вопрос, будет ли это работать? Я почти уверен, что так и будет, но я не хочу настраивать это и понимать, что я что-то упустил и должен начинать с нуля.

Answer 1

Я бы рассмотрел решение nosql здесь, как mongodb. Есть ли какие-то реальные ограничения в отношениях, которые вы хотели бы зафиксировать здесь помимо отношений город-почтовый индекс?

Кажется, что ответа здесь не будет.

@ Конерак прав, начните что-нибудь и строите оттуда.

Answer 2

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) 

Это не то, о чем вы спрашивали, но, увидев эту структуру, вы узнаете, что вам нужно создать связанную таблицу (и таблицу поиска значений для выбора) вместо того, чтобы делать что-то подобное. Если вы неоднократно перечисляете одни и те же вещи в таблице, вам нужна связанная таблица. У меня были бы сообщения и 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) 

Это дает вам возможность добавлять столько категорий, сколько вам нужно, без изменения структуры таблиц.

Answer 3

У меня не будет группы столбцов для каждого типа листинга, кроме столбца "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)