استفاده از روال‌های مشترک ولی موردی در جداول

[mmbguide]

فرض کنیم پروژه‌ای شامل 100 جدول است و هرجدول حدود 1000 ردیف دارد و تمامی اطلاعاتی که در جدوال ثبت می‌شوند بدلیل ماهیت اون کسب و کار ممکن است به ازای هر ردیف توضیحاتی توسط کاربر در آن درج شود. این ستون می‌تواند یک نام مانند Comment و یا Remark داشته باشد.

سوال: آیا پیاده سازی این روش اشکال فنی دارد؟

اگر بجای ایجاد ستون Comment و یا Remark در تمامی جدوال که احتمالا 90 درصد ردیف‌ها نیازی به آن ندارند و در تمامی جداول null باقی خواهند ماند، یک جدول با نام Comment ایجاد کنم و ستون‌های آن بصورت زیر باشد:


Id, TableName, TableId, Comment

اگرچه که امکان ایجاد رابطه با تمام جدوال برای TableId وجود ندارد اما در زمان واکشی داده‌ها می‌توان در مدل خروجی (Output Model) یک List از Commentهای متناظر با جدول واکشی شده قرار داد تا برنامه سمت Client از آن استفاده کند.

[mazoolagh]

خب این همون روش خیلی قدیمی child/extension table هست
که وقتی مثل اینجا فیلدهایی دارین که بیشترش null هست (sparse data)
یا ساختار سلسله مراتبی دارن (hierarchical) استفاده میشه - این مورد شما فقط یک level داره البته
و این که عمومی تر از جدول فرزند عادی هست.

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

ولی Id, TableName, TableId, Comment گویا باید اینجوری باشه: Id, TableName, RecordId, Comment

====
الان 10 سالی هست که MS SQL مستقیما فیلد نوع sparse رو پشتیبانی میکنه،
که بد نیست اون رو هم یک نگاهی بندازین.

[mmbguide]

ممنون بابت راهنمایی و اصلاح نامگذاری. موردی که فراموش کردم در متن اولیه به آن اشاره کنم:

یکی از دلایل اصلی، امکان درج چندین توضیح برای یک ردیف است. این توضیحات به همراه اطلاعاتی مانند نام کاربری که توضیح را ثبت کرده به همراه زمان ثبت، برای کلاینت ارسال میشه و قراره که همان کاربر بتونه توضیح را اصلاح و یا حذف کنه. اگر بخوام به ازای هر جدول یک جدول Comment جداگانه بسازم (البته راه حل دیگه‌ای بلد نیستم) باید دقیقا 100 جدول دیگه به بانک اضافه کنم: TableA, TableAComments و TableB, TableBComments و... ولی پیاده سازی یک جدول سراسری برای جمع آوری Commentهای یک پروژه ضمن اینکه تعداد جداول و کلاس‌های تولید شده در پروژه را بشدت کاهش میده، مدیریت این ویژگی از نظر پیاده سازی هم برام ساده‌تر میشه و تغییرات تنها برای یک جدول و Handlerهای مربوط به آن اعمال خواهد شد.

البته یک پاسخ در لینک زیر دریافت کردم:
https://www.dntips.ir/questions/details/28#comment-72

[mazoolagh]

توضیح شما همون اول هم دقیق و واضح بود و مشخص میکرد که فقط یک جدول برای همه کامنتهای این 100 جدول قراره که ساخته بشه.

الان که مشخص شد:
1- بیش از یک کامنت برای یک رکورد میتونه وجود داشته باشه
2- برای هر کامنت اطلاعات اضافی دیگه ای هم هست: نام کاربری و زمان ثبت و ...
این روش مورد نظر شما بهتر نمود پیدا میکنه؛
البته میشه هم در همون 100 جدول، فیلد کامنت رو nvarchar(max) تعریف و این دیتا رو به فرمت json ذخیره کرد
و خود MSSQL هم میتونه مستقیما روی اون query بگیره،
هم اینکه همین جدول کامنتها رو بسازین به شکلی که خودتون اشاره کردین (البته timestamp و username و ... هم بهش اضافه میشه) و برای هر کامنت یک رکورد بسازین،
هم اینکه در جدول کامنتها فقط یک رکورد به ازای هر رکورد کامنت دار بسازین (همین فرمت json).

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

=======
ممنون از به اشتراک گذاشتن پاسخ آقای نصیری