كيفية تصميم تخطيط قاعدة البيانات هذا؟

Question

أنا أعمل على موقع مشابه لـ Craigslist حيث يمكن للمستخدمين إنشاء منشورات وبيع العناصر في مدن مختلفة. سيكون أحد الاختلافات بين موقعي و Craigslist قادرًا على البحث عن طريق الرمز البريدي بدلاً من وجود جميع المدن المدرجة في الصفحة.

لدي بالفعل قاعدة بيانات الرمز البريدي التي تحتوي على معلومات عن كل مدينة ، والولاية ، وخطوط الطول ، والرمز البريدي لكل مدينة. حسنًا ، حتى أغوص في ما أحتاجه وما أحتاج إليه:

1. على الرغم من أن لدي قاعدة بيانات الرمز البريدي ، إلا أنها لا يتم إعدادها تمامًا لاستخدامي. (قمت بتنزيله من الإنترنت مجانًا http://zips.sourceforge.net/)

2. أحتاج إلى مساعدة في إعداد بنية قاعدة البيانات الخاصة بي (على سبيل المثال عدد الجداول المختلفة التي يجب أن أستخدمها وكيف يجب أن أربطها).

سأستخدم PHP و MySQL.

هذه أفكاري حتى الآن حول كيفية إعداد قاعدة البيانات: (لست متأكدًا مما إذا كان هذا سيعمل.)

سيناريو

يذهب شخص ما إلى الصفحة الرئيسية وسيخبره ، "الرجاء إدخال الرمز البريدي الخاص بك.". إذا دخلوا "17241" على سبيل المثال ، فإن هذا الرمز البريدي مخصص لمدينة تدعى نيوفيل تقع في ولاية بنسلفانيا. سيبدو الاستعلام هكذا مع إعداد قاعدة البيانات الحالية:

SELECT city FROM zip_codes WHERE zip = 17241;

ستكون نتيجة الاستعلام "نيوفيل". المشكلة التي أراها هنا الآن هي عندما يرغبون في نشر شيء ما في قسم Newville في الموقع ، سيتعين عليّ إعداد طاولة بالكامل فقط لنشرات مدينة Newville. هناك أكثر من 42000 مدينة ، مما يعني أنه سيتعين عليّ أن يكون لدي أكثر من 42000 طاولة (واحدة لكل مدينة) بحيث يكون من الجنون القيام بذلك بهذه الطريقة.

إحدى الطرق التي كنت أفكر بها في القيام بذلك كانت إضافة عمود إلى قاعدة بيانات الرمز البريدي المسمى "city_id"سيكون رقمًا فريدًا مخصصًا لكل مدينة. لذا على سبيل المثال ، سيكون لدى City Newville 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 لتخزين الرمز البريدي الذي يدخله المستخدم في الجلسات وملفات تعريف الارتباط لتذكرها في جميع أنحاء الموقع)

الآن سوف يخبرهم ، "الرجاء اختيار فئتك.". إذا اختاروا فئة "عناصر للبيع" ، فهذا هو الاستعلام لتشغيل وفرز النتائج:

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

إذن سؤالي الآن ، هل سيعمل هذا؟ أنا متأكد تمامًا من أن الأمر سيفعل ذلك ، لكنني لا أريد إعداد هذا الشيء وأدرك أنني أغفلت شيئًا ما وأبدأ من كل مكان من الصفر.

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) 

هذا ليس ما طلبته ولكن رؤية هذا الهيكل يخبرني أنك بحاجة إلى إنشاء جدول ذي صلة (وجدول بحث للقيم للاختيار من بينها) بدلاً من القيام بالأشياء بهذه الطريقة. إذا كنت تدرج نفس الأشياء بشكل متكرر في الجدول ، فأنت بحاجة إلى جدول ذي صلة. سيكون لدي منشورات و 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 2

لن يكون لدي مجموعة من الأعمدة لكل نوع من القائمة ، ولكن عمود "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

سأعتبر حل NOSQL هنا مثل MongoDB. هل هناك أي قيود علائقية حقيقية تريد التقاطها هنا بصرف النظر عن علاقة المدينة والزيب؟

يبدو أن الجواب لن يكون هنا.

konerak على حق ، ابدأ شيئًا وابنه من هناك.