طراحی سیستم اتوماسیون ساده

[IMANAZADI]

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

میخوام این سیستم رو در php پیاده سازی کنم

به طوری که هر یوزر بتونه به چندین یوزر نامه ارسال کنه ،امکان ارسال رونوشت برای دیگر یوزرها باشه ، و امکان پیوست داشته باشه(شاید چندین پیوست)

بعد میخوام در پیاده سازی اون بتونم گیرندگان نامه بتونن نسبت به اون جواب بدن و در پایین نامه اصلی به ترتیب جواب ها نمایش داده بشه

من یک موجودیت در نظر گرفتم برای یوزرها (ای دی ، کد یوزر، نام ، نام خانوادگی ، یوزرنیم ، پسورد، واحد کاری ، ایمیل ، و....) کد یوزر کلید هست
یک موجودیت در نظر گرفتم برای نامه ها (ای دی ، شماره نامه ، موضوع ، تاریخ ، پیوست ها ، خوانده شده ) شماره نامه کلید هست
الان برای ارتباط بین این موجودیت ها و طراحی جدول واسط موندم ؟؟

[IMANAZADI]

دوستان عزیز همچنان منتظر راهنمایی های شما هستم

[IMANAZADI]

دوستان آیا این دیاگرام صحیح است
فیلد type در جدول tbl_type شامل فرستنده ، گیرنده ، رونوشت می باشد
مابقی هم که مشخص می باشد

[SabaSabouhi]

دوستان آیا این دیاگرام صحیح است
فیلد type در جدول tbl_type شامل فرستنده ، گیرنده ، رونوشت می باشد
مابقی هم که مشخص می باشد

سلام
دوست عزیز، موضوع اتوماسیون به این سادگی هم نیست، اما با فرض بر این که به همین سادگی
باشه من چند مورد اشکال تو طراحی‌ای که کردی برات لیست می‌کنم:

[نام‌گذاری]
نام‌گذاری ( که متاسفانه همکاران ایرانی ما خیلی کم بهش اهمیت می‌دن ) خیلی اهمیت داره، به‌ویژه
هنگامی که قراره تو یه تیم کار کنی یا کسی در آینده قرار هست این کار رو ادامه بده.
1. «وحدت رویه» اگه جدول کاربران رو tbl_users نام گذاری می‌کنی، جدول انواع رو هم tbl_types نام‌گذاری کن
یا هر دو مفرد باشه یا هر دو جمع ( البته جمع صحیح‌تر هست )
2. به هیچ عنوان از پینگلیش استفاده نکن. vaset اینجا خیلی بد هست. سعی کن وقتی یک جدول واسط بین
دو جدول هست از نام هر دو جدول استفاده کنی. مثلاً tbl_users_letters
3. *** خیلی مهم *** کلید اصلی فقط باید کلید اصلی باشه، پس تو جدول نامه‌ها حتماً یک Id برای کلید اصلی
اضافه کن. اگه شماره‌ی نامه قراره یکتا باشه، یک اندیس یکتا ( Unique Index ) براش بساز.
همیشه این احتمال رو بده که به هر دلیل نیاز باشه ساختار شماره‌ی نامه عوض بشه. مثلاً کارفرما بخواد که بهش
یک حرف و یک / اضافه کنی مثل "5264223/ک" اون‌جا هست که اگه کلید اصلی باشه این کار ساده تبدیل می‌شه
به یک مشکل عظیم. ( چون تو تمام جدول‌ها به این کلید اصلی وصل هستی ).
4. باز هم «وحدت رویه»! تو جدول واسط می‌بینم که به سه جدول کلید خارجی داری
userid
letter_id
type_code
چرا برای هر کدوم یک شکل نام‌گذاری متفاوت داری؟ همه رو با یک فرمول نام‌گذاری کن. مثلاً
user_id, letter_id, type_id

[کمبودها]
جدول واسط چه چیزی رو نشون می‌ده؟ فرستنده یا گیرنده؟ در هر صورت یکی رو جا انداختی.
درستش اینه که این جدول برای گیرنده یا گیرنده‌گان نامه باشه و فرستنده یک کلید خارجی
تو جدول نامه داشته باشه ( چون نویسنده‌ی نامه یکتا هست ) که این مورد رو جا انداختی.
تصور می‌کنم که منظورت از جدول tbl_types نوع گیرنده باشه ( گیرنده‌ی اصلی یا cc یا bcc ).

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

این صورت مساله ریزه‌کاری زیاد داره، اما فعلاً تا همین حد تونستم به چند مورد اشاره کنم. امیدوارم
که مفید واقع بشه.

صبا صبوحی

[IMANAZADI]

با تشکر از دقت شما دوست گرامی
عرض کنم موارد 1 تا 4 حق با شماست و خودم نیز همیشه رعایت میکنم
فقط من این دیاگرام رو فقط جهت اینکه منظورمو برسونم بصورت سریع و سرسری آماده کردم

در خصوص مابقی موارد :
برای فرستنده نامه که همیشه یک نفر بیشتر نیست و یکتا می باشه میتونیم یک فیلد به جدول نامه اضافه کنیم و نام فرستنده رو همونجا درج کنیم ؟؟؟؟؟



تصور می‌کنم که منظورت از جدول tbl_types نوع گیرنده باشه ( گیرنده‌ی اصلی یا cc یا bcc ).


بله منظورم همین بود
بنظر شما صحیح هست ؟؟؟
یا ایده دیگه ای دارید ؟





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


منظورتون اینه که یک فیلد از نوع شماره نامه در جدول نامه ها اضافه کنم و این دو رو با هم self refrence بزنم ؟؟؟

[SabaSabouhi]

با تشکر از دقت شما دوست گرامی
عرض کنم موارد 1 تا 4 حق با شماست و خودم نیز همیشه رعایت میکنم
فقط من این دیاگرام رو فقط جهت اینکه منظورمو برسونم بصورت سریع و سرسری آماده کردم

در خصوص مابقی موارد :
برای فرستنده نامه که همیشه یک نفر بیشتر نیست و یکتا می باشه میتونیم یک فیلد به جدول نامه اضافه کنیم و نام فرستنده رو همونجا درج کنیم ؟؟؟؟؟



بله منظورم همین بود
بنظر شما صحیح هست ؟؟؟
یا ایده دیگه ای دارید ؟



منظورتون اینه که یک فیلد از نوع شماره نامه در جدول نامه ها اضافه کنم و این دو رو با هم self refrence بزنم ؟؟؟

سلام
1. دقیقاً منظورم همین بود، برای فرستنده یک کلید در جدول نامه بگیر. چون نویسنده فقط یک نفر می‌تونه باشه.
2. به نظر قابل قبول میاد ( منظورم جدول tbl_types هست )، اما این که ایده‌ی خودم هست یا نه، به این راحتی نمی‌تونم جواب
بدم. چون شناخت مناسب از کل صورت مساله ندارم، اما احتمالاً چیزی تو همین مایه‌ها خواهد بود.
3. دوست من، من که خیلی صریح گفتم که شماره‌ی نامه «نباید» کلید باشه، نگران یک ستون اضافی نباش.
و اما پاسخ این پرسش مثبت هست، بله شما باید یک ارجاع حلقه‌ای به خود جدولت داشته باشی که ساختاری شبیه به
linked list رو ایجاد می‌کنه و این همون چیزی هست که برای نمایش سابقه‌ی یک نامه بهش نیاز داری.

صبا صبوحی

[IMANAZADI]

من دیاگرام رو اصلاح کردم (جدول Attachment ها رو نذاشتم )
ولی یه مشکلی در مورد ارجاعات دارم

من توی اتوماسیون یه شرکتی دیدم در قسمت بالای هر نامه و ارجاعاتش شماره نامه نوشته شده بود بدین صورت که اگر شماره نامه اصلی به این صورت بود xxx-0001 شماره نامه بعدی که جواب و ارجاع همین نامه بود که در پایین اون نشون داده میشد به صورت xxx-0001-01 و به همین صورت xxx-0001-02 و.... بود

حالا دو سوال برای این مورد :

سوال اول :
آیا بیایم و یک ستون دیگه در جدول نامه ها اضافه کنم و در برنامه توسط کدنویسی آخرین مقدار ارجاع هر نامه رو بگیرم و + 1 کنیم در ستون فوق آپدیت کنم
یا بیام ارجاعات رو براساس id به صورت نزولی به صعودی مرتب کنم و با کد نویسی و یکی به متغییر COUNTER اضافه کنم


سوال دوم :
برای نامه های ارجاع شده به نامه اصلی اگر ما شماره نامه رو یونیک ایندکس کرده باشیم که دیگه نمیتونیم همون شماره نامه رو بزاریم
اگر هم از یونیک ایندکس دربیاریم که احتمال خطا هست (نامه تکراری و ....)

[SabaSabouhi]

من دیاگرام رو اصلاح کردم (جدول Attachment ها رو نذاشتم )
ولی یه مشکلی در مورد ارجاعات دارم

من توی اتوماسیون یه شرکتی دیدم در قسمت بالای هر نامه و ارجاعاتش شماره نامه نوشته شده بود بدین صورت که اگر شماره نامه اصلی به این صورت بود xxx-0001 شماره نامه بعدی که جواب و ارجاع همین نامه بود که در پایین اون نشون داده میشد به صورت xxx-0001-01 و به همین صورت xxx-0001-02 و.... بود

حالا دو سوال برای این مورد :

سوال اول :
آیا بیایم و یک ستون دیگه در جدول نامه ها اضافه کنم و در برنامه توسط کدنویسی آخرین مقدار ارجاع هر نامه رو بگیرم و + 1 کنیم در ستون فوق آپدیت کنم
یا بیام ارجاعات رو براساس id به صورت نزولی به صعودی مرتب کنم و با کد نویسی و یکی به متغییر COUNTER اضافه کنم


سوال دوم :
برای نامه های ارجاع شده به نامه اصلی اگر ما شماره نامه رو یونیک ایندکس کرده باشیم که دیگه نمیتونیم همون شماره نامه رو بزاریم
اگر هم از یونیک ایندکس دربیاریم که احتمال خطا هست (نامه تکراری و ....)

سلام
دوست عزیز، اگه فیلم قدیمی «اجاره‌نشین‌ها» رو دیده باشی، یه ساختمون یک طبقه بوده که به تدریج طبقات بهش
اضافه می‌کنن تا می‌شه 6 طبقه و آخرش هم فرو می‌ریزه.
وقتی پست اول رو دیدم گمان کردم که هدفت نوشتن یه پروژه‌ی آزمایشی یا دانشجویی هست.
اما این پست آخر نشون می‌ده که هدف جدی‌تری داری.
اگه با یک هدف جدی قصد نوشتن یک سیستم رو داری. باید قبل از شروع طراحی، تعریف رو کامل کرده باشی.
همونطور که گفتم سیستم اتوماسیون سیستم ساده‌ای نیست. اگه بخوای کامل باشه نیاز به جدول‌های زیادی
داره. تو ارجاع‌ها یک کاربر می‌تونه روی نامه‌ی اصلی حاشیه نویسی کنه. می‌تونه یک برگه به نامه اضافه کنه.
بحث دسترسی‌ها هست، ممکنه مثلاً من نامه رو ارجاع بدم به کسی، اما اجازه ندم که برگه‌ای رو که خودم به
نامه اضافه کردم رو ببینه.
این که با 3-4 تا جدول سیستم رو طراحی کنی، بعد بخوای برای هر نیازی یه تغییراتی به دیتامدل بدی، به نظر من که
به هیچ عنوان روش صحیحی نیست و منجر به ساختار ناپایداری می‌شه مثل همون ساختمون فیلم اجاره‌نشین‌ها
که اول پست گفتم.
برای طراحی مناسب اول تعریف رو کامل کن. بعد تحلیل کن، و با یک دید وسیع که تمام ورودی‌ها، خروجی‌ها ( نیازها )
و عملیات رو بتونی در نظر داشته باشی اقدام به طراحی دیتامدل کن.
در غیر این صورت مشکل زیاد پیدا می‌کنی.

صبا صبوحی