PDA

View Full Version : نوشتن برخی شروط در store procedure.



hossein2007
سه شنبه 13 مهر 1389, 11:09 صبح
سلام به همه دوستان.
می خواستم موضوعی رو مطرح کنم و نظرتون رو بدونم.

همون طور که کی دونید تو برنامه نویسی سه لایه شروط برنامه در لایه منطق یا همون Business Logic Layer نوشته می شه.

حالا مشکلی که وجود داره اینه که توی بسیاری از برنامه ها این شروط بستگی به داده های درون پایگاه داده داره.

مثلا: تکراری نبودن کد ملی، شماره کارت سوخت، کد پرسنلی و ... .
یا اینکه مثلا عدد یا تاریخی که کاربر وارد می کند با مقادیری که قبلا وارد شده است بررسی شود.

اینکه در لایه BLL این شروط چک شود باعث می شود که لازم باشد برای یک عمل درج مثلا تا 10 بار به دیتابیس متصل شویم و نتایج را در BLL چک کنیم و دوباره برای شرط بعدی یکبار دیگه به دیتابیس متصل شویم و ....

سوال من اینه که متصل شدن به دیتابیس و باز و بسته شدن connection چه میزان کارایی را کاهش می دهد؟

اگه جواب اینه که کاهش کارایی زیاد است آیا بررسی این گونه شروط در store procedure را پیشنهاد می کنید.

طبعا استفاده از روش دوم نگهداری برنامه را دچار مشکل می کند.

لطفا نظرات و تجربیات شخصی خود را بیان کنید.

ali.ghodrati
سه شنبه 13 مهر 1389, 11:54 صبح
سلام دوست عزیز
من خودم به شخصه تمام شروط رو توی stored procedure چک میکنم
به نظر من این بهترین راه حل هست چون اگه یه زمانی بخوای برنامه رو شبکه کنی این راه حل بیشتر به کارت میاد
راه حل مناسب برای این کار هم به نظر من این هست که تمام اطلاعات را برای ویرایش یا افزودن با پارامتر بفرستی توی stored procedure بعد اونجا تک تک valid بودن پرامتر ها رو چک کنی و پاسخ مناسب رو return کنی

M.YasPro
سه شنبه 13 مهر 1389, 12:00 عصر
سلام
باز و بسته کردن کانکشن و رفت و آمد به دیتابیس کار زمانگیری هست .
منم توی برنامه هام ترجیح میدم که بیشتر لایه business توی دیتابیس باشه ، چون این رفت وآمد ها کمتر میشه و همه چی توی دیتابیس تموم میشه .
موفق باشید .

hossein2007
سه شنبه 13 مهر 1389, 12:07 عصر
سلام
باز و بسته کردن کانکشن و رفت و آمد به دیتابیس کار زمانگیری هست .
منم توی برنامه هام ترجیح میدم که بیشتر لایه business توی دیتابیس باشه ، چون این رفت وآمد ها کمتر میشه و همه چی توی دیتابیس تموم میشه .
موفق باشید .

درباره زمانگیر بودن رفت و آمد یه مقاله مناسب علمی سراغ ندارید؟ تا بتوان تصمیم گیری کرد که بین این پارامتر و نگهداری بهتر برنامه کدام را انتخاب کنیم.

M.YasPro
سه شنبه 13 مهر 1389, 19:16 عصر
مقاله برای چی؟
به نظر شما 10 خط کد زودتر اجرا میشه یا 100 خط کد؟
خوب این رفت وامد ها و پرس و جو مستلزم اجرا شدن چندین خط کد هست ، پس ماشین کاربر رو درگیر محاسبات و اجرای کدها می کنه، پس زمانبره
موفق باشید ./

hossein2007
چهارشنبه 14 مهر 1389, 00:47 صبح
مقاله برای چی؟
به نظر شما 10 خط کد زودتر اجرا میشه یا 100 خط کد؟
خوب این رفت وامد ها و پرس و جو مستلزم اجرا شدن چندین خط کد هست ، پس ماشین کاربر رو درگیر محاسبات و اجرای کدها می کنه، پس زمانبره
موفق باشید ./

در این که این رفت و آمد ها باعث کاهش کارایی می شه از اول هم هیچ شکی نداشتم، بلکه میزان این کاهش کارایی در شرایط مختلف سوال من هست.
اگه به عنوان مثال این کاهش کارایی کم باشه می شه ازش چشم پوشی کرد و با نوشتن شروط در BLL قابلیت نگه داری برنامه را افزایش داد.
(نظر شخصی من اینه که بهترین نرم افزار ها اون هایی هستن که در درجه اول قابلیت نگهداری بالاتری دارند و بعد از آن از لحاظ کارایی و امنیت هم متناسب باشند نه لزوما ایده آل)

این مساله که توی این تاپیک مطرح شده بنظرم در تولید نرم افزار واقعا مهم هست و ممنون می شم دوستان همکاری کنند تا به نتیجه برسیم.

C Sharp
چهارشنبه 14 مهر 1389, 09:32 صبح
راه حل مناسب برای این کار هم به نظر من این هست که تمام اطلاعات را برای ویرایش یا افزودن با پارامتر بفرستی توی stored procedure بعد اونجا تک تک valid بودن پرامتر ها رو چک کنی و پاسخ مناسب رو return کنی

با توجه به راه حل بالا ، هدف از ایجاد تریگر چی بوده ؟:متفکر:

آیا بررسی تکرارای نبودن با استفاده از قید ها (constraints) امکان پذیر نیست ؟
کدوم پایگاه داده ای هست که از یونیک بودن فیلد ها پشتیبانی نکنه ؟

لایه منطق تجاری میتونه و باید معتبر بودن ورودی های کاربر رو چک کنه و بر اساس اون تصمیم گیری کنه ، اما اینکه آیا این ورودی جامعیت داده ها رو به خطر میندازه یا نه ، وظیفه لایه داده هاست

شما میتونید با طراحی اینترفیس ، و کلاسهایی که هر کدوم با توجه به این اینترفیس از پایگاه داده های متفاوت پشتیبانی میکنن ، مشکل نگهداری سیستمتون رو حل کنید ، نه اینکه وظیفه لایه داده رو به لایه منطق تجاری بسپرین.

نکته مهم دیگه ای که وجود داره اینه که شما نمیتونید امنیت سیستم و داده ها رو فدای نگهداری اون کنید . فرض کنید همه شروط در لایه منطق تجاری بررسی شد و در لایه داده ها نشد، اگه بر اثر اشتباهی شخصی بتونه به پایگاه داده وصل بشه ، هر داده ای که دوست داشته باشه میتونه وارد کنه ، بدون هیچ کنترلی!

و در آخر ، شما هیچ وقت رو به عقب حرکت نمیکنید (نباید) ، اگه انتظار دارید امروز پایگاه داده سیستمتون sql باشه و نگرانید که بعدا بشه access و این قابلیت نگهداری سیستمتون رو به خطر میندازه ، این طرز فکر کاملا اشتباهه! اگه نیاز سیستمتون در حد access هست ، پس چرا sql server انتخاب شده و اگه در حد sql server هست ، پس مطمئنا سطح پایگاه داده سیستم از sql فرا تر میره اما کمتر نمیشه ، و خودتون میدونید که مطمئنا پایگاه داده هایی در حد sql serverو بالا تر قابلیت هایی برابر یا بالاتر از اون دارند

FastCode
چهارشنبه 14 مهر 1389, 10:04 صبح
من همه تست ها رو در DAL انجام میدم.همه تست ها هم در واقع auto generate شدن.من جراءت اشتباه کردن رو ندارم.تنها چیزی که اینجا مهمه اینه که طراحی چنین برنامه ای 10 برابر یه برنامه معمولی از شما وقت میگیره.


اگه بر اثر اشتباهی شخصی بتونه به پایگاه داده وصل بشه ، هر داده ای که دوست داشته باشه میتونه وارد کنه ، بدون هیچ کنترلی!
این مشکل شماست.در واقع شما برنامتون رو به شکلی بد طراحی کردی که اگر کسی یک constraint رو bypass کنه,برنامه شما fail میشه.
یه PM به من بزن.میخوام یه چشمه از کار رو نشونت بدم.

C Sharp
چهارشنبه 14 مهر 1389, 11:03 صبح
این مشکل شماست.در واقع شما برنامتون رو به شکلی بد طراحی کردی که اگر کسی یک constraint رو bypass کنه,برنامه شما fail میشه.

مشکل کسیه که همه چیز رو تو لایه منطق تجاری تست میکنه و از قابلیت های خدا دادی RDBMS ها استفاده نمیکنه !

FastCode
چهارشنبه 14 مهر 1389, 11:15 صبح
مشکل کسیه که همه چیز رو تو لایه منطق تجاری تست میکنه و از قابلیت های خدا دادی RDBMS ها استفاده نمیکنه !
اولاً که به این روش برنامه شما کاملاً cross-database میشه.
دوماً منظورم این نبود.
منظورم این بود که اگر با یک اشتباه در دیتابیس و مثلاً با حذف شدن چندتا از constraint ها برنامه شما fail بشه بهتره یا اینکه Fail نشه؟
و مشکل دیگه این که با روش من شما فقط آخرین build رو برای مشتری کپی میکنی و هیچ کاری به دیتابیسش نداری ولی با روش شما از در و دیوار build system ت change script بالا میره.
بعد از یه مدت 2000 تا فایل این شکلی داری:
change script_89_07_14_dbo_Table1_Constraint_Swap.sql

edit:
یادم رفت بگم که اون قابلیت ها خدادادی نیستن.صبر کن پولی بشن اون موقع قیمت قابلیت ها دستت میاد.
بعد میفهمی یه برنامه enterprise نوشتن که sqlite compatible باشه یعنی چی.ok؟

M.YasPro
چهارشنبه 14 مهر 1389, 11:24 صبح
من فکر می کنم اگر جنس این شروط رو بیان کنیم بهتر میشه بحث کرد .
مثلا برای خالی بودن تکست باکسی که باید پر باشه ( مثل کد ملی) من چک کردن تو UI رو ترجیح میدم .
برای چک کردن valid بودن یه مقدار مثل کد شهرها ، خوب حتما باید رفت به دیتابیس و از اونجا چک کرد .

hossein2007
چهارشنبه 14 مهر 1389, 12:00 عصر
من فکر می کنم اگر جنس این شروط رو بیان کنیم بهتر میشه بحث کرد .
مثلا برای خالی بودن تکست باکسی که باید پر باشه ( مثل کد ملی) من چک کردن تو UI رو ترجیح میدم .
برای چک کردن valid بودن یه مقدار مثل کد شهرها ، خوب حتما باید رفت به دیتابیس و از اونجا چک کرد .

به نکته کلیدی اشاره کردید.
شروطی مانند تکراری نبودن و یا لزوم وجود یه رکورد والد برای وارد کردن رکورد فرزند (با relationship) و شروطی از این دست رو می توان با قابلیت هایی که دیتابیس مورد استفادمان می دهد اعمال کرد.

اما دقت کنید که بسیاری از شروط در مسائل واقعی فراتر از این هست.
مثلا برنامه ای که من الان دارم می نویسم مربوط به یه سازمانی است که برای کد بندی کالاهایش، روش های پیچیده و قواعد خاصی داره که طبعا این قواعد رو نمی شه با قابیلت های DBMS اعمال کرد. (این قواعد ارتباط مستقیم با داده های درون DB داره)

از این گذشته تا جایی که من فهمیدم فلسفه وجودی BLL (همون طوری که از اسمش پیدا است) قرار دادن منطق تجاری برنامه در یک مکان است، تا در صورتی که بخواهیم آن را تغییر دهیم یا حتی اشکال یابی کنیم دچار سردگمی نشویم و در واقع منطق تجاری برنامه در یک مکان متمرکز شود.

واقعیتش رو بخواهید من حتی قبول ندارم که شرط تکراری نبودن رو خارج از BLL انجام دهیم چون این به منطق برنامه ما مربوط می شه و اگه قرار باشه برخی از منطق برنامه در BLL انجام بشه و برخی خارج از آن این یه تناقض هست و فلسفه وجودی برنامه نویسی سه لایه رو نقض می کنه.

البته یه راه حل به ذهنم می رسه که یکم باید در موردش فکر کنم.(راه حلی که همزمان کارایی و قابلیت نگهداری برنامه رو حفظ کنه)

FastCode
چهارشنبه 14 مهر 1389, 12:35 عصر
البته یه راه حل به ذهنم می رسه که یکم باید در موردش فکر کنم.
خب بگو.من رو این مساله که بقیه چی فکر میکنن خیلی حساسم.

M.YasPro
چهارشنبه 14 مهر 1389, 12:41 عصر
واقعیتش رو بخواهید من حتی قبول ندارم که شرط تکراری نبودن رو خارج از BLL انجام دهیم چون این به منطق برنامه ما مربوط می شه و اگه قرار باشه برخی از منطق برنامه در BLL انجام بشه و برخی خارج از آن این یه تناقض هست و فلسفه وجودی برنامه نویسی سه لایه رو نقض می کنه.



من قبول ندارم
معماری مسئله ای فراتر از کد هست . گوشه ای از معماری توی محیط کد میشه کلاس لایبرری به نام bl . یعنی کل معماری نمیشه توی محیط کد ، نمیدونم منظورمو خوب رسوندم یا نه .

FastCode
چهارشنبه 14 مهر 1389, 13:09 عصر
یعنی کل معماری نمیشه توی محیط کد
اگر بشه چی؟
اگر بگم که من 5 تا تیم رو میشناسم که دارن روش کار میکنن چی؟اگر بگم که خودم 3 ساله دارم روش کار میکنم و جواب داده؟

C Sharp
چهارشنبه 14 مهر 1389, 13:14 عصر
اولاً که به این روش برنامه شما کاملاً cross-database میشه.
دوماً منظورم این نبود.
منظورم این بود که اگر با یک اشتباه در دیتابیس و مثلاً با حذف شدن چندتا از constraint ها برنامه شما fail بشه بهتره یا اینکه Fail نشه؟
و مشکل دیگه این که با روش من شما فقط آخرین build رو برای مشتری کپی میکنی و هیچ کاری به دیتابیسش نداری ولی با روش شما از در و دیوار build system ت change script بالا میره.
بعد از یه مدت 2000 تا فایل این شکلی داری:
change script_89_07_14_dbo_Table1_Constraint_Swap.sql

edit:
یادم رفت بگم که اون قابلیت ها خدادادی نیستن.صبر کن پولی بشن اون موقع قیمت قابلیت ها دستت میاد.
بعد میفهمی یه برنامه enterprise نوشتن که sqlite compatible باشه یعنی چی.ok؟

1- لطفا از لحن دوستانه تری استفاده کنید ، اینجا میدون بحثه نه جدل
2- منظورتون رو گویا تر بیان کنید تا دیگران همون چیزی رو بفهمن که میخواید
3- من نمیدونم کجای این حرف ایراد داره که چیزی مثل duplicate نبودن رو باید توی db چک کرد نه BLL!!!
4- دیتابیسی که خوب طراحی نشده باشه ، خوب ورودی هاش چک نشه ، کدوم سیستمی میتونه روش با اطمینان اجرا بشه ؟!
5- کجای دنیا واسه وجود Unique پول میگیرن؟!!

FastCode
چهارشنبه 14 مهر 1389, 13:19 عصر
1- لطفا از لحن دوستانه تری استفاده کنید ، اینجا میدون بحثه نه جدل
2- منظورتون رو گویا تر بیان کنید تا دیگران همون چیزی رو بفهمن که میخواید
3- من نمیدونم کجای این حرف ایراد داره که چیزی مثل duplicate نبودن رو باید توی db چک کرد نه BLL!!!
4- دیتابیسی که خوب طراحی نشده باشه ، خوب ورودی هاش چک نشه ، کدوم سیستمی میتونه روش با اطمینان اجرا بشه ؟!
5- کجای دنیا واسه وجود Unique پول میگیرن؟!!

1.منظورتون میدون جنگه نوشتید میدون بحث؟:قهقهه:
2.چیز مبهمی توش نمیبینم.:خجالت:
3.سعی میکنم براتون یه مثال آماده کنم.چند دقیقه دیگه یه PM بهت میزنم.
4.من میتونم.:بامزه:
5.همه جا.تا حالا mssql اصلی خریدی؟oracle چطور؟برم بالاتر؟TeraData خریدی؟قیمتش 10 برابر mssql ه.

C Sharp
چهارشنبه 14 مهر 1389, 13:30 عصر
1.منظورتون میدون جنگه نوشتید میدون بحث؟:قهقهه:
2.چیز مبهمی توش نمیبینم.:خجالت:
3.سعی میکنم براتون یه مثال آماده کنم.چند دقیقه دیگه یه PM بهت میزنم.
4.من میتونم.:بامزه:
5.همه جا.تا حالا mssql اصلی خریدی؟oracle چطور؟برم بالاتر؟TeraData خریدی؟قیمتش 10 برابر mssql ه.
موفق باشین!

FastCode
چهارشنبه 14 مهر 1389, 13:31 عصر
موفق باشین!
منظورتون چیه؟

M.YasPro
چهارشنبه 14 مهر 1389, 13:46 عصر
اگر بشه چی؟
اگر بگم که من 5 تا تیم رو میشناسم که دارن روش کار میکنن چی؟اگر بگم که خودم 3 ساله دارم روش کار میکنم و جواب داده؟

خوب منظورمو خوب نرسوندم ، منظور من اینه که یک معماری لزوما توی کد نمیشه که پیاده سازی بشه ، امکان داره که در بخش های دیگه هم استفاده بشه ، یعنی معماری مفهوم گسترده تری نسبت به پیاده سازی هست ،

hossein2007
چهارشنبه 14 مهر 1389, 14:01 عصر
من قبول ندارم
معماری مسئله ای فراتر از کد هست . گوشه ای از معماری توی محیط کد میشه کلاس لایبرری به نام bl . یعنی کل معماری نمیشه توی محیط کد ، نمیدونم منظورمو خوب رسوندم یا نه .

منظور من دقیقا تناقض با معماری سه لایه است نه معماری در سطوح دیگه.
وقتی بحث معماری سه لایه می شه دقیقا در مورد پیاده سازی داریم بحث می کنیم. توی این هیچ شکی نداشته باشید.

بعد از فکر روی راه حلی که می خواستم بگم متوجه شدم که راه مناسبی نبوده.

در هر حال الان بعد از چند هفته فکر روی این مساله به این نتیجه می رسم که شروط SP رو کاملا به عنوان بخشی از لایه منطق(BLL) به رسمیت بشناسم و همیشه در نگهداری برنامه و هنگامی که منطق برنامه تغییر می کند کلاس های BLL و شروط SP را به عنوان لایه منطق در آن لحاظ کنم و محیط نامناسب کد نویسی sql server رو هم تحمل کنم.

نظر شما چیه؟

FastCode
چهارشنبه 14 مهر 1389, 14:10 عصر
نظر شما چیه؟
اگر منفی نبود که اینجا نبودم.!


امروز یک سوال برای من ایجاد شد که فکر میکنم جاش توی همین تاپیکه:
"به نظر شما کد نویسی داخل دیتابیس جزئی از BLL ه؟"

hossein2007
چهارشنبه 14 مهر 1389, 14:21 عصر
امروز یک سوال برای من ایجاد شد که فکر میکنم جاش توی همین تاپیکه:
"به نظر شما کد نویسی داخل دیتابیس جزئی از BLL ه؟"

بله من به این نتیجه رسیدم.
واقعا نمی تونه غیر از این باشه .چون این کد ها منطق برنامه رو بررسی می کنند جزئی از لایه منطقی برنامه محسوب می شن.

M.YasPro
چهارشنبه 14 مهر 1389, 14:56 عصر
وقتی بحث معماری سه لایه می شه دقیقا در مورد پیاده سازی داریم بحث می کنیم. توی این هیچ شکی نداشته باشید.

نه اینو قبول ندارم . معماری یه سری قرارداد یا پروتکل هست و به هر پلت فرمی قابل اجراست و نمیشه بگی فقط توی این محیط یا اون محیط باید اجرا بشه ( توی sql یا دات نت) . هر جایی که اهداف و پروتکل ها رو به ثمر برسونه .


امروز یک سوال برای من ایجاد شد که فکر میکنم جاش توی همین تاپیکه:
"به نظر شما کد نویسی داخل دیتابیس جزئی از BLL ه؟"


همه کد ها نه
کدهایی مثل Insert و update و .. نه ولی کدهای شرطی triger ها و توابع و ... به نظر من جزو business هست .

hossein2007
چهارشنبه 14 مهر 1389, 15:14 عصر
نه اینو قبول ندارم . معماری یه سری قرارداد یا پروتکل هست و به هر پلت فرمی قابل اجراست و نمیشه بگی فقط توی این محیط یا اون محیط باید اجرا بشه ( توی sql یا دات نت) . هر جایی که اهداف و پروتکل ها رو به ثمر برسونه .

همه کد ها نه
کدهایی مثل Insert و update و .. نه ولی کدهای شرطی triger ها و توابع و ... به نظر من جزو business هست .


اشتباه برداشت کردید چون با هر دو نظرتون کاملا موافقم و نتیجه ای هم که گرفتم بر همین اساس بود.

من گفتم :"وقتی بحث معماری سه لایه می شه دقیقا در مورد پیاده سازی داریم بحث می کنیم" . پیاده سازی می تواند در sql یا دات نت یا هر جای دیگه انجام بشه.

در مورد اعمال چهارگانه sql هم طبیعی است که جزو BLL نیست.

به هر حال ممنونم از توجهتون.