استفاده از تریگر یا نه؟ [بایگانی]

View Full Version : استفاده از تریگر یا نه؟

ashkandehnavi

دوشنبه 28 اردیبهشت 1394, 21:57 عصر

SabaSabouhi

سه شنبه 29 اردیبهشت 1394, 09:45 صبح

سلام خدمت همه

ممنون میشم راهنمایی کنید

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

1) در خود برنامه پس از تایید مدیر یک تغییر دیگر در جدول دوم انجام بشه
2) در برنامه پس از تایید مدیر یک sp صدا بزنم
3) در تریگر برای تغییر جدول در خودش یک sp صدا بزنم
4) از خود تریگر استفاده کنم(سربار مشکل ساز نمیشود)
5) راه حل شما...

ممنون میشم راهنمایی کنید

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

1. Trigger کند هست، اما نه اون‌قدر که شما رو نگران کنه.
یه چیز خیلی مهم اینه که ما اطلاعات و معلوماتمون مربوط به مطالبی هست که از مراجع غربی مطالعه می‌کنیم. و معیارهای اون‌ها با ما اصلاً قابل
قیاس نیست. یه زمانی تو یه کتاب خوندم که شرکت‌ها رو به سه دسته تقسیم کرده بود و کوچک‌ترین واحدش شرکت‌هایی بود که بین 2 تا 50 هزار
تا استفاده کننده Online داشتن. یعنی غالب شرکت‌های ما حتا در رده‌ی کوچولوهای اون‌ها هم قرار نمی‌گیرن.

2. استفاده از SP درون Trigger اصلاً کار جالبی به نظر نمی‌رسه.

3. بعضی‌ها ترجیح می‌دن که لایه‌ی BL کاملاً درون Source Code پیاده سازی بشه. نوشتن Trigger بخشی از این لایه رو به Sql Server منتقل می‌کنه
که این کار از نظر کارایی خوبه، اما از نظر یکپارچگی خوب نیست. یعنی سرعت اجرا بالا می‌ره ( چون تو همون Sql Server انجام می‌شه ) اما BL شما
دیگه یکپارچه نیست. بخشی درون کد، و بخشی درون SQL.
اون‌هایی که طرفدار SP هستن، بخشی از BL رو در سطح SQL Server پیاده سازی می‌کنن، و در این حالت وجود Trigger مشکلی از این جهت براشون
ایجاد نمی‌کنه.

4. اگه تو نوشتن T-Sql تبحر داشته باشی، Trigger خیلی چیزی معرکه‌ای هست. البته یه محدودیت‌هایی داره، اما واقعاً به خوبی از عهده‌ی کارها
بر میاد. واقعاً نگران سرعت و سربار نباش. اگه تصمیم که کار با Trigger گرفتی، با خیال راحت این کار رو انجام بده.
من یک مرتبه این کار رو جدی امتحان کردم و از نتیجه خیلی راضی بودم. فروش که یه فاکتور می‌زد، توسط Trigger سند حسابداری صادر می‌کردم،
حواله‌ی انبار صادر می‌کردم و موجودی رو به روز می‌کردم.
اما الان ترجیح می‌دم همه چیزی به صورت یکپارچه توی Source باشه.

صبا صبوحی

ashkandehnavi

سه شنبه 29 اردیبهشت 1394, 10:03 صبح

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

1. Trigger کند هست، اما نه اون‌قدر که شما رو نگران کنه.
یه چیز خیلی مهم اینه که ما اطلاعات و معلوماتمون مربوط به مطالبی هست که از مراجع غربی مطالعه می‌کنیم. و معیارهای اون‌ها با ما اصلاً قابل
قیاس نیست. یه زمانی تو یه کتاب خوندم که شرکت‌ها رو به سه دسته تقسیم کرده بود و کوچک‌ترین واحدش شرکت‌هایی بود که بین 2 تا 50 هزار
تا استفاده کننده Online داشتن. یعنی غالب شرکت‌های ما حتا در رده‌ی کوچولوهای اون‌ها هم قرار نمی‌گیرن.

2. استفاده از SP درون Trigger اصلاً کار جالبی به نظر نمی‌رسه.

3. بعضی‌ها ترجیح می‌دن که لایه‌ی BL کاملاً درون Source Code پیاده سازی بشه. نوشتن Trigger بخشی از این لایه رو به Sql Server منتقل می‌کنه
که این کار از نظر کارایی خوبه، اما از نظر یکپارچگی خوب نیست. یعنی سرعت اجرا بالا می‌ره ( چون تو همون Sql Server انجام می‌شه ) اما BL شما
دیگه یکپارچه نیست. بخشی درون کد، و بخشی درون SQL.
اون‌هایی که طرفدار SP هستن، بخشی از BL رو در سطح SQL Server پیاده سازی می‌کنن، و در این حالت وجود Trigger مشکلی از این جهت براشون
ایجاد نمی‌کنه.

4. اگه تو نوشتن T-Sql تبحر داشته باشی، Trigger خیلی چیزی معرکه‌ای هست. البته یه محدودیت‌هایی داره، اما واقعاً به خوبی از عهده‌ی کارها
بر میاد. واقعاً نگران سرعت و سربار نباش. اگه تصمیم که کار با Trigger گرفتی، با خیال راحت این کار رو انجام بده.
من یک مرتبه این کار رو جدی امتحان کردم و از نتیجه خیلی راضی بودم. فروش که یه فاکتور می‌زد، توسط Trigger سند حسابداری صادر می‌کردم،
حواله‌ی انبار صادر می‌کردم و موجودی رو به روز می‌کردم.
اما الان ترجیح می‌دم همه چیزی به صورت یکپارچه توی Source باشه.

صبا صبوحی

ممنون
من یک قسمت رو متوجه نشدم، شما فرمودید استفاده در trigger یکپارچه نیست ولی سرعت رو میبره بالا(شماره 3)
ولی توی شماره 4 ترجیح دادید از trigger استفاده نکنید و درون برنامه بنویسید

درست متوجه شدم؟

میتونم بپرسم چرا از trigger استفاده نکردین و ترجیح دادین در برنامه به صورت یکپارچه استفاده کنید؟

SabaSabouhi

سه شنبه 29 اردیبهشت 1394, 13:32 عصر

ممنون
من یک قسمت رو متوجه نشدم، شما فرمودید استفاده در trigger یکپارچه نیست ولی سرعت رو میبره بالا(شماره 3)
ولی توی شماره 4 ترجیح دادید از trigger استفاده نکنید و درون برنامه بنویسید

درست متوجه شدم؟

میتونم بپرسم چرا از trigger استفاده نکردین و ترجیح دادین در برنامه به صورت یکپارچه استفاده کنید؟

سلام
تو برنامه‌نویسی چند لایه، یکی از لایه‌ها مربوط به منطق‌ها و شرایط تجاری هست ( Business and Logic )
تو اون لایه هست که مشخص می‌کنیم هر فرایندی به چه شکلی انجام می‌شه، چه جدول‌هایی درگیر هستن
و . . .
حالا اگه بعضی از این کارها داخل Trigger انجام بشه، به‌ویژه در زمان پشتیبانی ( رفع عیب یا گسترش نرم‌افزار )
یک‌پارچه نبودن منطق‌ها ( یعضی‌ها داخل کد و بعضی داخل Trigger ) کار رو کمی سخت می‌کنه.
دلیل این که در حال حاضر ترجیح می‌دم از Trigger استفاده نکنم فقط همینه.
البته توی پروژه‌ی قبلی نیاز به تولید Log خیلی محکم رو اغلب جدول‌ها داشتیم. اونجا از Trigger استفاده کردم
چون هیچ ربطی به BL نداشت و جداگانه انجام می‌شد.

و اما در مورد سرعت. هر چی شما وظایف رو بیشتر تقسیم کنی، سرعت بالاتری خواهی داشت. به‌ویژه اگه هر وظیفه‌ای در محل مناسب انجام بشه.
اگه وظیفه‌ی ایجاد Transaction، و به روز رسانی داده‌ها داده‌ها رو روی Sql Server انجام بدی، دو تا امتیاز داری، یکی این که کارها رو بین دو تا سرور
تقسیم کردی، و دوم این که از یک ارسال و دریافت اطلاعات تحت شبکه پیش‌گیری کردی.

صبا صبوحی

ashkandehnavi

سه شنبه 29 اردیبهشت 1394, 13:39 عصر

سلام
تو برنامه‌نویسی چند لایه، یکی از لایه‌ها مربوط به منطق‌ها و شرایط تجاری هست ( Business and Logic )
تو اون لایه هست که مشخص می‌کنیم هر فرایندی به چه شکلی انجام می‌شه، چه جدول‌هایی درگیر هستن
و . . .
حالا اگه بعضی از این کارها داخل Trigger انجام بشه، به‌ویژه در زمان پشتیبانی ( رفع عیب یا گسترش نرم‌افزار )
یک‌پارچه نبودن منطق‌ها ( یعضی‌ها داخل کد و بعضی داخل Trigger ) کار رو کمی سخت می‌کنه.
دلیل این که در حال حاضر ترجیح می‌دم از Trigger استفاده نکنم فقط همینه.
البته توی پروژه‌ی قبلی نیاز به تولید Log خیلی محکم رو اغلب جدول‌ها داشتیم. اونجا از Trigger استفاده کردم
چون هیچ ربطی به BL نداشت و جداگانه انجام می‌شد.

و اما در مورد سرعت. هر چی شما وظایف رو بیشتر تقسیم کنی، سرعت بالاتری خواهی داشت. به‌ویژه اگه هر وظیفه‌ای در محل مناسب انجام بشه.
اگه وظیفه‌ی ایجاد Transaction، و به روز رسانی داده‌ها داده‌ها رو روی Sql Server انجام بدی، دو تا امتیاز داری، یکی این که کارها رو بین دو تا سرور
تقسیم کردی، و دوم این که از یک ارسال و دریافت اطلاعات تحت شبکه پیش‌گیری کردی.

صبا صبوحی

خيلى ممنون از راهنمايى خوبتون