نمایش نتایج 1 تا 11 از 11

نام تاپیک: خوب بد زشت در پایگاه داده

  1. #1

    خوب بد زشت در پایگاه داده

    سام دوستان
    می خواستم نظرتون رو در مورد سرعت اجرای دستورات در 3 حالت زیر بدونم و اینکه کدام یک سرعت بلایی در اجرا دارند.
    1- اجرای دستورات sql به صورت کد نویسی
    2- نوشتن پروسیجر در دیتاست وصدا زدن اون
    3- نوشتن پروسیجر در sql server و صدا زدن اون

  2. #2

    نقل قول: خوب بد زشت در پایگاه داده

    با سلام

    به نظرم اگر سرور قوي باشد (و البته بستگي به تعداد كاربران سيستم) روش سوم سريعتر از بقيه است

    موفق باشيد

  3. #3
    کاربر تازه وارد آواتار Ir.WebDeveloper
    تاریخ عضویت
    خرداد 1389
    محل زندگی
    یک شهر صنعتی
    پست
    50

    نقل قول: خوب بد زشت در پایگاه داده

    معمولا روش سوم بهترینه ،روش دوم هم چون از فایل های xsd استفاده میشه به نظرم خیلی پرسرعت نیست نسبت به SP.
    ضمن اینکه SP جلوی Injection رو هم میگیره.

    موفق باشید.

  4. #4
    کاربر دائمی آواتار mohammad_2039
    تاریخ عضویت
    فروردین 1387
    محل زندگی
    تهران
    پست
    360

    نقل قول: خوب بد زشت در پایگاه داده

    قطعا روش سوم سریعتره، اما سر کلاسهای UML به شدت از این کار نهی میکنند چون باید کدها در سطح برنامه نوشته بشن نه تو sqlserver، و اگه کسی بخواد کد شما رو بخونه باید هه چیز تو برنامه در دسترس باشه.

  5. #5
    کاربر دائمی آواتار behnam25214
    تاریخ عضویت
    اردیبهشت 1388
    محل زندگی
    @-<-<
    پست
    338

    نقل قول: خوب بد زشت در پایگاه داده

    منم روش 3 رو ترجیح میدم.

  6. #6
    کاربر دائمی آواتار FastCode
    تاریخ عضویت
    تیر 1388
    محل زندگی
    /dev/null
    پست
    3,486

    نقل قول: خوب بد زشت در پایگاه داده

    ضمن اینکه SP جلوی Injection رو هم میگیره.
    عین این جملست:
    آمپول جلوی بیماری رو میگیره.
    خوب اگر هوا تزریق کنیم چی؟

    به نظر من روش ۲ اصلاً به درد نمیخوره چون با AutoGenerate کردن خیلی مشکل به هم میزنه.
    روش اول هم یه جورایی مشکل late-binding داره و scalable نیست.
    قدرت کافی هم نداره و همیشه قدرت بیشتر توش مساوی سرعت کمتره.
    و دیگش هم اینه که بهترین Editor برای این کار, از بدترین Editor برای اون ۲ تا روش دیگه بدتره و اعصاب خورد کنه.(رو اعصابت راه میره)

    مشکل روش دوم هم اینه که مشکل concurrency داره.که قابل حله.
    ماههای اول که یه مشتری باهاش کار مکنه اصلاُ صداش در نمیاد ولی باید آماده باشید.
    یه سوال توی stackoverflow.com بود که گفته بود بدترین design-pattern های پایگاه داده از نظر شما چیه؟
    اگر اون سوال رو بخونی خیلی کمکت میکنه.الان لینکش رو ندارم.اگر پیدا کنم به همین سوال اضافه میکنم.

  7. #7
    کاربر دائمی آواتار FastCode
    تاریخ عضویت
    تیر 1388
    محل زندگی
    /dev/null
    پست
    3,486

    نقل قول: خوب بد زشت در پایگاه داده

    ببخشید من فراموش کردخم سرعت رو مقایسه کنم.
    تو حالت معمولی بدون ترافیک بالا بین برنامه و sql
    رتبه بندی اینطوریه:
    3- نوشتن پروسیجر در sql server و صدا زدن اون
    1- اجرای دستورات sql به صورت کد نویسی
    2- نوشتن پروسیجر در دیتاست وصدا زدن اون

  8. #8

    نقل قول: خوب بد زشت در پایگاه داده

    نقل قول نوشته شده توسط FastCode مشاهده تاپیک
    ببخشید من فراموش کردخم سرعت رو مقایسه کنم.
    تو حالت معمولی بدون ترافیک بالا بین برنامه و sql
    رتبه بندی اینطوریه:
    3- نوشتن پروسیجر در sql server و صدا زدن اون
    1- اجرای دستورات sql به صورت کد نویسی
    2- نوشتن پروسیجر در دیتاست وصدا زدن اون
    و اگه ترافيك بالا بود چطور مي شه

  9. #9
    کاربر دائمی آواتار FastCode
    تاریخ عضویت
    تیر 1388
    محل زندگی
    /dev/null
    پست
    3,486

    نقل قول: خوب بد زشت در پایگاه داده

    نقل قول نوشته شده توسط com_engineer_ab مشاهده تاپیک
    و اگه ترافيك بالا بود چطور مي شه
    میتونید جای اولی و سومی رو عوض کنید.کار آسونی نیست.
    3- نوشتن پروسیجر در sql server و صدا زدن اون
    1- اجرای دستورات sql به صورت کد نویسی
    ==>>

    1- اجرای دستورات sql به صورت کد نویسی
    3- نوشتن پروسیجر در sql server و صدا زدن اون

  10. #10

    نقل قول: خوب بد زشت در پایگاه داده

    سلام من دارم یه وب سایت برای یک فروشگاه طراحی میکنم به نظرتون کدوم روش رو استفاده کنم

  11. #11
    کاربر دائمی آواتار mahdi87_gh
    تاریخ عضویت
    فروردین 1388
    محل زندگی
    قزوین
    پست
    448

    نقل قول: خوب بد زشت در پایگاه داده

    دوستان من در یک کتابی خوندم که Linq برای اجرای دستورات دارای شرط ،ابتدا کل رکوردها رو از بانک لود میکنه و بعدش فیلترینگ رو اعمال میکنه اما در عوض مزیت هایی رو هم بدنبال داره.
    حالا که اینجا بحث سرعت برنامه رو دوستان دنبال میکنند میخواستم نظر دوستان رو بدونم که آیا این مزیت های Linq ارزش تاخیری رو که در پی داره، دارند؟

قوانین ایجاد تاپیک در تالار

  • شما نمی توانید تاپیک جدید ایجاد کنید
  • شما نمی توانید به تاپیک ها پاسخ دهید
  • شما نمی توانید ضمیمه ارسال کنید
  • شما نمی توانید پاسخ هایتان را ویرایش کنید
  •