Aide Avec la mise en page de base de données

Question

Je travaille sur un site similaire à Craigslist où les utilisateurs peuvent faire des messages et vendre des articles dans différentes villes. Une différence entre mon site et Craigslist sera que vous serez en mesure de rechercher par code postal au lieu d'avoir toutes les villes répertoriées sur la page.

J'ai déjà la base de données de code postal qui a toute la ville, état, latitude, longitude et informations code pour chaque ville. Bon, alors plonger dans ce que je dois faire et ce que j'ai besoin d'aide avec:

1.) Bien que j'ai la base de données de code postal, il n'est pas configuré parfaitement pour mon utilisation. (Je l'ai téléchargé à partir d'Internet gratuitement à partir http://zips.sourceforge.net/)

2.) J'ai besoin d'aide pour configurer ma structure de base de données (Ex: Combien de tableaux différents dois-je utiliser et comment dois-je les relier)

I utilisera PHP et MySQL.

Ces nos mes pensées à ce jour sur la façon dont la base de données peut être configuré: (. Je ne sais pas si cela fonctionnera bien)

Scénario:

Quelqu'un va à la page d'accueil et il leur dira: "Veuillez entrer votre code postal.". Si elles entrent "17241" par exemple, ce code postal est pour une ville nommée Newville située en Pennsylvanie. La requête ressemblerait à ceci avec la configuration de base de données actuelle:

SELECT city FROM zip_codes WHERE zip = 17241; 

Le résultat de la requête serait « Newville ». Le problème que je vois ici maintenant est quand ils veulent poster quelque chose dans la section de Newville du site, je devrai avoir une configuration entière de table juste pour les affichages de ville de Newville. Il y a plus de 42 000 villes, ce qui veut dire que je devrais avoir plus de 42 000 tables (une pour chaque ville), ce serait donc fou de le faire de cette façon. Une façon que je pensais de le faire était d'ajouter une colonne à la base de données de code postal appelée "city_id" qui serait un numéro unique attribué à chaque ville. Ainsi, par exemple, la ville de Newville aurait un city_id de 83. Donc maintenant, si quelqu'un vient poster une annonce dans la ville de Newville, je n'aurais besoin que d'une autre table. Qu'une autre table serait la configuration comme ceci:

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) 

);

(Les for_sale et noms colonne job_ sont des catégories des types de messages les utilisateurs pourront à la liste sous. Il y aura beaucoup plus de catégories que seulement ces deux mais ce n'est par exemple.)

Alors maintenant, quand quand quelqu'un vient sur le site et ils sont à la recherche de quelque chose à acheter et à ne pas vendre, ils peuvent entrer leur code postal, 17241, par exemple, et c'est la requête qui se déroulera:

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

(Veuillez noter que j'utiliserai PHP pour stocker le code postal de l'utilisateur entre dans SESSIONS et cookies afin de les rappeler à travers le site)

Maintenant, il leur dira: « S'il vous plaît choisir votre catégorie. ».S'ils choisissent la catégorie « Articles à vendre » alors ceci est la requête à exécuter et trier les résultats:

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

Est-ce que ce travail?

Alors maintenant, ma question à tout le monde est la volonté de ce travail? Je suis assez sûr que ce sera, mais je ne veux pas mettre cette chose et réaliser que j'oublié quelque chose et repartir de tout à zéro. Toutes les opinions et idées sont les bienvenues et j'écouterai ceux qui ont des idées. J'apprécie vraiment l'aide à l'avance: D

Answer 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) 

Ce n'est pas ce que vous avez demandé, mais en voyant cette structure me dit que vous devez créer une table associée (et une table de consultation pour les valeurs au choix) au lieu de faire les choses de cette façon. Si vous énumérez les mêmes choses à plusieurs reprises dans une table, vous avez besoin d'une table connexe. J'aurais postings et Posting_type (puisque vous avez plus d'un type que vous voulez énumérés par affichage. Quelque chose de plus comme cette structure.

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) 

Cela vous donne la liberté d'ajouter autant de catégories que vous le souhaitez sans changer la table

Answer 2

Je ne voudrais pas un groupe de colonnes pour chaque type de cotation, mais une colonne « 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) 

Answer 3

Je considérerais une solution NoSQL ici comme mongodb. Y a-t-il des contraintes relationnelles réelles que vous voulez capturer ici en dehors de la relation ville-zip?

Il semble que la réponse ne serait pas ici.

@Konerak a raison, commence quelque chose et construit à partir de là.