الأسماء المستعارة لجدول SQL - جيدة أم سيئة؟[مغلق]

Question

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

Answer 1

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

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

select person.FirstName
      ,person.LastName
      ,addr.StreetAddress
      ,addr.City
      ,addr.State
      ,addr.Zip
      ,phone.PhoneNumber
      ,company.CompanyName
from tblPeople person
left outer join tblAffiliations affl on affl.personID = person.personID
left outer join tblCompany company on company.companyID = affl.companyID

...إلخ

Answer 2

حسنا، هناك بعض الحالات لك يجب استخدمها، كما هو الحال عندما تحتاج إلى الانضمام إلى نفس الجدول مرتين في استعلام واحد.

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

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

Answer 3

هل أنا الشخص الوحيد هنا الذي يكرههم حقًا؟

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

select a.id, a.region, a.firstname, a.blah, b.yadda, b.huminahumina, c.crap
from table toys as a
inner join prices as b on a.blah = b.yadda
inner join customers as c on c.crap = something else
etc

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

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

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

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

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

Answer 4

يستفيد مُحسِّن الاستعلام الخاص بـ Microsoft SQL من استخدام الأسماء أو الأسماء المستعارة المؤهلة بالكامل.

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

--seems pretty readable to me ;-)
select a.Text
from Question q
    inner join Answer a
        on a.QuestionId = q.QuestionId

هناك أيضًا حد عملي للمدة التي يمكن فيها تنفيذ سلسلة Sql - الأسماء المستعارة تجعل تجنب هذا الحد أسهل.

Answer 5

جيد

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

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

Answer 6

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

أنا حقًا أكره قراءة الاستعلامات التي أنشأها المصمم باسم الجدول الكامل كبادئة لكل اسم عمود.

Answer 7

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

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

Answer 8

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

Answer 9

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

Answer 10

تعتبر الأسماء المستعارة رائعة إذا كنت تعتقد أن مؤسستي لديها أسماء جداول مثل:SchemaName.DataPointName_SubPoint_Sub-SubPoint_Sub-Sub-SubPoint...يستخدم فريقي مجموعة قياسية جدًا من الاختصارات، لذلك يتم تقليل التخمين إلى الحد الأدنى.سنقول إن ProgramInformationDataPoint تم اختصاره إلى pidp، وتم اختصار عمليات الإرسال إلى sub فقط.

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

Answer 11

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

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

Answer 12

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

Answer 13

IMHO، لا يهم حقًا أسماء الجداول القصيرة التي تكون منطقية، لقد عملت في بعض الأحيان على قواعد بيانات حيث يمكن أن يكون اسم الجدول شيئًا مثل VWRECOFLY أو بعض السلاسل العشوائية الأخرى (التي تمليها سياسة الشركة) التي تمثل المستخدمين حقًا، لذلك في في هذه الحالة أجد أن الأسماء المستعارة تساعد حقًا في جعل الكود أكثر قابلية للقراءة.(users.username له أهمية أكبر بكثير من VWRECOFLY.username)

Answer 14

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

حدد person.name من
dbo.Person كشخص

Answer 15

أستخدم دائمًا الأسماء المستعارة عند كتابة الاستعلامات.بشكل عام أحاول اختصار اسم الجدول إلى حرف واحد أو حرفين تمثيليين.لذلك يصبح المستخدمون u وتصبح معاملات المدين dt وما إلى ذلك ...

إنه يحفظ في الكتابة ولا يزال يحمل بعض المعنى.

الأسماء المختصرة تجعلها أكثر قابلية للقراءة بالنسبة لي أيضًا.

Answer 16

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

SELECT Description -- actually in a
 FROM
 table_a a,
 table_b b
 WHERE
 a.ID = b.ID

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

Answer 17

الأسماء المستعارة مطلوبة عند ضم الجداول ذات الأعمدة التي لها أسماء متطابقة.