ResultSet:استرجاع قيم العمود من قبل مؤشر مقابل استرداد من قبل التسمية

Question

عند استخدام JDBC, أنا في كثير من الأحيان تأتي عبر مثل بنيات

ResultSet rs = ps.executeQuery();
while (rs.next()) {
    int id = rs.getInt(1);
    // Some other actions
}

سألت نفسي (والمؤلفين من التعليمات البرمجية أيضا) لماذا عدم استخدام تسميات لاسترجاع قيم العمود:

int id = rs.getInt("CUSTOMER_ID");

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

Answer 1

يجب عليك استخدام سلسلة من التسميات بشكل افتراضي.

الايجابيات:

• الاستقلال من العمود النظام
• أفضل القراءة/الصيانة

سلبيات:

• لديك أي سيطرة على أسماء الأعمدة (الوصول عن طريق الإجراءات المخزنة)

تفضل ؟

رجات?

int i = 1;
"معرف العميل" = resultSet.getInt(i++);
customerName = resultSet.getString(i++);
customerAddress = resultSet.getString(i++);

أو السلاسل ؟

"معرف العميل" = resultSet.getInt("customer_id");
customerName = resultSet.getString("customer_name");
customerAddress = resultSet.getString("customer_address");

وما إذا كان هناك عمود جديد إدراجها في الموضع 1?وهو رمز تفضل ؟ أو إذا كان ترتيب الأعمدة تغيير أي رمز النسخة لن تحتاج إلى تغيير ؟

هذا هو السبب يجب عليك استخدام سلسلة من التسميات بشكل افتراضي.

Answer 2

تحذير: انا ذاهب للحصول على منمق هنا، لأن هذا يدفعني للجنون

99٪ * من الوقت، انها سخيفة الأمثل الصغير أن الناس لديهم فكرة غامضة يجعل الامور "أفضل". هذا يتجاهل تماما حقيقة أن، إلا إذا كنت في حلقة ضيقة جدا ومشغول على الملايين من نتائج SQL <م> كل الوقت ، وهو أمر نادر نأمل، فلن تلاحظ ذلك. لكل من ليست فعل ذلك، وتكلفة الوقت المطور لاستمراره، وتحديثها، وإصلاح الخلل في فهرسة العمود هي أكبر بكثير من التكاليف الإضافية للجهاز للحصول على طلبك متناهي الصغر-أسوأ أداء.

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

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

ويرصد * الشكل يصل.

Answer 3

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

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

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

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

Answer 4

ومن وثائق جافا:

<اقتباس فقرة>   

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

وبالطبع كل طريقة (المسمى أو مفهرسة) له مكانه. أوافق على أن أعمدة اسمه يجب أن يكون الافتراضي. ومع ذلك، في الحالات التي تتطلب عدد كبير من الحلقات، وحيث يتم تعريف عبارة SELECT والحفاظ في نفس القسم من التعليمات البرمجية (أو فئة)، وينبغي أن تكون المؤشرات طيب - فإنه من المستحسن أن قائمة الأعمدة اختياره، وليس فقط "SELECT * FROM ..."، لأن أي تغيير الجدول وكسر الشفرة.

Answer 5

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

والشكر

Answer 6

وأنا لا أعتقد باستخدام الأداء تسميات الآثار بكثير. ولكن هناك سبب آخر لعدم استخدام Strings. أو ints، لهذه المسألة.

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

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

Answer 7

وفعلت بعض ملامح الأداء على هذا الموضوع المحدد على قاعدة بيانات Oracle. في التعليمات البرمجية لدينا لدينا resultset ومع العديد من colums وعدد كبير من الصفوف. من 20 ثانية (!) على طلب يأخذ لتنفيذ طريقة oracle.jdbc.driver.ScrollableResultSet.findColumn (اسم سلسلة) يستغرق حوالي 4 ثوان.

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

Answer 8

يمكنك الحصول على أفضل من كلا!سرعة استخدام المؤشرات مع الصيانة و الأمن من استخدام أسماء الأعمدة.

أولا - إذا لم يتم تنفيذ الحلقات خلال مجموعة نتائج مجرد استخدام أسماء الأعمدة.

1. تحديد مجموعة من المتغيرات عدد صحيح واحد لكل عمود سوف يمكنك الوصول إلى.أسماء المتغيرات يمكن أن تشمل اسم العمود:على سبيل المثالiLast_Name.

2. من قبل مجموعة النتائج حلقة تكرار من خلال عمود بيانات التعريف تعيين قيمة كل متغير عدد صحيح إلى العمود مؤشر المقابلة اسم العمود.إذا كان مؤشر 'Last_Name' عمود 3 ثم تعيين قيمة 'iLast_Name' إلى 3.

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

ملاحظة:عملية المسح الأولي (أياسم عمود مؤشر رسم الخرائط) لا تتم إلا مرة واحدة قبل حلقة بدلا من كل سجل و عمود في الحلقة.

Answer 9

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

Answer 10

أنا أتفق مع الإجابات السابقة أن الأداء ليس شيئا يمكن أن تجبرنا على تحديد أي من النهجين.سيكون من الجيد أن تنظر في الأمور التالية بدلا من ذلك:

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

Answer 11

وباستخدام مؤشر هو محاولة لتحسين الأداء.

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

وأعتقد أنه لدينا المدمج في غريزة استخدام الأرقام بدلا من النص.

Answer 12

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

وكل هذا يتوقف على الاختيار الفردي وحتى الآن ولقد استخدمت مؤشرات فقط: -)

Answer 13

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