‫۱ ماه قبل، جمعه ۱۹ مرداد ۱۴۰۳، ساعت ۱۰:۰۴

یعنی می فرمائید اینکه در روش اول، هر روز تعداد زیادی رکورد به دیتابیس افزوده میشه ولی در روش دوم، فقط تعداد ثابتی رکورد (به ازای هر کالا یک رکورد) وجود داره که هر روز، یک فیلد آن (مثلا در قالب یک رشته) بروزرسانی میشه، بازهم روش دوم کم حجم تر از روش اول می شه؟ مثلا برای 1000 کالا، در روش اول، پس از یکسال، 10 میلیون رکورد باید ثبت بشه ولی در روش دوم، فقط 1000 رکورد در سال وجود داره که البته هر روز، فایل XML (یا در قالب رشته) مربوط به این رکوردها با زمان حجیم تر میشه.

در واقع مشکل اصلی من اینه که نرم افزار، هر روز، باید تعداد زیادی داده رو در مدت زمان کوتاهی دریافت و ثبت کنه. برای کاهش مدت زمان لازم برای این کار، من از BullkInsert و حتی افزونه هایی مانند Z.EntityFramework.Extensions استفاده می کنم. ولی بازهم زمان زیادی برای دریافت و ثبت داده ها لازم هستش. به همین دلیل می خوام بدونم آیا در این سناریوی خاص، میشه طراحی رو به شکلی تغییر داد که بر خلاف روش اول، نیازی به ثبت این تعداد رکورد در هر روز نباشه و یا اینکه ثبت این داده ها اجتناب ناپذیره؟

همانگونه که شما فرمودید روش دوم به وضوح غیر اصولی است ولی آیا جنابعالی پیشنهادی برای اجرای روش اول به صورت اصولی و بهینه دارید؟

‫۱ ماه قبل، جمعه ۱۹ مرداد ۱۴۰۳، ساعت ۰۸:۴۵

یقینا سرعت کار با بانک‌های اطلاعاتی رابطه‌ای و امکانات توکار آن‌ها همیشه بیشتر از کار با XML و هر حالت مشابه دیگری در آن‌هاست و بنابراین ... بله. حالت دوم بهینه‌تر نیست، سریعتر نیست و همچنین کم‌حجم‌تر هم نیست. اساسا بانک‌های اطلاعاتی رابطه‌ای زمانی طراحی شدند که یک هارد دیسک 4 مگابایتی، چندهزار دلار قیمت داشت. به همین جهت در زمینه ذخیره سازی اطلاعات، بسیار بهینه و کم‌حجم عمل می‌کنند؛ با حداقل تکرار و سربار و با سرعت بالا. استفاده از XML و JSON امثال این‌ها زمانی باب شدند که قیمت هارد دیسک‌های حجیم کاهش یافته بود و همچنین بیشتر سرعت read مطرح بود و نه سرعت write. اطلاعات بیشتر

‫۱ ماه قبل، چهارشنبه ۱۷ مرداد ۱۴۰۳، ساعت ۱۰:۴۴

آنچه که در خصوص کتابخانه های مخصوص اعتبارسنجی فرمودید آیا با ارجاع به بانک اطلاعاتی هم پیاده سازی میشوند؟ چون مفهوم اعتبارسنجی را در سطح کلاس های برنامه بلد هستم. برای سناریوی عنوان شده در پست اولیه، یک لایه اعتبارسنجی توسط FluentValidation پیاده سازی شده و null بودن کلیدها بررسی می شوند ولی وجود چنین شناسه ای به عنوان کلید اصلی در بانک اطلاعاتی چطور باید بررسی شود؟ آیا با همان FluentValidation امکانپذیر است یا اینکه در همان لایه Application باید تمام کلیدها بررسی و پیغام مناسب به کاربر برگردانده شود؟

‫۱ ماه قبل، چهارشنبه ۱۷ مرداد ۱۴۰۳، ساعت ۰۷:۳۸

مزیت وجود این همه فریم‌ورک‌های اعتبارسنجی، عدم واگذاری یکسری از کارها به خود بانک اطلاعاتی است؛ وگرنه، بله. اتفاقا خود بانک اطلاعاتی به خوبی می‌تواند (یکسری از قیود «ابتدایی» تعریف شده‌ی در آن‌را و نه ... بررسی‌های پیچیده‌ی ممکن توسط فریم‌ورک‌های اعتبارسنجی را) اعتبارسنجی کند و درخواست‌های insert/update/delete را راسا خاتمه داده و برگشت بزند. البته ... در نهایت با پیام‌هایی غیرکاربرپسند و به همراه استثناءهایی که هزینه‌ها و سربارهایی را به سیستم تحمیل می‌کنند. به همین جهت ترجیح داده می‌شود که برای بررسی‌های پیچیده‌تر و همچنین نمایش پیام‌های کاربرپسندتری، پیش از ارسال اطلاعات به بانک اطلاعاتی، اعتبارسنجی‌های پیچیده در سمت برنامه انجام شوند.

‫۱ ماه قبل، چهارشنبه ۱۷ مرداد ۱۴۰۳، ساعت ۰۷:۰۴
  • انتقال پارامترهای آبشاری، نیاز به تعریف cascading value در سطحی بالاتر دارند؛ یک مثال:
<CascadingValue Value=this>
  • بر اساس طراحی ذاتی Blazor، راه‌حلی برای نال نشدن HttpContext در تمام حالات رندر وجود ندارد. در SSR در دسترس است و در مابقی خیر (^ و ^).