المساعدة في مخطط قاعدة البيانات (منصة مستقلة)

Question

لدي نوع من سؤال الرأي ولكن في نفس الوقت قد يكون لديه إجابة صحيحة. أحاول تطوير مجموعة من المنتجات وأريد التأكد من أنني منذ أن أفعل ذلك بنفسي ، وأن أفعل ذلك بشكل صحيح في المرة الأولى. لقد قمت بإعادة كتابة المخطط عدة مرات ، في كل مرة أفكر أنها كانت أفضل. بعد ذلك ، يمكن أن صادف بعض الأفكار الجديدة وسيتطلب الكثير من العمل على المخطط ، أو سيؤدي إلى كسر مخططتي.

في الكلية ، تعلمت عن "الترشيد" (أعتقد أن هذه هي الكلمة التي استخدموها ، يمكن أن تكون في طريقها) قاعدة بيانات وهناك 5 مستويات. من ما أتذكره ، كان المستوى 3 أكثر شيوعًا. أعلم أن الممارسة كانت التأكد من أن البيانات لم تتكرر والقيام بذلك ، كان عليك تقسيم الجداول إلى جداول أصغر. واعتمادًا على المدى الذي كسرته ، كلما زاد المستوى. حسنًا ، لا أعرف ما إذا كنت أريد أعلى مستوى ، لكنني أعلم أنني أريده فعالًا قدر استطاعتي. كان لدي 4 سنوات من SQL Server 2000/2005/2008 و 2 سنوات من Oracle ، حوالي 6 أشهر مع Informix (قبل 5 سنوات) ، لمسة هنا أو هناك مع MySQL وحوالي 6 أشهر من الوصول. تفضيلي هو SQL Server ، لكنني أود أن يكون المخطط فعالًا على أي من النظامين.

إليك تصميم مخطط PSUEDO لبعض الجداول ، ثم سأشرح ما أريد القيام به.

Manufacturers
  ManufacturerID (Identity)
  ManufacturerName
  ManufacturerStreetAddress
  ManufacturerZipCodeID
  ...

ZipCodes
  ZipCodeID (Identity)
  ZipCode
  ZipCodeStateID
  ...

States
  StateID (Identity)
  StateName
  StateAbbreviation
  ...

Cities
  CityID (Identity)
  CityName
  CityStateID
  ...

أعتذر عن كونه مخططًا لـ PSUEDO فقط ، لكن هذا كل ما لدي الآن وأنا أقوم بالتصميم على الورق على Break ، لكن كان لدي سؤال قبل أن أكون بعيدًا. ما أريد فعله هو التأكد من أن كل شيء يرتبط ببعضهم البعض بشكل صحيح. اعتقادي هو أن الرمز البريدي ينتمي إلى دولة ومدينة ، ولكن لا توجد مدينة تنتمي إلى أي رمز مضغوط واحد ، فقد يكون لديها الكثير. إذا وضعت الرمز الرمز البريدي في جدول الشركات المصنعة ، فأنا أريد أن أكون قادرًا على الحصول على الدولة والمدينة. لكني لا أريد استخدام أي معرفات عدة مرات في الجداول الأخرى. ما أعنيه بذلك هو أن يكون stateid في zipcodes والمدن قد يكون واحدًا عدة مرات. يمكن أن يكون للدولة مدن متعددة تحمل نفس الاسم ، ويمكن أن تحتوي حالات متعددة على مدن ذات نفس الأسماء. لكنني لست متأكدًا مما إذا كنت أريد طاولة أسماء CityNames ثم طاولة CityStates (CityNameId و StateId). أدرك جيدًا أن هناك قواعد بيانات موقع للشراء ، وربما بعضها مجاني ، والتي يمكنني استخدامها ولن أضطر للقلق بشأن هذا. ومع ذلك ، أود أن أعمل على فهمي لهذا لأنني أعتقد أنه سيساعدني على تصميم المخطط الحكيمة في المستقبل ، ولكن أيضًا لأنني أرغب في الحصول على تخصيص التخطيط إذا كان هناك حاجة إلى تغيير أي شيء.

أسئلة:

1. هل يبدو أن مخطط psuedo ، كما هو ، صحيح أم أنه يمكن أن يكون أفضل (الرأي)؟
2. هل يطلق عليه "ترشيد" قاعدة البيانات ، أو أي شيء آخر (هل سيصوت للإجابة الصحيحة)؟ وكم بعيد جدًا (الرأي)
3. سيكون هناك أيضًا جدول للمستخدمين ، والجداول الأخرى التي ستتضمن عناوين (الفرق ، الكابيتول ، إلخ) ، هل سيكون مخطط PSUEDO ، إذا كان صحيحًا من الناحية النظرية ، خطة جيدة لقاعدة بيانات مثل هذا (الرأي)؟

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

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

تحديث: حسنًا ، قد يكون هذا الآن طبيعًا جدًا أو غير طبيعي بما فيه الكفاية أو على الإطلاق ، ولكن هل يمكن أن تخبرني يا رفاق إذا كنت تحب مخطط PSUEDO هذا بشكل أفضل؟

Manufacturers
  ManufacturerID (Identity)
  ManufacturerName
  ManufacturerStreetAddress
  ManufacturerCCSZID --CCSZ (Country, City, State, Zip), needs a better name
  ...

ZipCodes
  ZipCodeID (Identity)
  ZipCode
  ...

States
  StateID (Identity)
  StateName
  StateAbbreviation
  ...

Cities
  CityID (Identity)
  CityName
  ...

Countries
  CountryID (Identity)
  CountryName
  CountryAbbreviation
  ...

CountryCityStateZipCodes
  CountryCityStateZipCodeID (Identity)
  CCSZCountryID
  CCSZStateID
  CCSZCityID
  CCSZZipCodeID

وللحصول على عنوان ، يبدو الأمر كذلك:

SELECT  M.ManufacturerStreetAddress,
        CN.CountryName,
        CN.CountryAbbreviation,
        S.StateName,
        S.StateAbbreviation,
        C.CityName,
        Z.ZipCode
FROM Manufacturers M
LEFT OUTER JOIN CountryCityStateZipCodes CCSZ ON CCSZ.CountryCityStateZipCodeID = M.ManufacturerCCSZID
LEFT OUTER JOIN Countries CN ON CN.CountryID = CCSZ.CCSZCountryID
LEFT OUTER JOIN States S ON S.StateID = CCSZ.CCSZStateID
LEFT OUTER JOIN Cities C ON C.CityID = CCSZ.CCSZCityID
LEFT OUTER JOIN ZipCodes Z ON Z.ZipCodeID = CCSZ.CCSZZipCodeID

أو ربما تعرف يا رفاق طريقة أفضل لكتابة هذا الاستعلام. ولكن بغض النظر ، هل يبدو ذلك أفضل من المخطط الأول؟

Answer 1

لقد سمعت دائمًا أنه يسمى "التطبيع" ، لكننا نتحدث عن نفس الشيء.

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

1. تحتوي الولايات الشمالية الشرقية على رموز ZIP التي تبدأ بـ 0 ، والتي سيتم اقتطاعها إذا قمت بتجميع الرمز البريدي حقلًا رقميًا.
2. إذا كنت تستخدم الرمز البريدي كمفتاح ، فلا يمكنك الحصول على هذا الرمز البريدي في عدة مرات لمدن متعددة. كما قلت ، فإن مكتب البريد يهتم أكثر من Zip أكثر من اسم المدينة. لكن هذا الإعداد من شأنه أن يقيدك من البحث في تلك المدن الفردية لاحقًا.

للبحث من قبل المدينة أو الولاية أو الرمز البريدي لاحقًا ، فقط انضم إلى هذا الجدول إلى جدول الشركات المصنعة. أنت موافق على استخدام Join Inner - ما لم تكن هناك حقول في جدول الشركات المصنعة حيث تكون الشركة المصنعة BantedZipCodeID فارغة ، وفي هذه الحالة ستحتاج إلى انضمام يسار للحصول على تلك لإظهارها أيضًا.

Answer 2

ليس لدي مشكلة كبيرة في طريقة إعداد الأشياء. قد يكون معرف الحالة في الرمز البريدي خطيرًا - لن يفاجئني أن أتعلم أن هناك رموزًا بريديًا عبر حدود الحالة ، لكنني لست متأكدًا من ذلك.

ستقوم بالكثير من الوهمات عن طريق تخزين الدولة والمدينة والرمز البريدي في طاولات منفصلة ، ولكنك تعاملت مع قواعد البيانات التي تخزن العناوين دون تدابير الاتساق ، فهذا أكثر من كابوس أكثر من عدد قليل من الوصلات. على سبيل المثال ينتهي بك الأمر بـ "NY" و "NY" و "NY" و "New York" و "Newyork". لذلك أعتقد أن لديك الجدول المنفصل للدولة والمدينة والرمز البريدية ستؤتي ثمارها على المدى الطويل.

Answer 3

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

1. يمكن أن يكون للدولة مدن متعددة.
2. الدولة فريدة من نوعها
3. يمكن للمدن أن تحتوي على رموز ZIP متعددة
4. قد يكون اسم المدينة متساويًا في اسم مدينة أخرى.
5. الرمز البريدي فريد من نوعه

أولا ، اكتب التفرد. لذلك نحن نبني هذين الجداولين الخام:

STATE
---
State ID (PK)
State Name

ZIP
---
Zip ID (PK)
Zip Code (NK)

ثم ، يطرح سؤال منطقي. معرفة معرف الرمز البريدي ، كيف يمكننا استرجاع معرف المدينة؟ للإجابة عليه ، نحتاج إلى تقديم رابط بين Zip و City. أين يجب وضع هذا الرابط؟ ليس في طاولة المدينة لأنه من الحقيقة رقم 3 ، نعلم أن المدينة يمكن أن تحتوي على العديد من الرموز البريدية المختلفة. لذلك يجب أن يكون في جدول الرمز البريدي. هذا هو الإصدار التالي من جدول الرمز البريدي:

ZIP
---
Zip ID (PK)
Zip Code (NK)
City ID (FK)

الآن ، نظرًا لأننا يمكننا "الانتقال" من الرمز البريدي إلى المدينة ، سنناقش حول طاولة المدينة. يمكن أن يكون لاسم المدينة نفس الاسم مع الآخرين. لذلك نحن لسنا بحاجة إلى إجباره (مجال اسم المدينة) على أن نكون فريدين. لذلك هذا هو الإصدار الأول من طاولة المدينة:

CITY
----
City ID (PK)
City Name

مرة أخرى ، ينشأ نفس السؤال المنطقي. كيف ننتقل إلى الدولة معرفة مدينة؟ يجب إنشاء رابط في مكان ما بين هذين الجدولين. مرة أخرى ، لا يمكن لمعرفة حقيقة#4 أن تضمن أي شيء عن تفرد اسم المدينة. يجب وضع الرابط على طاولة المدينة. لذلك هذا هو نسختنا التالية من طاولة المدينة:

CITY
---
City ID (PK)
City Name
State ID (FK)

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

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

فيما يتعلق بمشاكل أخرى مثل المستخدمين والفرق والكابيتول ، وما إلى ذلك. لا يمكنني قول أي شيء في الوقت الحالي لأنني لم أر المشكلة بعد.