تعداد زیاد روابط یک به چند

[پرواز]

یه جدول به اسم Employees دارم که اطلاعات کارمندان رو ذخیره می کنه.
هرجا می خوام ثبت کنم که اپراتور ثبت یه رکورد کی بوده اون جدولو با جدول Employees یک به چند می کنم.

یه جدول دارم که توش 9 بار نام اپراتو ذخیره میشه. (یعنی ممکنه تو 9 مرحله فیلدها تکمیل میشن و هر مرحله رو یه اپراتور می تونه انجام بده)

به نظرتون این جدول رو با جدول Employees یک به چند کنم؟ یا همینجوری ID جدول Employees رو بندازم اونجا؟

[SYNDROME]

اگر می توانید کمی واضحتر توضیح بدید تا ما هم دقیقتر جواب بدیم.
ولی با توجه به توضیحات بالا اگر یک به چند در نظر بگیرید بهتر است .
موفق باشید

[پرواز]

ببینید
جدول Employees یه فیلد داره به نام EmployeeID. تو بعضی جدولهام لازم دارم که بگم کدوم Employee این رکورد رو ذخیره کرده. میام اون رو با جدول Employees یک یه چند می کنم. یعنی میام EmployeeID رو توش ذخیره می کنم. حالا هر وقت بخوام اسم Employeeای که رکورد ذخیره کرده رو در بیارم میام و با یک INNER JOIN اسم اونا رو پیدا می کنم.

تا اینجا که فکر نکنم مشکلی باشه؟

خوب حالا من یه جدول دارم که ممکنه هر کدوم از فیلدهاشو به Employee پر کنه. و حداکثر تعداد Employeeهایی که تو یک رکورد این جدول ذخیره میشن 9تاست.

سوال من اینه: اگه بیام 9تا رابطه یک به چند بین این جدول و جدول Employees برقرار کنم performance برنامه نمیاد پایین؟

[Alireza Orumand]

ببینید شما میگید هر رکورد رو یک Employee پر میکنه و اینکه تو یه جدول فیلد هایی باشه که هر فیلد اون رو یک شخص خاص پر میکنه نشون میده که این فیلدها تو حوضه های مختلفی هستن که به هم ارتباطی ندارن. بنده اگر تو این شرایط بودم برای هر کدوم از فیلدهایی که شخصی خاص پر میکنه یه جدول درست میکردم. مثلا اگر جدول شما الان 10 تا فیلد داره که 4 تای اون رو یه نفر و 4 تای دیگه رو یه نفر دیگه و 2 تای باقی مونده رو نفر سومی پر میکنه خوب 3 تا جدول درست کنید که اولی شامل 4 فیلد اول، دومی 4 فیلد دوم و سومی هم 2 فیلد باقی مونده باشه که البته تو هر کدوم از این جداول EmployeeID هم شرکت میکنه.
فکر میکنم اینطوری بهتر از این باشه که شما یه جدول داشته باشی که توی اون 9 تا EmployeeID ذخیره کنید.

[پرواز]

ببینید شما میگید هر رکورد رو یک Employee پر میکنه و اینکه تو یه جدول فیلد هایی باشه که هر فیلد اون رو یک شخص خاص پر میکنه نشون میده که این فیلدها تو حوضه های مختلفی هستن که به هم ارتباطی ندارن. بنده اگر تو این شرایط بودم برای هر کدوم از فیلدهایی که شخصی خاص پر میکنه یه جدول درست میکردم. مثلا اگر جدول شما الان 10 تا فیلد داره که 4 تای اون رو یه نفر و 4 تای دیگه رو یه نفر دیگه و 2 تای باقی مونده رو نفر سومی پر میکنه خوب 3 تا جدول درست کنید که اولی شامل 4 فیلد اول، دومی 4 فیلد دوم و سومی هم 2 فیلد باقی مونده باشه که البته تو هر کدوم از این جداول EmployeeID هم شرکت میکنه.
فکر میکنم اینطوری بهتر از این باشه که شما یه جدول داشته باشی که توی اون 9 تا EmployeeID ذخیره کنید.
نه دوست عزیز. به این سادگی هم نیست. روابط یه کم پیچیده تره.
من برای سیکل مراحل اداری یه شرکت این کارو کردم. بذارید بیشتر توضیح بدم:

یه جدول دیگه داریم به اسم Customers و یه جدول هم به اسم Cycle (همون که 9تا EmployeeID ذخیره میکنه) که این دوتا جدول یک به چندن. یعنی هر مشتری می تونه چندبار بیفته تو سیکل مراحل اداری.

طی مراحل اداری شامل تاریخ رسیدن به اون مرحله و Employee ثبت اون مرحله هست. فعلاً 9تا مرحله داریم. پس برای هر مرحله باید دوتا فیلد تو جدول Cycle داشته باشیم. یکی تاریخ و دیگری EmployeeID.

اگه خوب توضیح داده باشم متوجه شدید که جدول Cycle نمی تونه به چند جدول تقسیم بشه. باید هر رکوردی بتونه اطلاعات یک سیکل کامل رو تو خودش ذخیره کنه.

[Alireza Orumand]

اینطوری که شما میفرمایید که یک برای هر بار مراجعه یه تاریخ و Employee ذخیره میکنید یعنی اینکه تو هر رکورد 18 تا فیلد دارید که 9 تا Employee و 9 تای دیگه تاریخ هست.
اگر درست متوجه شده باشم من برای این سناریو ترجیح میدم به هر کدوم ازCustomers ها یه CustomersID اختصاص بدم و جدول رو به این شکل درست کنم که یه فیلد برای CustomersID و فیلد دیگه ای برای EmployeeID و یه فیلد هم برای تاریخ باشه.
اگر هم نیاز بود که اطلاعات دیگه ای هم نگه داری بشه خوب یه فیلد دیگه اضافه میکنم و سه تا فیلد دیگه رو در صورت نیاز به صورت مشترک Primary key میگیرم.
والا اینقدی که شما توضیح دادید از دید بنده میشه به این روش کار کرد مگر اینکه نکته ی خاص دیگه ای وجود داشته باشه.

[پرواز]

اینطوری که شما میفرمایید که یک برای هر بار مراجعه یه تاریخ و Employee ذخیره میکنید یعنی اینکه تو هر رکورد 18 تا فیلد دارید که 9 تا Employee و 9 تای دیگه تاریخ هست.
اگر درست متوجه شده باشم من برای این سناریو ترجیح میدم به هر کدوم ازCustomers ها یه CustomersID اختصاص بدم
تا اینجا کاملاً درسته و منم همین کارو کردم. هم 18 رکورد درسته و هم یه CustomerID تو جدول Cylce وجود داره و کلید خارجیه که باعث میشه این جدول با جدول Customers یک به چند بشه. این چه معنی میده؟ یعنی اینکه یه Customer می تونه چندتا رکورد تو جدول Cycle داشته باشه و کاملاً درسته.

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

[SYNDROME]

خوب حالا من یه جدول دارم که ممکنه هر کدوم از فیلدهاشو به Employee پر کنه. و حداکثر تعداد Employeeهایی که تو یک رکورد این جدول ذخیره میشن 9تاست.

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

[پرواز]

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

ولی من هنوز جوابمو نگرفتم!

[Alireza Orumand]

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

خوب بنده همین رو خدمت شما عرض کردم که جدول به جای اینکه 18 تا فیلد داشته باشه 4 تا فیلد داشته باشه که اینطوری که هر مشتری در هر تاریخ خاص وارد یک مرحله ی خاص میشود و با یک کارمند خاص مرحله ای خاص رو انجام میده.
اینطوری شما جای 9 اینکه 9 تا رابطه ی یک به چند داشته باشید فقط یه رابطه یک به چند بین اون جدول و جدول Employees دارید.
از افزونگی هم جلوگیری میشه.ترتیب کار هم حفظ میشه یعنی تنها خریداری میتونه وارد مرحله ی 4 بشه که از مرحله ی 3 رد شده باشه که شماره هر مرحله هم تو فیلد چهارم این جدول نگه داری میشه.
با سناریویی که شما ارائه دادید فکر کنم بهترین کاری که بشه کرد همین باشه.
مگر اینکه سناریویی که مد نظر شما هست با اینی که من فهمیدم متفاوت باشه.:گیج:
که اگر هست و من دارم بیراهه میرم خواهش میکنم یه بار دیگه دقیق بفرمایید اصل سوال چی هست و اینکه اشکالی که در استفاده از 4 فیلد وجود داره چی هست؟
موفق باشید.

[پرواز]

سلام آقا علیرضا،
سناریو رو تقریباً درست فهمیدی.
ولی مشکلی که باعث شد من این کارو نکنم اینه که نمی شه برای یک کاربر چندبار مراحل رو طی کرد. چون اینطور که شما میگی یه کلید ترکیبی داریم که شامل CustomerID و EmployeeID و شماره مرحله است.
یا اینکه میشه و من منظور شما رو نمی فهمم!

[Alireza Orumand]

سلام
خوب اگر کلید این جدول رو به جای ترکیبی از CustomerID و EmployeeID و شماره مرحله باشه این کلید رو شما ترکیبی از CustomerID و شماره مرحله بگیرید اینطوری هر خریدار فقط و فقط یک بار میتونه وارد یه مرحله بشه و به شرط اینکه مرحله ی قبل رو پشت سر گذاشته باشه.
اگر هم منظورتون این هست که شما میخواهید یک کاربر بتونه یک مرحله رو چند بار پشت سر بگذاره هم باز هم شدنی هست که شما به کلید های خودتون به جز دو مورد قبلی تاریخ رو هم اضافه میکنید. که با این کار اگر کاربر بخواد چند بار یک مرحله رو بگذرونه چون هر مرحله تو روزهای متفاوتی هست باز هم امکانش به وجود میاد.
اگر من درست متوجه شده باشم که شما میفرمایید شدم، شما جدول رو به این شکل بسازید و باتوجه به نیازی که دارید میتونید کلید جدول رو درست کنید. یعنی میشه یه کلیدی ساخت که هر کاربر فقط یک بار وارد یک مرحله بشه و یا هر کاربر هرچند بار که خواست بتونه وارد یک مرحله بشه، یعنی این مشکلی که شما فرمودید در هر صورت با کمی تغییر تو ساختار کلید قابل حل هست.
موفق باشید.

[پرواز]

همه حرفای شما درسته. ولی یه مشکل داریم و اونم اینه که پیوستگی مراحل از بین میره. مثلاً شما می خوای کاربر رو از یه مرحله رد نکنی و مستقیم بری 2مرحله بعد. اینجا دیگه نمیشه تشخیص داد که یک دوره از طی مراحلش کدومه.

من می خوام سیکل رو بشه تشخیص داد. اگه فیلدها از هم جدا بشن اصلا شیرازه کار از دست میره. یا مثلا می خوام همه مراحل رو تو یه رکورد تو Grid نشون بده و سیکل بعدی رو تو یه رکورد دیگه. که تو این رکورد کلی محاسبات دیگه هم هست. مثلا تعداد روزایی که تو اون مرحله بوده و ...

خلاصه اینکه رو این سیکل خیلی مانور میدم و کلی باهاش کار دارم. JOINهای زیاد ازش کشیدم بیرون و گزارشهای متنوعی ازش می خوام. فکر نکنم روش شما مقرون به صرفه باشه. البته خیلی زحمت کشیدید نظر دادید و تشکر می کنم ازتون.

نمی دونم دلایل قانع کننده بود یا نه.