لماذا الاستعلامات الموضعية سيئة؟

Question

أنا أقرأ تاريخ CJ نظرة عامة SQL وعلاقات نظرية: كيفية كتابة رمز SQL دقيق, ، وهذا هو الحال أن الاستعلامات الموضعية سيئة - على سبيل المثال، هذا INSERT:

INSERT INTO t VALUES (1, 2, 3)

بدلا من ذلك، يجب عليك استخدام استعلامات قائمة على السمة مثل هذا:

INSERT INTO t (one, two, three) VALUES (1, 2, 3)

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

Answer 1

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

الناس الذين يفعلون SELECT * الاستعلامات ثم الاعتماد على تدوين موضعي لاستخراج القيم التي تشعر بالقلق لها صيانة البرمجيات لنفس السبب.

Answer 2

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

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

Answer 3

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

Answer 4

يجب أن تحاول جعل استعلامات SQL تعتمد على التصميم الدقيق للطاولة بأقل قدر ممكن.

يعتمد الاستعلام الأول على الجدول فقط وجود ثلاثة حقول، وفي هذا النظام الدقيق. سيؤدي أي تغيير على الإطلاق إلى الجدول الاستعلام.

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

على الرغم من أنك لا ترخص تخطيط الجدول في كثير من الأحيان، فإن إضافة المزيد من الحقول إلى جدول شائع جدا.

أيضا، الاستعلام الثاني هو أكثر قابلية للقراءة. يمكنك أن تقول من الاستعلام نفسه ما هي القيم التي وضعت في الوسائل السجل.

Answer 5

شيء لم يتم ذكره بعد هو أنك سوف تكون في كثير من الأحيان مفتاح بديل مثل PK الخاص بك، مع auto_increment (أو شيء مماثل) لتعيين قيمة. مع أول واحد، يجب عليك تحديد شيئا ما هناك - ولكن ما القيمة التي يمكنك تحديدها إذا لم يتم استخدامها؟ NULL قد يكون خيارا، لكن هذا لا يصلح حقا في النظر في تعيين PK NOT NULL.

ولكن بصرف النظر عن ذلك، فإن "مقفل" بأكمله من مخطط معين "هو سبب أكثر أهمية بكثير، IMO.

Answer 6

يمنحك SQL بناء جملة لتحديد اسم العمود لكل من إدراج وتحديد العبارات. يجب عليك استخدام هذا بسبب:

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

Answer 7

أفضل استخدام بناء جملة مثل التحديث:

INSERT t SET one = 1 , two = 2 , three = 3

وهو أسهل بكثير القراءة والصيانة من كلتا الأمثلة.

Answer 8

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

Answer 9

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