قواعد البيانات واصطلاحات تسمية الجداول والأعمدة؟[مغلق]

Question

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

1. هل يجب أن تكون أسماء الجداول متعددة؟
2. هل يجب أن تكون أسماء الأعمدة مفردة؟
3. هل يجب أن أبدأ الجداول أو الأعمدة؟
4. هل يجب علي استخدام أي حالة في تسمية العناصر؟

هل هناك أي إرشادات موصى بها لتسمية العناصر في قاعدة البيانات؟

Answer 1

أوصي بمراجعة نماذج قواعد بيانات SQL Server الخاصة بـ Microsoft:https://github.com/Microsoft/sql-server-samples/releases/tag/adventureworks

يستخدم نموذج AdventureWorks اصطلاح تسمية واضحًا ومتسقًا للغاية يستخدم أسماء المخططات لتنظيم كائنات قاعدة البيانات.

1. الأسماء المفردة للجداول
2. الأسماء المفردة للأعمدة
3. اسم المخطط لبادئة الجداول (على سبيل المثال:اسم المخطط.اسم الجدول)
4. غلاف باسكال (ويعرف أيضا باسم.حالة الجمل العلوي)

Answer 2

إجابة متأخرة هنا، ولكن باختصار:

1. لي التفضيل هو الجمع
2. نعم
3. الجداول:*عادة* لا توجد بادئات هي الأفضل. أعمدة:لا.
4. كل من الجداول والأعمدة:باسكال كيس.

التفصيل:

(1) ما يجب عليك فعله. هناك أشياء قليلة جدًا يمكنك القيام بها يجب افعل طريقة معينة في كل مرة، ولكن هناك القليل منها.

• اسمك المفاتيح الأساسية باستخدام تنسيق "[singularOfTableName]ID".وهذا يعني ما إذا كان اسم الجدول الخاص بك هو عميل أو عملاء, ، ينبغي أن يكون المفتاح الأساسي هوية الزبون.
• إضافي، مفاتيح خارجية يجب يتم تسميتها باستمرار في جداول مختلفة.يجب أن يكون من القانوني ضرب شخص لا يفعل ذلك.أود أن أقدم ذلك في حين أن القيود الرئيسية الخارجية المحددة هي غالباً تسمية المفتاح الأجنبي مهمة ومتسقة دائماً مهم
• يجب أن يكون لديك قاعدة البيانات الاتفاقيات الداخلية.على الرغم من أنك سترونني في الأقسام اللاحقة مرنًا جدًا، داخل يجب أن تكون تسمية قاعدة البيانات متسقة للغاية.ما إذا كان يتم استدعاء الجدول الخاص بك للعملاء عملاء أو عميل أقل أهمية من أن تفعل ذلك بنفس الطريقة في نفس قاعدة البيانات.ويمكنك قلب العملة لتحديد كيفية استخدام الشرطة السفلية، ولكن بعد ذلك أنت يجب الاستمرار في استخدامها بنفس الطريقة.إذا لم تفعل هذا، فأنت شخص سيء وينبغي أن يكون لديه احترام منخفض لذاته.

(2) ما يجب عليك فعله على الأرجح.

• الحقول التي تمثل نفس النوع من البيانات في جداول مختلفة يجب يكون اسمه نفسه.ليس لديك الرمز البريدي على طاولة واحدة والرمز البريدي على طاولة أخرى.
• لفصل الكلمات في أسماء الجداول أو الأعمدة، استخدم PascalCasing.لن يكون استخدام CamelCasing مشكلة جوهرية، لكن هذا ليس هو التقليد وسيبدو الأمر مضحكًا.سوف أتناول الشرطة السفلية في لحظة.(لا يجوز لك استخدام ALLCAPS كما في الأيام الخوالي.OBNOXIOUSTABLE.ANNOYING_COLUMN كان مقبولاً في DB2 قبل 20 عامًا، ولكن ليس الآن.)
• لا تختصر الكلمات أو تختصرها بشكل مصطنع.ومن الأفضل أن يكون الاسم طويلا وواضحا من أن يكون قصيرا ومربكا.الأسماء القصيرة جدًا هي بقايا من العصور المظلمة والأكثر وحشية.Cus_AddRef.ما على الأرض هو أن؟مرجع المرسل إليه الاحتجازي؟استرداد العميل الإضافي؟إحالة عنوان مخصص؟

(3) ما يجب عليك مراعاته.

• أعتقد حقًا أنه يجب أن يكون لديك أسماء جمع للجداول؛يعتقد البعض المفرد.اقرأ الحجج في مكان آخر.ومع ذلك، يجب أن تكون أسماء الأعمدة مفردة.حتى إذا كنت تستخدم أسماء الجداول بصيغة الجمع، فقد تكون الجداول التي تمثل مجموعات من الجداول الأخرى بصيغة المفرد.على سبيل المثال، إذا كان لديك الترقيات و أغراض جدول، يمكن أن يكون الجدول الذي يمثل عنصرًا جزءًا من عرض ترويجي هو Promotions_Items، ولكنه قد يكون أيضًا Promotion_Items بشكل شرعي على ما أعتقد (يعكس علاقة رأس بأطراف).
• استخدم الشرطة السفلية باستمرار ولأغراض معينة.فقط أسماء الجداول العامة يجب أن تكون واضحة بما فيه الكفاية مع PascalCasing؛لا تحتاج إلى الشرطة السفلية لفصل الكلمات.احفظ الشرطات السفلية إما (أ) للإشارة إلى جدول اقتران أو (ب) للبادئة، وهو ما سأتناوله في النقطة التالية.
• البادئة ليست جيدة أو سيئة.هو - هي عادة ليس الأفضل.في أول قاعدة بيانات أو اثنتين، لا أقترح استخدام البادئات للتجميع المواضيعي العام للجداول.في نهاية المطاف، لا تتناسب الجداول مع فئاتك بسهولة، ويمكن أن تفعل ذلك بالفعل أصعب للعثور على الجداول.من خلال الخبرة، يمكنك تخطيط وتطبيق نظام البادئة الذي يفيد أكثر من الضرر.لقد عملت في قاعدة بيانات مرة واحدة حيث بدأت جداول البيانات بـ tbl, ، جداول التكوين مع ctbl, وجهات النظر مع vew, ، بروك sp, ، و udf fn, ، وعدد قليل من الآخرين؛لقد تم تطبيقه بدقة وباستمرار، لذلك كان الأمر جيدًا.المرة الوحيدة التي تحتاج فيها إلى البادئات هي عندما يكون لديك حلول منفصلة بالفعل والتي لسبب ما تتواجد في نفس قاعدة البيانات؛يمكن أن تكون البادئة لها مفيدة جدًا في تجميع الجداول.تعتبر البادئة أيضًا مناسبة للمواقف الخاصة، مثل الجداول المؤقتة التي تريد إبرازها.
• نادراً ما ترغب في بادئة الأعمدة.

Answer 3

حسنًا، بما أننا نزن بالرأي:

أعتقد أن أسماء الجداول يجب أن تكون متعددة.الجداول عبارة عن مجموعة (جدول) من الكيانات.يمثل كل صف كيانًا واحدًا، ويمثل الجدول المجموعة.لذلك أود أن أسمي جدول الكيانات الشخصية أشخاصًا (أو أشخاصًا، أيًا كان ما يعجبك).

بالنسبة لأولئك الذين يرغبون في رؤية "أسماء الكيانات" المفردة في الاستعلامات، هذا هو ما سأستخدمه في الأسماء المستعارة للجدول:

SELECT person.Name
FROM People person

يشبه إلى حد ما خيار LINQ "من شخص إلى شخص، حدد اسم الشخص".

أما بالنسبة لـ 2 و 3 و 4، فأنا أتفق مع @Lars.

Answer 4

أنا أعمل في فريق دعم قاعدة البيانات مع ثلاثة مسؤولي قواعد البيانات وخياراتنا المدروسة هي:

1. أي معيار تسمية أفضل من عدم وجود معيار.
2. لا يوجد معيار "حقيقي واحد"، فكل منا لديه تفضيلاته
3. إذا كان هناك معيار موجود بالفعل، فاستخدمه.لا تقم بإنشاء معيار آخر أو تعكير صفو المعايير الحالية.

نحن نستخدم الأسماء المفردة للجداول.تميل الجداول إلى أن تكون مسبوقة باسم النظام (أو اختصاره).يعد هذا مفيدًا إذا كان النظام معقدًا حيث يمكنك تغيير البادئة لتجميع الجداول معًا بشكل منطقي (على سبيل المثال.reg_customer وreg_booking وregadmin_limits).

بالنسبة للحقول، نتوقع أن تتضمن أسماء الحقول البادئة/الأحرف الأولى للجدول (أي:cust_address1) ونفضل أيضًا استخدام مجموعة قياسية من اللواحق ( _id لـ PK، _cd لـ "code"، _nm لـ "name"، _nb لـ "number"، _dt لـ "Date").

يجب أن يكون اسم حقل المفتاح الخارجي هو نفس حقل المفتاح الأساسي.

أي.

SELECT cust_nm, cust_add1, booking_dt
FROM reg_customer
INNER JOIN reg_booking
ON reg_customer.cust_id = reg_booking.cust_id

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

Answer 5

1. لا.يجب تسمية الجدول باسم الكيان الذي يمثله."الشخص، وليس الأشخاص" هو الطريقة التي يمكنك بها الإشارة إلى من يمثله أحد السجلات.
2. مرة أخرى، نفس الشيء.لا ينبغي أن يُطلق على عمود الاسم الأول اسم FirstNames.كل هذا يتوقف على ما تريد تمثيله بالعمود.
3. لا.
4. نعم.القضية من أجل الوضوح.إذا كنت بحاجة إلى أعمدة مثل "الاسم الأول"، فإن غلاف الكتاب سيجعل من السهل قراءتها.

نعم.هذا هو 0.02 دولار الخاص بي

Answer 6

أنا أيضًا أؤيد اتفاقية تسمية النمط ISO/IEC 11179، مع الإشارة إلى أنها مبادئ توجيهية وليست توجيهية.

يرى اسم عنصر البيانات في ويكيبيديا:

"الجداول عبارة عن مجموعات من الكيانات، وتتبع إرشادات تسمية المجموعة.من الناحية المثالية، يتم استخدام الاسم الجماعي:على سبيل المثال، الموظفين.والجمع صحيح أيضاً:موظفين.الأسماء غير الصحيحة تشمل:الموظف، وtblEmployee، وEmployeeTable."

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

Answer 7

تفضيلنا:

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

   Update person set property = 'value' يعمل على كل شخص في الجدول.
   Select * from person where person.name = 'Greg' إرجاع مجموعة/مجموعة صفوف من صفوف الأشخاص.

2. هل يجب أن تكون أسماء الأعمدة مفردة؟
   عادة، نعم، باستثناء الحالات التي تنتهك فيها قواعد التطبيع.

3. هل يجب أن أبدأ الجداول أو الأعمدة؟
   في الغالب تفضيل النظام الأساسي.نحن نفضل بادئة الأعمدة باسم الجدول.نحن لا نبدأ الجداول بالبادئات، ولكننا نقوم بعرض البادئات (v_) والإجراءات المخزنة (sp_ أو f_ (وظيفة)).يساعد ذلك الأشخاص الذين يرغبون في محاولة تحديث v_person.age وهو في الواقع حقل محسوب في طريقة عرض (والتي لا يمكن تحديثها على أي حال).

   إنها أيضًا طريقة رائعة لتجنب تضارب الكلمات الرئيسية (فواصل Delivery.from، لكن Delivery_from لا يحدث ذلك).

   إنه يجعل التعليمات البرمجية أكثر تفصيلاً، ولكنه غالبًا ما يساعد في سهولة القراءة.

   bob = new person()
bob.person_name = 'Bob'
bob.person_dob = '1958-12-21'
   ...سهل القراءة وصريح للغاية.يمكن أن يخرج هذا عن السيطرة بالرغم من ذلك:

   customer.customer_customer_type_id

   يشير إلى وجود علاقة بين العميل وجدول customer_type، ويشير إلى المفتاح الأساسي في جدول customer_type (customer_type_id) وإذا رأيت "customer_customer_type_id" أثناء تصحيح الاستعلام، فستعرف على الفور من أين جاء (جدول العملاء).

   أو عندما تكون لديك علاقة M-M بين customer_type وcustomer_category (أنواع معينة فقط متاحة لفئات معينة)

   customer_category_customer_type_id

   ...قليلاً (!) على الجانب الطويل.

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

   معظم هذه التفضيلات بالرغم من ذلك.- طالما أنك متسق، يجب أن يكون متوقعًا لأي شخص يجب أن يقرأه.

Answer 8

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

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

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

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

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

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

Answer 9

ألق نظرة على ISO 11179-5:مبادئ التسمية وتحديد الهوية يمكنك الحصول عليها هنا: http://metadata-standards.org/11179/#11179-5

لقد كتبت عنها منذ فترة هنا: اصطلاحات التسمية ISO-11179

Answer 10

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

يجب تسمية جميع الأعمدة ببادئة فريدة للجدول الذي تم تعريفها فيه.

على سبيل المثالبالنظر إلى الجدولين "العميل" و"العنوان"، فلنستخدم البادئات "cust" و"addr" على التوالي.سيكون لـ "العميل" "cust_id" و"cust_name" وما إلى ذلك.فيه.قد يحتوي "العنوان" على "addr_id"، و"addr_cust_id" (FK العودة إلى العميل)، و"addr_street"، وما إلى ذلك.فيه.

عندما عُرض علي هذا المعيار لأول مرة، كنت معارضًا له بشدة؛لقد كرهت الفكرة.لم أستطع تحمل فكرة كل تلك الكتابة الإضافية والتكرار.لقد اكتسبت الآن ما يكفي من الخبرة في هذا الأمر لدرجة أنني لن أعود إليه أبدًا.

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

يمكنك البحث في قاعدة التعليمات البرمجية بأكملها والعثور بشكل موثوق على كل سطر من التعليمات البرمجية الذي يمس عمودًا معينًا.

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

هناك فائدة أخرى بسيطة نسبيًا وهي أنه لا يتعين عليك استخدام الأسماء المستعارة للجدول إلا عند القيام بربط ذاتي:

SELECT cust_id, cust_name, addr_street, addr_city, addr_state
    FROM customer
        INNER JOIN address ON addr_cust_id = cust_id
    WHERE cust_name LIKE 'J%';

Answer 11

آرائي حول هذه هي:

1) لا، يجب أن تكون أسماء الجداول مفردة.

بينما يبدو من المنطقي الاختيار البسيط (select * from Orders) إنه أقل منطقية بالنسبة لمكافئ OO (Orders x = new Orders).

الجدول الموجود في قاعدة البيانات هو في الواقع مجموعة هذا الكيان، ويصبح الأمر أكثر منطقية بمجرد استخدام المنطق المحدد:

select Orders.*
from Orders inner join Products
    on Orders.Key = Products.Key

يبدو هذا السطر الأخير، وهو المنطق الفعلي للصلة، مربكًا مع أسماء الجداول المتعددة.

لست متأكدًا من استخدام اسم مستعار دائمًا (كما يقترح مات) لتوضيح ذلك.

2) أن تكون مفردة لأنها تملك عقاراً واحداً فقط

3) أبدًا، إذا كان اسم العمود غامضًا (كما هو مذكور أعلاه حيث يحتوي كل منهما على عمود يسمى [مفتاح]) فإن اسم الجدول (أو اسمه المستعار) يمكن أن يميزهما جيدًا بما فيه الكفاية.تريد أن تكون الاستعلامات سريعة الكتابة وبسيطة - فالبادئات تضيف تعقيدًا غير ضروري.

4) كل ما تريد، أقترح عليك CapitalCase

لا أعتقد أن هناك مجموعة واحدة من الإرشادات المطلقة بشأن أي من هذه الأمور.

طالما أن كل ما تختاره متسق عبر التطبيق أو قاعدة البيانات، فلا أعتقد أنه مهم حقًا.

Answer 12

في رأيي:

1. يجب أن تكون أسماء الجداول بصيغة الجمع.
2. يجب أن تكون أسماء الأعمدة مفردة.
3. لا.
4. إما CamelCase (المفضل لدي) أو الشرطة السفلية_مفصولة لكل من أسماء الجداول وأسماء الأعمدة.

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

Answer 13

1. بالتأكيد احتفظ بأسماء الجداول مفردة، وليست أشخاصًا
   2. نفس الشيء هنا
   3. لا.لقد رأيت بعض البادئات الرهيبة، وذهبت إلى حد الإشارة إلى أن ما نتعامل معه هو جدول (tbl_) أو إجراء متجر المستخدم (usp_).يلي ذلك اسم قاعدة البيانات ...لا تفعل ذلك!
   4. نعم.أنا أميل إلى PascalCase جميع أسماء الجداول الخاصة بي

Answer 14

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

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

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

فقط في حالة، هنا إجاباتي:

1. نعم.الجدول عبارة عن مجموعة من السجلات, معلمون أو ممثلين, ، لذا...جمع.
2. نعم.
3. أنا لا أستخدمها.
4. قاعدة البيانات التي أستخدمها كثيرًا - Firebird - تحافظ على كل شيء بأحرف كبيرة، لذلك لا يهم.على أية حال، عندما أقوم بالبرمجة، أكتب الأسماء بطريقة تسهل قراءتها، مثل سنة الإصدار.

Answer 15

تسمح اصطلاحات التسمية لفريق التطوير بتصميم قابلية الاكتشاف وقابلية الصيانة في قلب المشروع.

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

وهنا إجاباتي:

1. نعم، يجب أن تكون أسماء الجداول بصيغة الجمع عندما تشير إلى مجموعة من الصفقات, ضمانات, ، أو الأطراف المقابلة على سبيل المثال.
2. نعم.
3. نعم.جداول SQL مسبوقة بـ tb_، وطرق العرض مسبوقة بـ vw_، والإجراءات المخزنة مسبوقة بـ usp_، والمشغلات مسبوقة بـ tg_ متبوعة باسم قاعدة البيانات.
4. يجب أن يكون اسم العمود بأحرف صغيرة مفصولاً بشرطة سفلية.

التسمية صعبة ولكن في كل مؤسسة يوجد شخص يمكنه تسمية الأشياء، وفي كل فريق برمجيات يجب أن يكون هناك شخص يتحمل مسؤولية معايير التسمية ويضمن أن مشكلات التسمية مثل sec_id, sec_value و Security_id يجب حلها مبكرًا قبل أن يتم دمجها في المشروع.

إذن ما هي المبادئ الأساسية لاتفاقية ومعايير التسمية الجيدة:-

• استخدم لغة عميلك ومجال الحل الخاص بك
• كن وصفيًا
• كن متسقا
• إزالة الغموض والتأمل وإعادة البناء
• لا تستخدم الاختصارات ما لم تكن واضحة للجميع
• لا تستخدم الكلمات الرئيسية المحجوزة SQL كأسماء الأعمدة

Answer 16

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

http://justinsomnia.org/writings/naming_conventions.html

Answer 17

يجب أن تكون أسماء الجداول مفردة دائمًا، لأنها تمثل مجموعة من الكائنات.وكما تقول قطيع لتعيين مجموعة من الأغنام، أو قطيع لتعيين مجموعة من الطيور.لا داعي للتعدد.عندما يكون اسم الجدول مكونًا من اسمين وتكون اصطلاح التسمية بصيغة الجمع، يصبح من الصعب معرفة ما إذا كان اسم الجمع يجب أن يكون الكلمة الأولى أو الكلمة الثانية أو كليهما.إنه المنطق – Object.instance، وليس object.instance.أو TableName.column، وليس TableNames.column(s).Microsoft SQL ليس حساسًا لحالة الأحرف، ومن الأسهل قراءة أسماء الجداول، إذا تم استخدام أحرف كبيرة، لفصل أسماء الجداول أو الأعمدة عندما تتكون من اسمين أو أكثر.

Answer 18

SELECT 
   UserID, FirstName, MiddleInitial, LastName
FROM Users
ORDER BY LastName

Answer 19

اسم الطاولة: يجب أن يكون مفردًا، لأنه كيان مفرد يمثل كائنًا من العالم الحقيقي وليس كائنات، وهو مفرد.

اسم العمود: يجب أن تكون مفردة فقط عندها تنقل أنها ستحمل قيمة ذرية وستؤكد نظرية التطبيع.ومع ذلك، إذا كان هناك عدد n من نفس النوع من الخصائص، فيجب إضافتها بـ 1، 2، ...، n، وما إلى ذلك.

بادئة الجداول / الأعمدة:وهو موضوع ضخم سنناقشه لاحقا.

غلاف:ينبغي أن تكون حالة الجمل

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

Answer 20

لقد تأخرت كثيرًا في الحفلة ولكنني مازلت أرغب في إضافة سنتي حول بادئات الأعمدة

يبدو أن هناك وسيطتين رئيسيتين لاستخدام معيار تسمية table_column (أو tableColumn) للأعمدة، وكلاهما يعتمد على حقيقة أن اسم العمود نفسه سيكون فريدًا عبر قاعدة البيانات بأكملها:

1) ليس عليك تحديد أسماء الجداول و/أو الأسماء المستعارة للأعمدة في استعلاماتك طوال الوقت

2) يمكنك بسهولة البحث في الكود بالكامل عن اسم العمود

أعتقد أن كلا الحجتين معيبتان.الحل لكلا المشكلتين دون استخدام البادئات سهل.وهنا اقتراحي:

استخدم دائمًا اسم الجدول في SQL الخاص بك.على سبيل المثال، استخدم دائمًا table.column بدلاً من column.

من الواضح أنه يحل المشكلة 2) حيث يمكنك الآن فقط البحث عن table.column بدلاً من table_column.

ولكن يمكنني سماع صراخك، كيف يتم حل المشكلة 1)؟كان الأمر بالضبط يتعلق بتجنب هذا.نعم، كان الأمر كذلك، لكن الحل كان معيبًا بشكل فظيع.لماذا؟حسنًا، حل البادئة يتلخص في:
لتجنب الاضطرار إلى تحديد table.column عندما يكون هناك غموض، يمكنك تسمية جميع الأعمدة الخاصة بك table_column!
ولكن هذا يعني أنه سيتعين عليك من الآن فصاعدًا دائمًا كتابة اسم العمود في كل مرة تحدد فيها عمودًا.ولكن إذا كان عليك القيام بذلك على أي حال، فما الفائدة من كتابة table.column بشكل صريح دائمًا؟بالضبط، ليست هناك فائدة، إنه نفس عدد الأحرف المراد كتابتها.

يحرر:نعم، أدرك أن تسمية الأعمدة بالبادئة يفرض الاستخدام الصحيح بينما أسلوبي يعتمد على المبرمجين

Answer 21

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

تختار أسماء الجدول أسماء قصيرة لا لبس فيها ، لا تميز كلمتين أو كلمتين تميز الجداول بسهولة تسمية أسماء الحقول الفريدة وكذلك الجداول الربطية التي تمنح الجداول أسماء فريدة ، لا تُجد أبدًا (تحديث: تحديث:ما زلت أتفق مع الأسباب المقدمة لهذه الاتفاقية، ولكن معظم الناس يحبون حقًا أسماء الجداول المتعددة، لذا فقد خففت موقفي)...اتبع الرابط أعلاه من فضلك

Answer 22

أسماء الجداول مفردةلنفترض أنك كنت تصمم علاقة بين شخص ما وعنوانه.على سبيل المثال ، إذا كنت تقرأ Datamodel هل تفضل "قد يعيش كل شخص على عنوان 0،1 أو العديد من العنوان". أو "قد يعيش كل شخص في 0،1 أو العديد من العناوين." أعتقد أنه من الأسهل عنوان التعددي ، بدلاً من أن تعيد صياغة الأشخاص كشخص.بالإضافة إلى أن الأسماء الجماعية غالبًا ما تختلف عن النسخة المفردة.

Answer 23

--Example SQL

CREATE TABLE D001_Students
(
    StudentID INTEGER CONSTRAINT nnD001_STID NOT NULL,
    ChristianName NVARCHAR(255) CONSTRAINT nnD001_CHNA NOT NULL,
    Surname NVARCHAR(255) CONSTRAINT nnD001_SURN NOT NULL,
    CONSTRAINT pkD001 PRIMARY KEY(StudentID)
);

CREATE INDEX idxD001_STID on D001_Students;

CREATE TABLE D002_Classes
(
    ClassID INTEGER CONSTRAINT nnD002_CLID NOT NULL,
    StudentID INTEGER CONSTRAINT nnD002_STID NOT NULL,
    ClassName NVARCHAR(255) CONSTRAINT nnD002_CLNA NOT NULL,
    CONSTRAINT pkD001 PRIMARY KEY(ClassID, StudentID),
    CONSTRAINT fkD001_STID FOREIGN KEY(StudentID) 
        REFERENCES D001_Students(StudentID)
);

CREATE INDEX idxD002_CLID on D002_Classes;

CREATE VIEW V001_StudentClasses
(
    SELECT
        D001.ChristianName,
        D001.Surname,
        D002.ClassName
    FROM
        D001_Students D001
            INNER JOIN
        D002_Classes D002
            ON
        D001.StudentID = D002.StudentID
);

هذه هي التقاليد التي تعلمتها، ولكن يجب عليك التكيف مع كل ما يستخدمه خرطوم التطوير.

1. جمع.إنها مجموعة من الكيانات.
2. نعم.السمة هي تمثيل للخاصية الفردية لكيان ما.
3. نعم، يسمح اسم الجدول البادئة بتسمية يمكن تتبعها بسهولة لجميع فهارس القيود والأسماء المستعارة للجدول.
4. حالة باسكال لأسماء الجداول والأعمدة، البادئة + ALL للأحرف الكبيرة للفهارس والقيود.