باید عرض کنم که به سادگی می شه جدول هم طراحی کرد اما در خصوص تغییر دادن اشیای ثابت (دستورات DDL) این اتفاق بعیده (ذاتا نمی خواهیم این کار رو انجام بدیم)
جناب صادقیان فکر می کنم که برای کارهای معمولی و فیلدهایی که معمولا اکثر شرکت ها نیاز دارند انجام این روش مقرون به صرفه نباشه. چه از نظر کد نویسی (UI & SQL) و چه از نظر مشتری که از سیستم داره استفاده می کنه.
مثلا اگر برای کد ملی چنین کاری کنیم ، مشتری زمینه ذهنی بدی پیدا می کنه و ممکنه این فکر رو کنه که سیستم برای ذخیره اطلاعاتی به این پرکاربردی فیلد نداره ، پس ضعف داره و تازه داره پا می گیره.
اما اگر فیلدی بخواد که خودش هم می دونه معمولا سیستم ها اون رو ندارند ، وقتی بفهمه سیستم قابلیت تعریف کاری که می خواد رو داره، به شدت طرفدار و مبلغ سیستم می شه.
در کد نویسی هم معمولا کدهایی که برای مکش دیتا از این ساختار استفاده می شه زمان بیشتری می بره و طولانی تر هست. امکان برخی کارها رو هم مثل رابطه نداره و خودمون باید دستی این کار رو انجام بدیم.
اما گاهی هم ممکنه که فیلدی که می خواد به حدی پر بازدید هست که عملا ممکنه برای حجم وسیعی از داده که در گزارشات هم شرکت می کنند ، انجام این کار باعث کندی غیر قابل قبول از نظر مدیران شرکت میزبان بشه. (مثلا فیلدی مثل کاربر ثبت کننده کالا در ریز سند فروش یا همون اقلام فاکتور در حالتی که شرکت مورد نظر هر روز 500 فاکتور در هر شعبه ثبت می کنه - مثل شرکتهای پخش)
برای این کار هم افزودن فیلد استاتیک به نظرم منطقی تر هست.
نظر شما در این باره چیه؟
پاسخ با نقل قول