أيهم تفضل : ORM ، SQL Procedural Language أو xDBC

مطروح اسئلة عديدة مثل هذا السؤال في موقع stackoverflow وبالمناسبة الموقع مليااااان فوائد،

جلست عليه شهرين وطلعت بفوائد ما كنت أحلم بها جاوبت على اسئلة كثيرة جدا صار لها سنوات كانت تدور في بالي،

بعض المعلومات المتعلقة بالمضوع

- stored procedure تكتب بالـ pl/sql وما شابهها

- بشكل عام الأفضل لـ منطق العمل business logic انه يكون في طبقة واحدة، إذا استخدمت stored procedure تكون خالفت هذا الشيء وراح يتعبك كما ذكرت يصير منطق العمل مقسوم في مكانين وبلغتين مختلفتين

- تلجأ لـ stored procedure في حالات معينة

ودنا لو تخبرنا لماذا الـ orm وضعته للحالات البسيطة، أعتقد أنه ناضج وينفع حتى في المشاريع الكبيرة

بـارع كتب:

ودنا لو تخبرنا لماذا الـ orm وضعته للحالات البسيطة، أعتقد أنه ناضج وينفع حتى في المشاريع الكبيرة

كنت أتكلم من منطلق تجربة شخصية بسيطة وليس شيء أجزم به. المشكلة التي واجهتها تظهر عندما أختار ORM و أحتاج لعمل join بين أربعة جداول مع Aggregate functions الخ من الاستعلامات المعقدة. خصوصاً لو كان مطلوب منك تقرير Report ، و ليس مجرد mapping بين جدول و Object . قد يكون كلامي خطأ ، لذلك أحببت سماع تجربة الآخرين.

اقتباس

- تلجأ لـ stored procedure في حالات معينة

مثل ماذا ؟

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

ال ORM هو أفضل شئ بالنسبة لي ولاأفضل إنزل لأكواد SQL بدون داعي طالما أقدر اتعامل مع كائنات

أما عن الأداء فغير ملحوظ بالقدر المتصور بالإضافة إن العائد كبير جدا بإستخدام ORM مناسب (على سبيل المثال جرب تنقل مشروع لك من قاعدة بيانات إلى أخرى وأحسب ماتتكلفة بدعم قاعدة أخرى في حين إنك ربما لاتحتاج إلا لسطر واحد فقط!

غيرذلك فال ORM يسمحلك في الغالب بأن تتعامل مع SQL مباشرة إذا أردت ذلك

اما عن الإستعلامات المعقدة فالأمر في حدود تعاملي أبسط كثيرا عبر ال ORM وناهيك عن ادارة العلاقات وهي لوحدها ميزة لاتقاوم

*معظم إستخدامي ل Django ORM وبعض الأحيان SQLAlchemey

بالنسبه لل PL فهي في الغالب تستخدم لعمل منطق عمل (business logic) لا يرجع بيانات كثيره في العاده حيت أن ال Stored Procedures لا يوجد شئ إسمه Return value فيها (أتحدث عن Oracle PL/SQL تحديدا) ...

أعرف أنك قادر على إرجاع نتيجه كبيره (عدة صفوف) عن طريق إستخدام ال Output parameters..

إذن فإن كنت تريد تنفيذ مجموعه من الجمل التي تقوم بعمل تغيرات على قاعدة البيانات دون إرجاع ناتج (أو إرجاع ناتج صغير -- scalar values) ... فإستخدم PL/SQL (أو Stored Procedures بوجه عام)

أما بالنسبه للإستعلامات فأفضل إستخدام ORM لسهولة إستخدامها... لكن المشكله التى أواجهها هنا هو إستهلاك الذاكره ... بعكس ال JDBC ...

فال JDBC هو مثله مثلا ال Cursor يقوم بإرجاع صف بصف من قاعدة البيانات ( أو على حسب إعدادك له .. ) أما ال ORM تقوم بإرجاع النتيجه كلها على هيئة مصفوفه في الذاكره .... و هذا يؤثر على الذاكره إن كنت تريد أرجاع نتائج كبيره مثلا 100k من قاعدة البيانات ...

الملخص:

للعمليات الأخري غير الإستعلام (إضافه- حذف - تعديل )... أفضل ال SP

للإستعلام و إرجاع نتائح قليله (عدة ألاف) أفضل ال ORM

للإستعلامات التى تقوم بإرجاع نتائج ضحمه ( أكثر من 100k ) أفضل ال JDBC

اقتباس

أما ال ORM تقوم بإرجاع النتيجه كلها على هيئة مصفوفه في الذاكره

هذا غير دقيق فمثلا مع django لايقوم بإعادة النتائج مرة واحدة كل مايعطيك هو "وعد" بالحصول على تلك النتائج.

يوجد في هايبرنيت lazy-loading

وفيه أكثر من Fetching strategies

اقتباس

هذا غير دقيق فمثلا مع django لايقوم بإعادة النتائج مرة واحدة كل مايعطيك هو "وعد" بالحصول على تلك النتائج.

شكرا على المعلومه ...... حقيقه كانت تجربتى على TopLink Essentials ...

اقتباس

جد في هايبرنيت lazy-loading

وفيه أكثر من Fetching strategies

هذا يا أخ بارع - على حسب ما أفهم - خاص بال association و ليس بال entity الأصليه ...

بمعنى أنك لو قلت له "select o from MyObject" ففي Hibernate سيقوم بإرجاع كل النتائج حتى لو كان عدد النتائج 1000000 صف ...

أما موضوع ال lazy-loading و خلافه فهو ينطبق على حالة إذا كانت هناك association ... مثل "select o from MyObject join o.someAssociation "

أتبع مبدأ في عملي و هو عدم أخذ لغات البرمجة أو قواعد البيانات كلعبه أنتقل من واحده إلى الأخرى كل فترة فالاول أدرس ثم أستقر على لغة تناسب إحتياجاتي و نفس الإسلوب ينطبق على قاعدة البيانات و لهذا أفضل SQL Procedural Languages فهي تعطيني سرعة في الأداء ففي حالات كثيرة أحتياج لإرسال بيانات تصل إلى أكثر من 20 ألف سجل على هيئة csv أو xml و أريد أن أقوم بعمل حسابات عليها كثيره و إختبار سجلات في قاعده البيانات و لهذا SQL Procedural Languages تعطيني أداء قوي و سريع و هذا غير أنها تعطيني القوة في كتابة إستعلامات معقده بدون مشاكل.

بالنسبة لتغيير قواعد البيانات فمن وجه نظري إذا كنت أريد أن أنتقل في يوم من الأيام فسوف أنتقل لقاعده بيانات تعطيني نفس الأداء و الادوات أو أقوى و إلا لماذا انتقل و هنا سوف أتعرف على البديل أو التغيرات الطفيفة في SQL Procedural Languages و لا يوجد مشكله وقتها عندي.

اقتباس

بالنسبه لل PL فهي في الغالب تستخدم لعمل منطق عمل (business logic) لا يرجع بيانات كثيره في العاده حيت أن ال Stored Procedures لا يوجد شئ إسمه Return value فيها (أتحدث عن Oracle PL/SQL تحديدا) ...

أعرف أنك قادر على إرجاع نتيجه كبيره (عدة صفوف) عن طريق إستخدام ال Output parameters..

ألقي نظرة على PL/pgSQL أو على PostgreSQL عموماً فأنها تمكنك من إرجاع عده صفوف بدون إستخدام Output parameters و ذلك بتحديد نوع Return value إلى Record كما أنه يمكنك أن تحدد أنواع أخرى مثل Table أو يمكنك إنشاء Type جديد وتختاره كهيكلة إرجاع.

السلام عليكم ..

كعادة مواضيعك تفتح الافق وتجعل الواحد يفكر :lol:

على فرضية ان الDatabase هي Relational وهي Perfectly maintained

اعتقد انه من المجدي وضع معايير للideal connectivity approach

1. Based on mathematical model

بمعنى ان اي عمليه تتم يمكننا تمثيلها رياضياً (عادة عن طريق الجبرا والset theory ) فائدة هذا التمثيل اثبات خصائص اخرى مثل الdata consistency

كذلك ان المعلومه او البيانات المتواجده لها معنى محدد clear semantics

2. Platform Independent

لايمكنني ان اتصور طريقه تعتمد على بيئه/نظام محدد

3. Simplicity

لاشك ان القدره على ان يتعلم المطور الطريقه بسهوله عامل مهم لنجاحها

4. Separation of Concern

المفترض ان يتم الفصل بين الBusiness Logic والOperational processes العاديه

5. Maintain data properties

فالطريقه المستخدمه لابد ان اضمن انها لن تخلق مشكله جديده في قواعد البيانات او Persistence Layer مثل data redudancy

بكل حال من الاحوال التواصل مع قواعد البيانات لايمكنه ان يستمر بالطريقه التقليديه لعدة اسباب اهمها هو عدم قدرة قواعد البيانات على ان تكون صديقه للSemantic web الا عن طريق وسيط اخر مثل الOntologies

بيني وبينك قد يكون هذا (بل بالفعل) هو سبب نجاح الRDBMS لانها لاتتكلم مع احد الا ب 1+1=2

يمكنك بالاخير اغفال كل كلامي والاخذ بالPure JDBC لانه هو standard بالسوق فكل vendor عنده JDBC :cool:

طبعا الموضوع ملهم وكله فلسفه من طرفي لكني لم اوفق في ايجاد اوراق علميه -جيده- تتكلم عنه.

اقتباس

أما عن الأداء فغير ملحوظ بالقدر المتصور بالإضافة إن العائد كبير جدا بإستخدام ORM مناسب (على سبيل المثال جرب تنقل مشروع لك من قاعدة بيانات إلى أخرى وأحسب ماتتكلفة بدعم قاعدة أخرى في حين إنك ربما لاتحتاج إلا لسطر واحد فقط!

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

أعرف أن ORM يسهل الإنتقال و لكن أعتمد عليه بحيث إستخدامه لا يتعدى أكثر من الحصول على بيانات أو إرسال البيانات في حدود Standard SQL بينما الإعتماد الكلي على قاعدة البيانات نفسها فماذا لو قمت بتصميم برنامج لحجز تذاكر الطياران مثلاً و البرنامج يعمل بحيث يخدم الدوله كامله بواسطه الشبكة و كان هناك إثنان يريدون حجز مقعد و كان هو الوحيد المتاح و الإثنان قامو بالطلب في نفس الوقت؟

أرى أن إستخدام PL/pgSQL يعد الحل الأفضل في هذا الموقف.

اقتباس

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

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

اقتباس

أعرف أن ORM يسهل الإنتقال و لكن أعتمد عليه بحيث إستخدامه لا يتعدى أكثر من الحصول على بيانات أو إرسال البيانات في حدود Standard SQL بينما الإعتماد الكلي على قاعدة البيانات نفسها فماذا لو قمت بتصميم برنامج لحجز تذاكر الطياران مثلاً و البرنامج يعمل بحيث يخدم الدوله كامله بواسطه الشبكة و كان هناك إثنان يريدون حجز مقعد و كان هو الوحيد المتاح و الإثنان قامو بالطلب في نفس الوقت؟

أرى أن إستخدام PL/pgSQL يعد الحل الأفضل في هذا الموقف.

هل تعتقد حقا أنك ستعاني من هذه المشكلة مع ORM ؟

اقتباس

هل تعتقد حقا أنك ستعاني من هذه المشكلة مع ORM ؟

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

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

للتوضيح أخي عبد الله يريد أن يعرف لماذا يقال على SQL Procedural Languages فحبيت أذكر بأن عندما أحب أن أعالج أكثر من 20 ألف بيان مثلاً تعتبر هنا أسرع من أي طريقه أخرى و أمنه كمان

اقتباس

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

ال ORM هو طبقة فوق SQL المجردة فيمكن أن تتوقع (مزايا ماتحتها) وتحسينات خاصة لل drivers المدعمة.

وتحت أمركم

معلومات مفيدة ، لكن بعض الامور لم استوعبها :

اقتباس

للعمليات الأخري غير الإستعلام (إضافه- حذف - تعديل )... أفضل ال SP

هل يمكن آن تسهب أخي في شرح هذا السطر ؟ ليش ارجاع صفوف غير جيد من وجهة نظرك ؟ كنت أعمل في أحد الشركات و كانت لديهم Procedure مقدسه اسمها GetLOV حيث 25٪ من الاستعلامات تعاد عن طزيق بارمترات في هذه الدالة. المقصد هل لديك تجربة شخصية حول هذه النقطة.

اقتباس

و لهذا SQL Procedural Languages تعطيني أداء قوي و سريع

هل سبق ، أن عملت مقارنة ؟ لماذا آسرع و أقوى .

كلامك أخ asm-soft حول أن أحد مميزات PL/SQL و ما شابهها هو توحيد كتابة business logic و بالتالي تستطيع استخدام هذا الكنز من Procedures عن طريق أي لغة هو كلام جميل و رائع لو نظرنا له على بعد 3 أمتار لكن لو دققت قليلاً ستجد أنه يمكنك أن تكتب نفس هذه الاجراءات باستخدام سكالا أو جافا ( عن طريق JDBC مثلا ) و بالتالي تتخاطب أي لغه مع هذه الخدمات عبر XML مثلاً . ستقول أنه أبطأ ، سأقول هات الدليل :-) .

عموما اهتمامي في ORM زاد بقراءة المشاركات

اقتباس

هل يمكن آن تسهب أخي في شرح هذا السطر ؟ ليش ارجاع صفوف غير جيد من وجهة نظرك ؟ كنت أعمل في أحد الشركات و كانت لديهم Procedure مقدسه اسمها GetLOV حيث 25٪ من الاستعلامات تعاد عن طزيق بارمترات في هذه الدالة. المقصد هل لديك تجربة شخصية حول هذه النقطة.

الشركة التى أعمل بها حاليا هى PL-based company .... فمعظم الكود القديم هو عباره عن PLs ...

مشكلة ال PL عند إرجاع بيانات كبيره (table مثلا ) أنك تحتاج أن تكتب كود لا داعى له (plumbing code) لإستقبال هذا النوع الجديد ... كما أن ال PL هى لغة إجرائيه ... و زمن اللغات الإجرائيه قد ولىً ....

اقتباس

لو نظرنا له على بعد 3 أمتار لكن لو دققت قليلاً ستجد أنه يمكنك أن تكتب نفس هذه الاجراءات باستخدام سكالا أو جافا ( عن طريق JDBC مثلا ) و بالتالي تتخاطب أي لغه مع هذه الخدمات عبر XML مثلاً . ستقول أنه أبطأ ، سأقول هات الدليل :-) .

حسناً أستحمل كلامي شويه فكالعاده لا أستطيع التعبير و لذلك حاول أن تتعايش معي و تدخل جوه مخي لتفهمي

في المشاركة السابقه قولت لاخي أحمد أن المثال ممكن أن يصمم بكل الطرق و منها PL و ORM و XDBC و لكن إختياري لـ PL يتوقف على المطلوب فأستخدم أحياناً كثيرة ORM و لكن PL أساسي و هذا ليس معناه إستخدام PL في كل الإحتمالات (على الفاضي و المليان) و في الاخر هي مسئله موازنات كما قال أخي أحمد.

و لتوضيح نظرتي على السرعة سأتلكم عن قواعد البيانات أولاً و سأذكرك بـ MySQL على سبيل المثال فأشتهرت هذه القاعده بسرعتها و عندما تدخل على موقعها و في صفحات المساعده تخبرك بالزمن المطلوب لفتح الجدول و غلقه و الزمن المطلوب لتسجيل Index و هكذا و كله يقاس بالجزء من الثانية فلماذا تقاس هذه السرعات و لماذا التباهي بها ؟؟؟

مثال أخر: لماذا قاعده بيانات SQLite سريعه جداً !!!!

إذا نظرنا في كل قواعد البيانات هذه فسنجد ظروف مختلفة بين كل واحده فالـ MySQL تستخدم TCP في الإتصال أما SQLite فيتم دمج Driver داخل البرنامج و لا تتعامل مع TCP و بهذا نحصل على سرعة أعلى في الفتح و الغلق و القراءة و الكتابة في SQLite عن MySQL التي تتباهى بسرعتها مع العلم أنه لا يجوز المقارنه بينهم فالأصح المقارنه بين MySQL و PostgreSQL على سبيل المثال و لكن ذكرت هذه المقارنه لتوضيح أن هناك ظروف مختلفه لكل مشروع

إذا عدنا إلى ORM أو XDBC فسنجد أننا نستخدم في الاخر مكتبة أو driver للإتصال بقاعده البيانات و يتم الإتصال بواسطه TCP دائماً مع قواعد البيانات مثل Oracel و MySQL و SQL server و PostgreSQL فإذا يجب أن نضع في الإعتبار أن هناك وقت سيضيع في الإتصال و هذا أولاً

ثانياً و عن تجربة شخصية صممت برنامج و كان في إصدارة الاول يعمل على استقبال ملفات بها سجلات عددها كثير جداً و كل سجل به أعمده يجب حساب إحتمالات له كثيرة منها هل إسم العميل مسجل أم لا و رقم الورقة الماليه مسجل أم لا لهذا السجل (هو برنامج يخدم شركات التداول) و التاريخ و كود العمليه القابل للتكرار حسب التاريخ و تاريخ التسويه و تصحيح تاريخ التسويه حسب أيام العمل و الاجازات و الكثير من الإختبارات الأخرى فإذا حسبنا كل هذه الإختبارات فكم سنستخدم من وقت في إرسال SQL و إستقبال النتائج من قاعده البيانات سواء استخدمنا ORM أو XDBC في المقابل لو كتبنا كل هذه الإختبارات في PL فسنجد أننا استغنينا عن إرسال العديد من SQL و إستقبال النتائج عبر إتصال TCP و في نفس الوقت استخدمنا إمكانيات PL في توفير العديد من الإستعلامات نظراً لإتحادها مع قاعده البيانات نفسها.

النتيجة: في الإصدار الاول كان زمن حساب التسويه للسجلات و التسجيل تقريباً من 5 إلى 10 دقائق و هذا لحوالي 20 ألف سجل فقط و عندما صممت الإصدار الثاني مستخدماً PL تم تقليص الزمن إلى 10 ثواني فقط لا غير

هل هذا المثال يكفي أم لا ؟

عموماً إستخدامي لـ ORM و PL سوياً ضربت أكثر من عصفور بحجر واحد أما XDBC فأرى أن مشكلته هي لابد من موفر للخدمه و لهذا أفضل التعامل مع PL و ORM إذا كان البرنامج يطلب ذلك و كله متوقف على إحتياجات السوق.