JPA والإسبات - المعايير مقابل.JPQL أو HQL

Question

ما هي إيجابيات وسلبيات الاستخدام معايير أو HQL؟تعد Criteria API طريقة لطيفة موجهة للكائنات للتعبير عن الاستعلامات في Hibernate، ولكن في بعض الأحيان يكون فهم/بناء استعلامات المعايير أكثر صعوبة من فهم/بناء HQL.

متى تستخدم المعايير ومتى HQL؟ماذا تفضل وفي أي حالات الاستخدام؟أم أنها مجرد مسألة ذوق؟

Answer 1

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

ومن ناحية أخرى أنا باستخدام HQL للاستعلامات ثابتة ومعقدة، لأنه من الأسهل بكثير لفهم / قراءة HQL. أيضا، HQL قليلا أكثر قوة، كما أعتقد، على سبيل المثال، لصلة مختلفة الأنواع.

Answer 2

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

فيما يتعلق باستراتيجيات الجلب [http://www.hibernate.org/315.html]

• تحترم المعايير إعدادات الكسل في تعييناتك وتضمن تحميل ما تريد تحميله.وهذا يعني أن استعلام معايير واحد قد يؤدي إلى عدة عبارات SQL SELECT فورية لجلب الرسم البياني الفرعي مع كافة الارتباطات والمجموعات المعينة غير البطيئة.إذا كنت تريد تغيير "كيف" وحتى "ماذا"، فاستخدم setFetchMode() لتمكين أو تعطيل جلب الصلة الخارجية لمجموعة أو اقتران معين.تحترم استعلامات المعايير أيضًا إستراتيجية الجلب تمامًا (الانضمام مقابل التحديد مقابل التحديد الفرعي).
• تحترم HQL إعدادات الكسل في تعييناتك وتضمن تحميل ما تريد تحميله.وهذا يعني أن استعلام HQL واحد قد يؤدي إلى عدة عبارات SQL SELECT فورية لجلب الرسم البياني الفرعي مع كافة الارتباطات والمجموعات المعينة غير البطيئة.إذا كنت تريد تغيير "كيف" وحتى "ماذا"، فاستخدم LEFT JOIN FETCH لتمكين جلب الصلة الخارجية لمجموعة معينة أو اقتران متعدد إلى واحد أو واحد لواحد لاغي، أو JOIN FETCH للتمكين جلب الصلة الداخلية لارتباط متعدد إلى واحد أو واحد لواحد غير قابل للإلغاء.لا تحترم استعلامات HQL أي جلب = "انضمام" محدد في مستند التعيين.

Answer 3

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

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

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

Answer 4

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

Answer 5

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

Answer 6

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

يمكنك العثور على مزيد من المعلومات هنا:

• http://tech.puredanger.com/2009/07/10/hibernate-query-cache/

Answer 7

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

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

Answer 8

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

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

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

وأيضًا إذا كتبت HQL في ملفات aspx.cs الخاصة بك، فأنت مقترن بإحكام بـ DAL الخاص بك.

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

Answer 9

لاستخدام أفضل ما في العالمين، والتعبيرية وجوامع HQL والطبيعة الديناميكية لمعايير النظر في استخدام Querydsl .

وQuerydsl يدعم JPA / السبات، JDO، SQL والمجموعات.

وأنا معيل من Querydsl، لذلك هذا الجواب هو منحاز.

Answer 10

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

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

• تفرض المعايير. createAlias("obj") صلة داخلية بدلاً من صلة خارجية محتملة
• لا يمكنك إنشاء نفس الاسم المستعار مرتين
• بعض عبارات SQL ليس لها نظير معايير بسيط (مثل التحديد الفرعي)
• إلخ.

أميل إلى استخدام HQL عندما أريد استعلامات مشابهة لـ SQL (حذف من المستخدمين حيث الحالة='محظورة')، وأميل إلى استخدام المعايير عندما لا أرغب في استخدام إلحاق السلسلة.

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

Answer 11

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

ومعايير الاستعلامات أقل التعبيرية ويمكنك في نهاية المتابعة بسهولة مع معقد جدا وغير فعال <لأ href = "http://vladmihalcea.com/hibernate-facts-always-check-criteria-api-sql-queries/ "يختلط =" نوفولو noreferrer "> SQL إنشاء الاستعلام . أنا مرة انضم الى تطبيق المشاريع الكبيرة حيث كان معايير API طريقة الاستعلام الافتراضي وحتى لا اسعة رمز المراجعة يمكن التغلب على الرعب من الذين لا يعرفون ما الاستفسارات SQL نحن ذاهبون في نهاية المطاف مع.

وJPQL أو HQL هو أكثر تعبيرا بكثير، وانه من الاسهل بكثير للتنبؤ المرتبطة الاستعلام SQL التي تم إنشاؤها. كما أنه من الأسهل بكثير لمراجعة المرء الاستفسارات HQL من تلك المعايير.

ومعظم حالات الاستخدام كيان الاستعلام لا تتطلب ديناميكية حيث شروط حتى تتمكن من تنفيذ معظم الاستعلامات مع JPQL بينما يترك معايير لتلك الديناميكية.

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

Answer 12

ومعايير المعهد يوفر ميزة واحدة المتميزة التي لا SQL أو HQL يقدمها. بمعنى آخر. لأنها تتيح تجميع فحص وقت استعلام.

Answer 13

ونحن تستخدم أساسا المعايير في تطبيق لدينا في البداية ولكن بعد أن تم استبداله HQL بسبب مشكلات في الأداء.
اساسا نحن باستخدام استعلامات معقدة للغاية مع العديد ينضم الأمر الذي يؤدي إلى استعلامات متعددة في المعايير ولكن هو الأمثل للغاية في HQL.
وهذه القضية هي التي نستخدمها فقط عدة propeties على كائن معين والأشياء يست كاملة. مع معايير كانت المشكلة أيضا سلسلة سلسلة.
أود أن أقول إذا كنت تحتاج إلى عرض الاسم واللقب المستخدم في HQL فمن السهل جدا (name || ' ' || surname) لكن في Crteria هذا غير ممكن.
للتغلب على هذه استخدمنا ResultTransormers، حيث كانت هناك طرق حيث تم تنفيذ هذه سلسلة لنتيجة الحاجة.
اليوم نحن نستخدم بشكل رئيسي HQL مثل هذا:

String hql = "select " +
            "c.uuid as uuid," +
            "c.name as name," +
            "c.objective as objective," +
            "c.startDate as startDate," +
            "c.endDate as endDate," +
            "c.description as description," +
            "s.status as status," +
            "t.type as type " +
            "from " + Campaign.class.getName() + " c " +
            "left join c.type t " +
            "left join c.status s";

Query query =  hibernateTemplate.getSessionFactory().getCurrentSession().getSession(EntityMode.MAP).createQuery(hql);
query.setResultTransformer(Transformers.ALIAS_TO_ENTITY_MAP);
return query.list();

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

Answer 14

• تهدف HQL إلى إجراء عمليات التحديد وغير التحديد على البيانات، ولكن المعايير مخصصة فقط لتحديد البيانات، ولا يمكننا تنفيذ عمليات غير التحديد باستخدام المعايير
• تعد HQL مناسبة لتنفيذ الاستعلامات الثابتة، بينما تكون المعايير مناسبة لتنفيذ الاستعلامات الديناميكية
• لا تدعم HQL مفهوم ترقيم الصفحات، ولكن يمكننا تحقيق ترقيم الصفحات باستخدام المعايير
• المعايير المستخدمة تستغرق المزيد من الوقت لتنفيذ HQL
• مع المعايير، نحن آمنون مع SQL حقن بسبب توليد الاستعلام الديناميكي الخاص به ولكن في HQL نظرًا لأن استعلاماتك إما ثابتة أو ذات معلمات، فلا يوجد أمان من SQL حقن.

مصدر

Answer 15

ومعايير الاستعلام عن حيوي يمكننا بناء استعلام يستند إلى حالة inputs..In لدينا الاستعلام HQL هو الاستعلام ثابت مرة واحدة نبني أننا لا نستطيع تغيير بنية الاستعلام.

Answer 16

وأنا لا أريد أن ركلة حصان خاسر هنا، ولكن من المهم الإشارة إلى أن معايير وإهمال الاستفسارات الآن. استخدام HQL.

Answer 17

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

Answer 18

معظم الإجابات هنا مضللة وأذكر ذلك Criteria Queries أبطأ من HQL, ، وهذا ليس هو الحال في الواقع.

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

وأيضا مع الاستعلام عن المعايير لقد حصلت التحكم الموجه للكائنات الذي ليس هناك مع HQL.

لمزيد من المعلومات اقرأ هذه الإجابة هنا.

Answer 19

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

Answer 20

وهذه الوظيفة هي قديمة جدا. معظم الإجابات الحديث عن معايير السبات، وليس معايير نقابة الصحفيين. JPA 2.1 أضاف CriteriaDelete / CriteriaUpdate، وEntityGraph التي تسيطر على ما لجلب بالضبط. معايير API هو أفضل منذ جافا OO. هذا هو السبب في إنشاء النقابة. عندما يتم ترجمة JPQL، فإنه سوف تترجم إلى شجرة AST (نموذج OO) قبل ترجمتها إلى SQL.

Answer 21

وHQL يمكن أن يسبب على الأمان المخاوف مثل حقن SQL.