أشياء لا أحبها عند برمجة قواعد البيانات

[shagrouni]

السلام عليكم،

توجد بعض الأمور التي شخصيا لا أحبها عند التعامل مع قواعد البيانات،
ولن أتوسع في شرح الأسباب.

بسم الله نبدأ:
1- البارادوكس Paradox
وجدت أن اكسيس أفضل منها بكثير من حيث المتانة والاعتمادية والمرونة والسرعة.
2
- BDE
أو Borland Database Engine أي محرك بورلاند لقواعد البيانات، فهو ذو تصميم
قديم بمفاهيم قديمة، وسبق وأن تم الاعلان عن وقف الدعم له.

3- متحكمات البيانات Dataware controls أي كل المتحكمات التي تأتي تحت باب
Data Controls مثل DBEdit و DBGrid و DBLookupListBox ..إلى آخر القائمة.

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

صعوبة السيطرة على التوليف=الكود لأنه سيكون أقل تنظيما بسبب توزعه على
مناولات الأحداث الخاصة بـ Dataset مثل BeforeInsert ، BeforeDelete .
وبالتالي مراجعة ومعاينة شروط الإدخال و العرض ستكون أصعب. أيضا، ستجد نفسك
مقيدا أكثر عند عمليات الترقية أو الصيانة أو المراجعة وإزالة الأعطال،
كما أن هذه المتحكمات تكون حساسة جدا أمام أي تغيير يتم على مستوى قاعدة
البيانات إذا تم تعديل حقل أو جدول.

أيضا فإن متحكمات البيانات سوف تتعارض مع مبادئ تصميم التطبيق بالمنحى
للكائن OOD، ومبادئ فصل العرض عن المنطقيات وعن خزن البيانات.

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

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

أتمنى أن أرى مثل هذا الحل في دلفي.

4- استخدام عمليات مثل: Edit و Addو Post و Filterو Indexالتي تكون
تابعة ل Dataset.

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

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

هذه بعض مما لا أحب التعامل مع عند برمجة تطبيقات قواعد البيانات. قد يقول
القائل وما ذا تركت؟ لكن صدقوني كل تسهيل برمجي يتم تقديمه تكون مقابله قيود
أكثر على حرية حركتك.

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

[nabilkeb]

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

كل تسهيل برمجي يتم تقديمه تكون مقابله قيود
أكثر على حرية حركتك

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

[shagrouni]

السلام عليكم

نعم يا سيدي، الحكمة أن تصل إلى غرضك بأسرع ما يمكن وبأقل عوائق.

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

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

جرب أن يكون لديك قاعدة بيانات بأكثر من 30 جدول رئيسي –وليس مساعد- وتطبيقات Client/Server
على نفس قاعدة البيانات.

حرب أن تتضمن تطبيقاتك وحدات اختبار Unit Tests .

جرب أن تعتمد في هذه التطبيقات على مفاهيم المنحى للكائن Object Oriented في تصميم مكونات
الأعمال فيها.

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

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

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

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

.

[nabilkeb]

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

و ختاما بالتوفيق أخي الكريم لك و لنا جميعا.

[محمد عبد العزيز]

السلام عليكم ورحمة الله

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

البارادوكس Paradox
وجدت أن اكسيس أفضل منها بكثير

قواعد البيانات ليس Paradox و Access فقط، دلفي يدعم تقريبا كل قواعد البيانات الموجودة
والتي لا يدعمها الباب مفتوح للمبرمج/المطور ان يضيف الدعم بنفسه
هل جربت مثلا Firebird ؟

BDE سبق وأن تم الاعلان عن وقف الدعم له

صحيح، مع ذلك لا يزال موجود بدلفي 2010 و قريبا بدلفي 2011
والاهم منذ اصدارات دلفي القديمة هناك بدائل اخرى غيره للتعامل مع قواعد البيانات

[shagrouni]

مهلا مهلا مهلا

أولا السلام عليكم

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

أولا، إن دلفي هي هوائي التي أتنفسه منذ الإصدار الأول وما زلت أتنفسها حتى الآن. ولا نية قريبة لي بتنفس هواء غير هواها.

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

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

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

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

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

- لم أقل أن متحكمات البيانات في دلفي سيئة بل قلت: وأقتبس: " وهذا رائع بالفعل من حيث تسهيل البرمجة وتصميم التطبيق بصريا وبسرعة. ولكن فقط عندما يكون التطبيق صغير الحجم ."

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

@الأخ nabilkeb : نحن هنا في منتدى، بطبيعته أن نضع أرائنا فيه عفو الخاطر ، ولست بالضرورة أن أكون ملزما بإتباع منهجية أكاديمية صارمة، تفرض علي الاستفاضة في المقدمات والنتائج و المزايا و العيوب.

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

معك حق، وآسف للجميع.

@الأخ ramijz : أنا أيضا لدي برنامج بقاعدة بيانات اكسيس يتشارك بها عدد من المستخدمين، واعتمدت فيه على متحكمات البيانات التي ذكرتها ولا يزال البرنامج يعمل منذ عشر سنين ولا مشاكل.

@ B.M.AbdelAziZ: أخي، خجلي منك يغلب رغبتي في التعليق على مشاركتك التي شرفتني. ولكن أحاول:
- " ذو خبرة ولك باع ": في المشاريع الفاشلة نعم، في البرمجة تعلمت أن الخبرة تكون في مجال دون آخر ، وشخصيا تتلمذت عند أناس كانوا تلاميذ لدي.

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

- <هل جربت مثلا Firebird> لا لم أجربها حديثا، وأنا مهتم بجانب Embedded فيها.

- بالنسبة لـ BDE أعلم أنه ليس البديل الوحيد، ما قصدته وقف التطوير به واستبداله بـ DbExpress وأظن أن الدعم المتبقي له هو أن يتماشى مع اليونيكود و بيئة 64 للحفاظ على توافقية مع العدد الكبير من التطبيقات التي تستخدمه.

شكرا على سعة صدركم

[محمد نسمان]

أخ خالد، أنا معك في كلامك في أول ثلاث نقاط، وبصراحة كنت من أشد المعجبين بعملية الربط المباشر Data Aware controls، عند بداية تعلمي للدلفي لكن مع مرور الوقت وجدت ان السهولة تضيع علي الكثير من المرونة، ومنذ حوالي أربع سنوات لم أعد استخدمها ما عدا DBgrid ومشتقاته.

أيضاً الباردوكس كانت خيار جيد مع دلفي 1 و2، وكانت سابقة في زمانها لكن لا أنصح اي احد في استخدماها في البرامج ما عدا للتعليم حيث يوجد لها اكثر عدد من المقالات على الانترنت، ولكنها تعلم برمجة سيئة لإعتمادها بشكل اساسي على مفهوم Local database، فمثلاً هناك الكثير ممن يستخدمون FindNext, Locate مع قواعد بيانات مثل Sql server وهذا اعتبره مصيبة.

أذكر قبل حوالي 5 سنوات أو أكثر قمت ببرمجة برنامج بشكل سريع واستخدمت به Data Aware controls للسرعة وايضاً Locate مع Sql server وعند تشغليه من خلال شبكة بحوالي 12 جهاز وبعد زيادة حجمة البيانات، أصبح هناك بطئ شديد في البرنامج واكتشفت ان المشكلة في Locate، حيث انها تقوم بجلب جميع البيانات من السيرفر ومن ثم تقوم بالبحث، طبعاً هي مخصصة للعمل مع باردوكس لان كل البيانات تكون موجودة في الذاكرة لذا تكون سريعة جداً في التعامل معه.

ومنذ حوالي 5 سنوات بدات بتغير طريقتي في التعامل مع قواعد البيانات فأصبحت لا استخدم TTable واخواتها الا في حالات نادرة واستخدم فقط TQuery ومشتقاتها.أيضاً ابتعدت عن كل طرق مكونات قواعد البيانات الموجودة مع دلفي، واستبدلتها بالمكونات الخاصة ب DevArt مثل MyDac,ODac, SDac، فحصلت على سرعة كبيرة وايضاً عدم الحاجة لوجود مكتبات للعمل مع قواعد البيانات الا في حالات خاصة.

بالنسبة للنقطة 4 فأنا أستخدم جمل Insert, Update, Delete بكثرة مباشرة وحتى بدون استخدام مكونات بل بتنفيذ الأمر من خلال الكونكشن مثل TmyConnection.ExeSql

لكني ايضا استخدم TmyQuery.append or TMyQuery.edit وPost ايضاً حيث ان جميع مكونات DevArt تقوم بتوليد جمل Insert,Update,Delete في وضع التصميم وتسمح لي بالتحكم بها بالشكل المراد وايضاً بإستخدام المعاملات parametrized queries.

اما النقطة الخامسة فهناك جزء كبير من الكود Bussiness Logic اضعه ضمن DataModule ووحدات أخرى ضمن Classes، واقوم بإنشاء المكونات برمجية، لكن ايضاً استخدم المكونات الجاهز مثل Tquery من على النماذج لتسهيل العمل وخاصة احيانا لعرض البيانات ضمن DBGrid او تقرير لنتيجة الإستفسار الموجودة.

أيضاً أرد ان اضيف نقطة جديدة وهي إستخدام جمل Sql بدون معاملات مثل

PHP كود :

qry1.SQL.Text := 'select * from mytable where name = ' + Edit1.Text + ' and city = ' + Edit2.Text; 


بدلاً من

PHP كود :

qry1.SQL.Text := 'select * from mytable where name = :n and city = :c';
  qry1.ParamByName('n').AsString := Edit1.Text;
  qry2.ParamByName('c').AsString := Edit2.Text; 


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

والمشكلة الثانية لو تعود المبرمج على هذه الطريقة في برمجة الويب فسيصبح موقع مستودع خصب لل Sql Injection.

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

[shagrouni]

السلام عليكم

أخي محمد
بالنسبة لعرض التسجيلات أنا استخدم مكون ٍStringGrid عبر إجرائية تقوم بقراءة Dataset وتحويلها
لمصفوفة أو TStrings ثم تمريرها ل StringGrid . وذلك حتى أتخلص من احتياجي ل DBGrid .
أحب دائما أن لا يكون للشاشات أية علاقة بتفاصيل قاعدة البيانات.

أنا أيضا لا أستخدم الباراميتر في جمل SQL فهي تشوش علي مقروئية الكود. و أتمنى لو يكون لدلفي
نفس خاصية C# عند صياغة متغير نصي قد يمتد لعدة أسطر مثلا باستخدام العلامة @ قيل النص:

PHP كود :

string s;
            s = @"SELECT fld1, fld2, fld3
                  FROM MyTable
                  WHERE fld1 = 2";
  بدلا من
  S := ‘SELECT fld1, fld2, fld3 ’ +
       ‘FROM MyTable ‘ +
       ‘WHERE fld1 = 2’; 


SQL Injection هي مشكلة حتى في التطبيقات المكتبية، أنا أقوم بفحص القيمة قبل وضعها في جملة SQL
لمعالجة العلامات أو الكلمات المشبوهة.

جمل Edit Post أستخدمهم في البرامج والأدوات السريعة الخارجية (أدوات مطبخ داخلي) لمراجعة وصيانة قواعد البيانات الخاصة بالتطبيقات، ولكن في التطبيقات نفسها أستخدم إجرائيات مثل:

PHP كود :

SQLUpdate(const TableName: string; AValues: TStringList; sWhere: string); 


فأقوم بتمرير اسم الجدول و أسماء الحقول وقيمها وجملة الشرط. وتقوم الإجرائية بصياغة جملة SQL وتنفيذها.

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

[محمد نسمان]

بالنسبة لعرض التسجيلات أنا استخدم مكون ٍStringGrid عبر إجرائية تقوم بقراءة Dataset وتحويلها
لمصفوفة أو TStrings ثم تمريرها ل StringGrid . وذلك حتى أتخلص من احتياجي ل DBGrid .
أحب دائما أن لا يكون للشاشات أية علاقة بتفاصيل قاعدة البيانات.

بصراحة أستخدمه فقط في حالات نادرة، في كثير من الأحيان أقوم بإستخدام جدول في الذاكرة مثل VirtualTable أو TClientDataset لعرض البيانات ضمن ال DBGrid، وبذلك أتخلص من إتصاله بقاعدة البيانات ولكن أحصل على مميزات كثيرة بدون الحاجة لكتابة مزيد من الكود، وخاصة إنني لا أستخدم ال DBGrid نفسه ولكن مكونات من شركات أخرى بها مميزات كثيرة من الموجود مع ehLib أو InfoPower لان بهم دعم RTL.

أنا أيضا لا أستخدم الباراميتر في جمل SQL فهي تشوش علي مقروئية الكود

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

أما بالنسبة لرمز @ Verbatim character، فإن بيئة التطوير تقوم بشيء مشابه حيث هي تقوم بإغلاق اخر السطر ووضع علامة + بشكل تلقائي، لكن هذا أعتقد مع دلفي 2006 وما بعد.

أيضاً مشكلة ال Verbatim character، هي انه يتم التعامل مع بكل المسافات المتروكة مثلا

كود :

s = @"Hello World";

فسوف يتم تمرير الجملة بكل المسافات التي قبل كلمة World، وهذا فيه .زيادة في البيانات المرسلة للسيرفر بدون داعي

أنا تمثل عندي ال DataModule مكتبة كبيرة أستخدمها مع جميع البرامج للدوال الجاهزة التي اضيف كل فترة وفترة وجميعها مكتوبة ال SQL ولا أعتقد إني أستخدم مكون يعتمد على TTable في برامج، وحتى ال ComboBox اقوم بتعبئتها في وقت التنفيذ ولا تكون مرتبطة مع أي مكون لقواعد البيانات

[ghostdz]

السلام عليكم
بارك الله فيكم على هذا النقاش و المعلومات القيمة
أضيف معلومة بسيطة بخصوص جمل SQL
يفضل أن تكون جمل sql موجودة في دوال بقاعدة البيانات (stored procedure أو query) حيث تكون سريعة لأن قاعدة البيانات تكون قد حددت مسار التنفيذ الأسرع (schema execution) سلفا وليس في مرحلة التنفيذ