بهترین روش واکشی رکورد از سه جدول مجزا

[mr.sirwan]

با سلام، دوستان بنده توی نرم افزار اتوماسیونم برا هر نوع نامه (داخلی، صادره و وارده) یک جدول مجزا طراحی کردم یعنی هر نوع نامه رو توی جدول مربوط به خودش ذخیره میکنم و به طبع اون برای جلوگیری از وجود حلقه، تمامی متعلقاتشون یعنی فایل ها و تصاویر پیوستیشون هم توی جدول های مجزا قرار میدم تا اینجای کار مشکلی نیست، تا به امروز توی برنامه م یه کمبوباکس برای انتخاب نوع نامه گذاشته بودم که طبق انتخاب کاربر فقط اون نوع نامه رو براش واکشی کنه و نمایش بده

اما حالا میخوام یه گزینه با عنوان «همه» توی همون کمبوباکس اضافه کنم که با انتخابش همه نوع نامه واکشی و توی دیتاگرید نمایش داده بشه اما مشکلی که هست همون مجزا بودن جدول ها و صفحه بندی دیتاگرید هستش، میخوام تنها با یک کوئری (البته اگر امکانپذیر باشه) این نامه هارو واکشی و صفحه بندی کنم

حالا توی این مورد گیر کردم و نمیدونم چطوری کوئری هارو بنویسم ممنون میشم راهنماییم کنین که اولا آیا این پیاده سازی بنده طرح خوبیه یا خیر و دوم اینکه نحوه واکشی نامه ها از هر سه جدول به چه شکلی باید باشه، از EF Code First استفاده میکنم
اگه خواستین ساختار جداول رو بصورت ساده شده هم قرار میدم

[Mahmoud Zaad]

سلام
چرا از یک جدول و اختصاص یک فیلد جدا کننده استفاده نکردید؟

[mr.sirwan]

به خاطر ساختار متفاوتی که هر نوع داره، مثلا نامه داخلی و صادره فیلد تایید کننده و امضا کننده، تایید کاربر دبیرخانه و خیلی فیلد دیگه دارن ولی نامه وارده همچین فیلدهایی رو نیاز نداره
یا نامه وارده فیلدی تحت عنوان شماره مندرج در نامه داره که نامه داخلی و صادره نیاز ندارن به همین خاطر جداشون کردم

[hrj1981]

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

[Mahmoud Zaad]

واقعیتش من در زمینه ef و همچنین نرم افزار دبیرخانه اطلاعات زیادی ندارم ولی برای طراحی دیتابیس به چند نکته توجه کنید اولا اگه تعداد فیلدهای غیر مشترک به نسبت بقیه فیلدها کم هستن می تونید جداول رو ادغام کنید. دوم اینکه اگه نرم افزار سفارشی نیست بهتره برای طراحی یک برآیندی از نیازهای همه مشتریها رو در نظر بگیرید مثلا ممکنه یک مجموعه ای نیاز داشته باشند برای نامه های وارده هم تاییدیه هایی داشته باشه که عملا بخشی از اون فیلدها هم استفاده میشه. سوم اینکه اگر میخواید دست کاربر کاملا باز باشه می تونید یک جدول پایه داشته باشید (با همین فیلدهای مشترکی که الان برای آیتم "همه" در کمبوباکس نیاز دارید) و در کنارش امکان اضافه کردن فیلدها رو به کاربر بدید مثلا یک مجموعه به 2 امضا برای تایید نیاز داره جای دیگه ممکنه 4 امضا نیاز داشته باشه. اینها در جداول دیگه ذخیره میشن.
جدول موقت هم یک راه هست و در ado و کوئری های Sql که می دونید از union استفاده میکنیم قاعدتا در ef هم میشه جداول رو ادغام کرد.
باز هم شما آشناتر هستید اینها صرفا پیشنهادهای کلی بود.

[mr.sirwan]

ممنون از نظراتتون، انگار مجبورم تبدیل به یه جدول کنم، ولی مسئله ای که هست اگر همه نوع نامه رو داخل یه جدول ذخیره کنیم اون جدول به مرور زمان اطلاعاتش زیاد و خیلی سنگین میشه و قطعا واکشی کوچکترین اطلاعات هم از این جدول زمانبر خواهد بود، درسته روش هایی مثل ایندکس گذاری هم در بهبود سرعت نقش دارن، ولی به نظرم زیاد جالب نیس موجودیت های متفاوت رو داخل یه جدول عمومی نگه داریم، مثل این میمونه یه آرایه ۱۰۰ عنصری تعریف کنیم که فقط در یک سوم موارد به تمامی ۱۰۰ عنصرش نیاز داریم و در باقیه موارد فقط ۶۰ تا عنصر یا کمترشو استفاده میکنم، خب اینکار حرفه ایی نیست

حالا یعنی این شرکت های بزرگ هم همه نامه هارو تو یه جدول ذخیره میکنن؟

[Mahmoud Zaad]

اگه در این حد متفاوت هستند که منطقی نیست. شما روش جایگزین برای union در ef رو تست کردید؟ اگر بله مشکل چی بوده؟
این برای جستجو در گوگل ef code first union multiple tables و این هم یک نمونه (https://stackoverflow.com/questions/14319763/query-the-unioned-results-of-multiple-tables-with-entity-framework)

[mr.sirwan]

ممنون از راهنماییتون جناب زاد، از Concat استفاده کردم و در حال حاضر دارم جواب میگیرم
تشکر از شما