تحلیل جداول مالی سیستم دانش آموزی

[veniz2008]

سلام،من بخش مالی پروژه ام رو نیاز به راهنمایی دارم. ابتدا توضیحات کلی: در این سیستم دانش آموز با مراجعه به آموزشگاه در آزمون های کنکور ثبت نام میکنه. هنگام ثبت نام کل مبلغ مشخص و دانش آموز قسمتی از این مبلغ رو به عنوان پیش پرداخت میپردازه و برای مابقی شهریه تعداد اقساط مشخص و هزینه هر قسط(به همراه تاریخ سررسید هر قسط) هم نشون داده میشه. یه مثال میزنم تا منظورمو کامل برسونم:فرض کنید کل هزینه 300 هزار تومان باشه و موقع ثبت نام 100 هزار تومان بصورت پیش پرداخت واریز میشه و 200هزارتومان مابقی طی 4 قسط(هر قسط 50 هزار)مشخص میشه. حالا برای پیاده سازی این کارها من دو جدول زیر رو در نظر گرفتم:
الف) جدول مشخصات مالی: 1.شماره داوطلبی. 2.سال آزمون 3.مبلغ کل شهریه 4.مبلغ پیش پرداخت 5.شماره فیش پیش پرداخت 6.تاریخ فیش پیش پرداخت 7.تعداد اقساط
ب) جدول اقساط: 1.شماره داوطلبی 2.سال آزمون 3. شماره قسط 4.مبلغ قسط 5.تاریخ سررسید قسط 6.وضعیت قسط(این فیلد در بار اول برای همه قسط ها بصورت 'پرداخت نشده' ثبت میشه) 7.شماره فیش قسط 8.تاریخ فیش پرداختی.
آیا این تحلیلی که انجام دادم درسته یا نقایصی در اون می بینید؟(لطفا با ذکر دلیل و پیشنهاد راه بهتر منو راهنمایی کنید.)

[maktoom]

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

[veniz2008]

ضمن تشکر از توجهتون.به غیر از این دو جدول بانک من حدود 11 جدول دیگه داره. من اصراری برای اضافه نکردن جدول ندارم ولی برای ایجاد یک جدول باید یک دلیل منطقی باشه. مثلا چه نیازی هست برای مبلغ یک جدول جداگانه در نظر گرفته بشه؟اگر چنین جدولی اضافه بشه چه فیلدهایی رو شامل میشه؟ همچنین در مورد وضعیت ها.
در مورد تخفیف ها چرا این کار انجام میشه(در یک جدول دیگه نوع سهمیه دانش آموز مشخص میشه و میزان تخفیف در نظر گرفته میشه).
فرض کنید دانش آموز در سال 90 ثبت نام کرده و کد 1000 رو بهش اختصاص دادیم، حالا همون دانش آموز امسال هم میخواد ثبت نام کنه، در سیستم اولین کاری که انجام میشه کد ملی رو چک میکنیم اگر وجود داشت پیغام میده که این دانش آموز قبلا ثبت نام کرده و اطلاعاتش نمایش داده میشه و میتونیم اطلاعات رو برای سال جدید ثبت کنیم.
در رابطه با چند به چند بودن جدول مشخصات مالی و داوطلب میشه بیشتر توضیح بدید؟
دوستان علاوه بر موارد بالا که گفتم یه تحلیل دیگه هم روی این دو جدول انجام دادم و به نظرم رسید یه سری تغییرات میتونم در دو جدول بالا بدم به این صورت که کلا مبلغ پیش پرداخت و تاریخ فیش پیش پرداخت و شماره فیش پیش پرداخت رو به جدول دومی(یعنی جدول اقساط) منتقل کنم و پیش پرداخت رو هم بصورت یک قسط (اولین قسط) درون جدول اقساط ذخیره کنم. دلیل این کارم بخاطر اینه که موقع گزارش گیری مجبور نباشم از دو جدول استفاده کنم و تمامی کارها رو فقط روی جدول اقساط انجام بدم. یعنی نتیجه به اینصورت میشه:
الف) جدول مشخصات مالی: 1.شماره داوطلبی. 2.سال آزمون 3.مبلغ کل شهریه
ب) جدول اقساط: 1.شماره داوطلبی 2.سال آزمون 3. شماره قسط 4.مبلغ قسط 5.تاریخ سررسید قسط 6.وضعیت قسط(این فیلد در بار اول برای همه قسط ها بصورت 'پرداخت نشده' ثبت میشه) 7.شماره فیش قسط 8.تاریخ فیش پرداختی.
به نظرتون کدوم روش بهتره؟. تاکید میکنم که دنبال بهترین و مناسب ترین راه هستم. نمیخوام کیفیت کار رو فدای سادگی کنم.

[Mahmoud.Afrad]

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

برای قیمت هر رشته هم میتونید یک جدول جدا داشته باشید. در این صورت با تغییر قیمت یک کلاس در سال های مختلف مشکلی برای ذخیره ندارید. id رشته-کلاس با قیمت دوره در این جدول ثبت میشه.

یک جدول برای مراجعه کننده(مشترک، شخص) که مشخصات خود شخص ثبت میشه(نام و نام خانوادگی و آدرس و تلفن و ...).

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

یک جدول هم برای قسط های پرداختی. در این جدول id جدول ثبت نام و قیمت قسطی که پرداخت شده و تاریخ پرداخت قسط و ... ثبت میشه.

همه جدول ها باید فیلد id مخصوص به خود داشته باشند که با شماره فیش و رسید ثبت نام و .. فرق داره.

[veniz2008]

اجازه بدید توضیحات بیشتری رو بگم.
سیستم قراره این کارها رو انجام بده:
کل سیستم دارای 3 بخش کلی هست:
I) مشخصات فردی داوطلب.
II) مشخصات آزمونی.
III) مشخصات مالی.
اما توضیحات بیشتر:داوطلب موقع ثبت نام ضمن مشخص شدن مقطع و پایه و رشته تحصیلیش شهریه اش مشخص میشه و اگه طرح (همون سهمیه) داشته باشه شامل تخفیف میشه و از شهریه اش کسر میشه.(مثلا دانش آموز مقطع دبیرستان پایه دوم رشته تجربی که شامل طرح فرهنگیان میشه).حالا برای دانش آموز در سیستم کارهای زیر انجام میشه:
در جدول مشخصات فردی ، مشخصات داوطلب مثل کد داوطلبی و کد ملی و نام و ... ذخیره میشه که کد داوطلبی کلید خواهد بود و یکتا بودن کد ملی هم درون برنامه چک میشه.
بعد از ثبت مشخصات فردی داوطلب، باید با توجه به مقطع و پایه و رشته، برای داوطلب آزمون تعیین بشه( اینکه چندتا آزمون داره، هر آزمون چه تاریخی هست و مبلغ هر آزمون چقدره و ...)،این کار بصورت زیر در سیستم انجام میشه:
جدول مشخصات آزمونی شامل : کد داوطلب، سال آزمون، شماره طرح( شماره طرح برای گرفتن تخفیف هستش، مثلا طرح 1 برای فرهنگیان و ...)، شماره مقطع تحصیلی(مثلا شماره 1 برای مقطع دبستان،شماره 2 برای مقطع راهنمایی و ...)،شماره پایه تحصیلی(مثلا برای مقطع دبستان از پایه 1 تا پایه 6 خواهیم داشت)،شماره رشته تحصلی (برای دبستان و راهنمایی و اول دبیرستان شماره رشته 1 خواهد بود چون تا سال دوم دبیرستان رشته تحصیلی وجود نداره. برای ریاضی 2، برای تجربی 3 و برای انسانی 4 خواهد بود)، شماره رابط تحصیلی(منظور از رابط همون مشاور تحصیلی خواهد بود). این نکته رو اضافه کنم که برای تمامی فیلدهای بالا که شماره اونها در جدول مشخصات ازمونی اومده یک جدول جداگانه در نظر گرفتم.
بعد از مشخص شدن مباحث آزمونی داوطلب باید سراغ مباحث مالی بریم، اینکه با توجه به تعداد آزمون هاش ، کل شهریه چقدر میشه،اگه طرح داره از مبلغ شهریه کسر بشه، چقدر بصورت پیش پرداخت میپردازه و بقیه شهریه به چه صورت قسط بندی میشه،این کارها در سیستم بصورت زیر انجام خواهد شد:
بحث مشخصات مالی خودش به دو جدول تقسیم میشه:الف. جدول مشخصات مالی شامل: 1.شماره داوطلبی. 2.سال آزمون 3.مبلغ کل شهریه 4.تعداد اقساط
ب) جدول اقساط: 1.شماره داوطلبی 2.سال آزمون 3. شماره قسط 4.مبلغ قسط 5.تاریخ سررسید قسط 6.وضعیت قسط(این فیلد در بار اول برای همه قسط ها بصورت 'پرداخت نشده' ثبت میشه) 7.شماره فیش قسط 8.تاریخ فیش پرداختی.
البته اینم بگم جداول الف و ب رو بصورت زیر هم پیش بینی کردم که از اساتید میخوام بگن کدومشون بهتره، حالت دوم:
الف) جدول مشخصات مالی: 1.شماره داوطلبی. 2.سال آزمون 3.مبلغ کل شهریه 4.مبلغ پیش پرداخت 5.شماره فیش پیش پرداخت 6.تاریخ فیش پیش پرداخت 7.تعداد اقساط
ب) جدول اقساط: 1.شماره داوطلبی 2.سال آزمون 3. شماره قسط 4.مبلغ قسط 5.تاریخ سررسید قسط 6.وضعیت قسط(این فیلد در بار اول برای همه قسط ها بصورت 'پرداخت نشده' ثبت میشه) 7.شماره فیش قسط 8.تاریخ فیش پرداختی.

[maktoom]

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

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

[ali_habibi1384]

مشكلاتي كه تحليلتون داره ايناست:
1-سال آزمون در هر د جدول الف و ب موجوده كه نيازي به اين كار نيست بايد در يك جدول بياد و با توجه به اينكه داوطلب ممكنه در چند آزمون شركت كنه در جدول ب بايد آورده بشه كه معلوم بشه هر قسط مال كدوم آزمونه
2- در جدول ب شما بايد دوتا فيلد اضافه كنيد مثلا اينكه اقساط ديرتر پرداخت بشه مبلغ جريمه توش زده بشه و دوم مبلغ كل كه حاصل جمع مبلغ جريمه و مبلغي كه بايد پرداخت ميشده
3-جدولهاي پرداخت اقساط نبايد در هنگام ثبت نام دانش آموز ايجاد بشه شما بايد فكر نياز آينده احتمالي كاربر رو بكنيد مثلا اينكه طرف همه اش رو در قسط بعدي پرداخت كنه اونوقت چون شما يك شماره فيش منحصر به فرد داريد نميتونيد براي همه اش همونو بزنيد و از اون گذشته اطلاعات غير واقعي توي سيستم بالاجبار ثبت خواهد شد كه مطلوب نيست.
4- فكر ميكنم يه جاي يه جدول شماره سومي هم خالي باشه كه سال آزموني هست كه داوطلب شركت ميكنه مثلا شما اينجوري در نظر بگيريد كه داوطلب در دو آزمون شركت كرده باشه سطح اول مشخصات مالي سطح دوم آزمون و سطح سوم اقساط پرداختي هر آزمون اين جدول براي جلوگيري از افزونگي داده استفاده ميشه
5- در صورتي كه جدول شماره 3 رو به پيشنهاد من اضافه كرديد بايد مبلغ پيش پرداخت و شهريه رو توي اون اضافه كنيد چون در هر آزمون جديد مبلغ پيش پرداختها و آزمونها متفاوت خواهد بود كه بايد در اون جدول اضافه بشه.
6- يه فيلد واسط در جدول الف درست كنيد كه شامل جمع كل پرداختي ها منهاي جمع كل شهريه قابل پرداختها كنه تا مشخص بشه چقدر بدهي داره.
چيز ديگه به ذهنم نميرسه

[veniz2008]

ضمن تشکر از راهنمایی دوستان، در جواب راهنمایی های دوست عزیز ali_habibi1384 (http://barnamenevis.org/member.php?48789-ali_habibi1384) چندتا نکته رو اشاره میکنم:
1. قیمت تمام آزمون ها یکسانه و برای هر آزمون به تنهایی شهریه ای اخذ نمیشه، مهم اینه که میزان بستانکاری داوطلب به اندازه ای باشه که بتونه در آزمون شرکت کنه.(یعنی اگه قراره آزمون 5 رو شرکت کنه حداقل بایستی شهریه 4 آزمون قبلی + آزمون 5 رو پرداخت کرده باشه)
2.با توجه به صحبت هایی که با مدیر اونجا انجام دادم قصد این رو نداره که از داوطلب جریمه دیر کرد بگیره.
3. فرض کنید برای داوطلب 3 قسط پیش بینی کرده باشیم و هر قسط 50 هزار تومان باشه. حالا در تاریخ سررسید قسط داوطلب قصد این رو داره که تمام بدهی رو یکجا بپردازه. این امکان درون برنامه قرار داده میشه که کاربر بتونه غیر از مبلغی که در قسط اومده رو بپردازه. یعنی زمانیکه تمام قسط رو پرداخت کرد، مبلغ پیش پرداخت + مبلغ قسط (ها) با هم جمع و از شهریه کم میشه اگه مبلغ 0 ( یا منفی شد یعنی داوطلب بستانکار بود) کلا هیچگونه قسط بندی انجام نمیشه.اگرم قسط بندی وجود داشته باشه پس از معلوم شدن بستانکاری، تمامی قسط ها پاک میشن. خلاصه بگم بعد از هر بار پرداخت قسط، باتوجه به میزان بدهکاری قسط بندی دوباره چک میشه.
4. در پست 5 و در قسمت جدول مشخصات آزمونی سال آزمون در نظر گرفته شده و مشخصه که داوطلب برای چه سالی قراره آزمون بده.
5. با توجه به توضیح 4 به نظر نمیرسه این جدول نیازی باشه!!
6.در مورد فیلدی که گفتید قبلا فکر کرده بودم،اتفاقا اگه باشه یه جاهایی خیلی میتونه بهم کمک کنه ولی یه موردی هست، این فیلد درواقع یه صفت مشتق هست و خودش به تنهایی وجود نداره( یعنی میزان بدهکاری = مبلغ کل شهریه - مبالغ پرداختی داوطلب)، قبلا تو دانشگاه استادمون میگفت که بهتره فیلد مشتق در جدول ذکر نشه و در موقع نیاز با توجه به فیلدهای دیگه محاسبه بشه.
با توجه به مواردی که ذکر کردم آیا به نظرتون باز هم نیاز به تغییرات هست؟، اگه هست لطفا ذکر کنید.

[Nima_kyan]

البته فك ميكنم فيلد "تعداد اقساط" در جدول "مشخصات مالي" تحليل دوم فراموش شده كه قطعا بايد تعداد اقساط مشخص شده باشه.
و در جواب پيشنهاد شماره 1 دوستمون ali_habibi1384 (http://barnamenevis.org/member.php?48789-ali_habibi1384) بايد بگم فيلد "سال آزمون" در هر دو جدول الف و ب اجباري هستش چون يه داوطلب با يه شماره داوطلبي واحد در دو سال مختلف بايد دو محاسبه شهريه داشته باشه. و همچنين فيلد كليد اين جدول بايد تركيبي از فيلد "شماره داوطلبي" و "سال آزمون" باشه.
و درمورد پيشنهاد شماره 6 همون دوستمون همونطور كه mohammaddou (http://barnamenevis.org/member.php?155296-mohammaddou) توضيح دادن فيلد "ميزان بدهي" يه صفت مشتقه كه از صفت هاي ديگه ميشه ميشه محاسبه شه و ثبت كردن يك صفت مشتق در بانك اطلاعاتي باعث افزونگي در بانك ميشه. مثله ثبت تاريخ تولد و سن يك شخص كه قطعاٌ سن رو ميشه از روي تاريخ تولد محاسبه كرد.
به نظر من تحليل دوم mohammaddou (http://barnamenevis.org/member.php?155296-mohammaddou) دقيق تر باشه.

[veniz2008]

ضمن تشکر از Nima_kyan (http://barnamenevis.org/member.php?155260-Nima_kyan) که در تحلیل پروژه با همدیگه این کار رو انجام دادیم، بله تعداد اقساط فراموش شده بود که در پست 5 تصحیح کردم.دوستان به نظر شما بهتره که پیش پرداخت به عنوان قسط اول در همون جدول اقساط ثبت بشه یا اینکه پیش پرداخت به همراه کل شهریه در یک جدول باشه و فقط اقساط رو درون جدول اقساط داشته باشم؟

[ali_habibi1384]

منظور من هم از واسط همون مشتق بود! كه توي شماره 6 گفتم .از نظر سال آزمون بازهم تحليلتون اشتباهه و بايد جدول شماره 3 بوجود بياد در غير اينصورت همون افزونگي داده بوجود مياد(هرچند به ميشه با سيستم فعلي با اين نواقص كار كرد).در هر صورت من كه 10 سال كارم تحليل و برنامه نويسي پيشنهادم و راه حلم اين بود دوست داشتين پياده سازي كنيد.
پيش پرداخت بايد در جدولي كه من بهتون گفتم ثبت شده هر جاي ديگه از نظر اصولي اشتباهه.
تحليل اول شما از نظر پياده سازي نمره 15 و تحليل دوم نمره 16.5 ميگيره از نظر من و قابل قبوله. موفق باشيد.

[veniz2008]

دوستان من یک عکس از تمامی جداول بانک رو میذارم،البته ارتباط ها در این شکل هنوز برقرار نشده. ممنون میشم نظراتتون رو بگید. همچنین من فعلا برای اغلب فیلدها و جداول نام های فارسی قرار دادم، شما چه عناوینی رو پیشنهاد میکنید؟
89991

[Mahmoud.Afrad]

در جدول TblStdExam کلید اصلی ناقصه چون یک student در یک سال میتونه چند رشته انتخاب کنه(البته اگر بتونه چند رشته رو همزمان بگیره). پس studentID و YearExam و ReshteID میتونه کلیداصلی باشه.

در جدول TblMali یک فیلد برای تعداد قسط های برداخت شده اضافه کنید تا معلوم بشه چند قسط رو داده. (میتونید یک فیلد هم برای هزینه پرداخت شده تا به حال اضافه کنید اینطوری مقدار بدهی میشه هزینه کل منهای هزینه پرداخت شده. هزینه پرداخت شده هم یعنی جمع همه قسط های پرداخت شده بعلاوه پیش قسط). اگر هم امکان گرفتن چند رشته همزمان هست باید ReshteID هم بیاد)

در جدول TblGhest همونطور که ali_habibi1384 (http://barnamenevis.org/member.php?48789-ali_habibi1384) فرمودند نیازی نیست همه سطرها همون اول ایجاد بشند. پس نیازی به فیلد GhestStatus نیست. یعنی با پرداخت قسط اونوقت یک سطر اضافه میشه و اطلاعات درج خواهد شد نه همون اول.
اگر هر شخص میتونه چند رشته رو هم زمان انتخاب کنه باید معلوم باشه این قسطی که شخص میده مربوط به چه رشته ای هست پس ReshteID باید به این جدول اضافه شود.

اگر هم برای جدول ها یک ID مخصوص اون جدول داشته باشید نیازی نیس کلید اصلی ترکیبی استفاده کنید و همچنین خیلی راحت تر میتونید برای کلیدهای خارجی از این کلیدهای اصلی استفاده کنید. مثلا در TblMali یک فیلد MaliID داشته باشید و در جدول TblGhest به جای دو فیلد Student , YearExam فقط یک فیلد MaliID رو به عنوان کلید خارجی بیارید

[maktoom]

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

[Nima_kyan]

در اين سيستم چون آزمون تمام رشته ها همزمان برگزار ميشه امكان شركت كردن يك داوطلب در چند رشته وجود نداره.كه اگه اين امكان وجود داشت اصلاحات mafaman2003 (http://barnamenevis.org/member.php?71297-mafaman2003) نياز بود.
و در مورد نكته دوم mafaman2003 (http://barnamenevis.org/member.php?71297-mafaman2003) آيا اين كار ضروريه(اضافه كردن تعداد قسط پرداخت شده)؟؟ يا فقط باعث راحتي كار برنامه نويس ميشه؟ چون اين اطلاعات قابل محاسبه شدن ازفيلدهاي ديگه هستن.
و در مورد نكته سوم mafaman2003 (http://barnamenevis.org/member.php?71297-mafaman2003) زمان ثبت نام بايد پرينت اقساط شامل تاريخ سررسيد هر قسط و مبلغ هر قسط به داوطلب داده بشه پس شايد راهي جز ايجاد اقساط هر داوطلب موقع ثبت نام وجود نداشته باشه. فقط جهت انعطاف پذير بودن برنامه مبلغ قسط زمان پرداخت قابل تغييره چون داوطلب ممكنه بخواد مبلغ بيشتري پرداخت كنه كه در اين صورت مبلغ قسط هاي بعد update ميشه.(البته پيشنهاد من اينه)
اگه راهكار بهتري هست ممنون ميشيم پيشنهاد كنيد.(همونطور كه mohammaddou (http://barnamenevis.org/member.php?155296-mohammaddou) اشاره كردن من و mohammaddou (http://barnamenevis.org/member.php?155296-mohammaddou) تحليل اين سيستم رو داريم باكمك هم انجام ميديم)

و در مورد راهنمايي دوستمون maktoom (http://barnamenevis.org/member.php?123790-maktoom) : در تحليلي كه با موسسه انجام داديم هيچ چكي از داوطب ها دريافت نميشه.

[veniz2008]

ببینید هدف از فیلد GhestStatus اینه که متوجه بشم وضعیت یک قسط به چه صورته؟(یعنی پرداخت شده یا نه؟)
ممنون میشم به این سوال هم پاسخ بدید که آیا قرار دادن صفت مشتق اصولی هست یا نه؟(مثلا همون فیلد میزان بدهکاری که دوستان گفتن بهتره در جدول اضافه بشه، چون میزان بدهکاری رو میشه از روی فیلدهای دیگه جدول دیگه هم بدست آورد). بقیه موارد رو هم دوستم Nima_kyan (http://barnamenevis.org/member.php?155260-Nima_kyan) توضیح دادن و از تکرار اونا خودداری میکنم.

[maktoom]

ممنون میشم به این سوال هم پاسخ بدید که آیا قرار دادن صفت مشتق اصولی هست یا نه؟(مثلا همون فیلد میزان بدهکاری که دوستان گفتن بهتره در جدول اضافه بشه، چون میزان بدهکاری رو میشه از روی فیلدهای دیگه جدول دیگه هم بدست آورد).
بستگی داره. اینم مثل قیمت تمام شده میمونه. شاید لازم باشه یه روزی بخواید بدونید طرف تا اون تاریخ میزان بدهکاریش چقد بوده. اگه اینکارو نکنید ممکنه بدهی فعلی رو همیشه داشته باشید. یا باید یه کوئری طولانی بزنید که در اون تاریخ مقادیر رو بدست بیاره بعد جمع و تفریق کنه. اینجوری بدهی در هر تاریخی مشخصه. البته معمولا کوئری رو یکبار می نویسن!

[ali_habibi1384]

بستگی داره. اینم مثل قیمت تمام شده میمونه. شاید لازم باشه یه روزی بخواید بدونید طرف تا اون تاریخ میزان بدهکاریش چقد بوده. اگه اینکارو نکنید ممکنه بدهی فعلی رو همیشه داشته باشید. یا باید یه کوئری طولانی بزنید که در اون تاریخ مقادیر رو بدست بیاره بعد جمع و تفریق کنه. اینجوری بدهی در هر تاریخی مشخصه. البته معمولا کوئری رو یکبار می نویسن!
اين ديگه از اون حرفهاست! واسه چنين گزارشي يه SP مينويسي كه جمع بدهكاري و پرداختي تا يه تاريخ خاص رو حساب كنه.
از همون مشتق اصوليش ميشه غير از اون اشتباهه.
توي صحبتهاي دوستمون آقاي mafaman2003 (http://barnamenevis.org/member.php?71297-mafaman2003) چندتا از چيزايي كه من توي پست اولم بهتون گوش زد كردم ديده ميشه اما ايشون يه جور ديگه بيان كردن.بذاريد توي كار واقعي متوجه منظور حرف من ميشيد.
براي تحليل پروژه تون لطفا ارتباطا رو هم بذاريد اينوري هيچي معلوم نيست.!

[maktoom]

البته معمولا کوئری رو یکبار می نویسن!
این جمله رو دقیقا واسه همین گفتم که با این جمله مواجه نشم:

اين ديگه از اون حرفهاست! واسه چنين گزارشي يه SP مينويسي كه جمع بدهكاري و پرداختي تا يه تاريخ خاص رو حساب كنه.

[veniz2008]

من یک عکس از ارتباط بین جداول گذاشتم، ممنون میشم اشکالات و پیشنهادهای جدیدی اگر دارید مطرح کنید.
90078

[veniz2008]

دوستان یک سوال هم درباره جدول رشته های تحصیلی داشتم( Tbl Reshte). در این جدول کلید بصورت ترکیبی فرض شده. یعنی مقطع،پایه و شماره رشته (مثلا مقطع دبستان،پایه اول،شماره رشته 1 (برای دبستان،راهنمایی و اول دبیرستان نام رشته رو "عمومی" در جدول در نظر میگیریم)، یا مقطع دبیرستان،پایه 2 ،رشته 1 (ریاضی) یا مقطع دبیرستان، پایه 2 ، رشته 2(تجربی) و ...). حالا به نظرتون اجبار هست که کلید ترکیبی باشه؟. اگر فقط شماره رشته رو کلید بگیرم( بصورت identity) به مشکلی برنمیخورم؟(یعنی به جای کلید ترکیبی فقط از فیلد شماره رشته به عنوان کلید استفاده کنم).

[Mahmoud.Afrad]

توی پست قبلی گفتم، اگر کلید ترکیبی بگیری اونوقت قرار باشه این کلید ترکیبی توی جدول دیگه ای به صورت کلید خارجی بیاد دردسر داره.

یک سوال، آیا نمیشه جدول مقطع و رشته رو یکی کرد؟؟
یک سوال مهمتر ، TblReshte و TblPriceExam به چه دردی میخوره؟؟ اینو پرسیدم چون هیچ رابطه خروجی ندارند!!(TblReshte با TblStdExam باید رابطه داشته باشه و TblPriceExam هم با TblExam)

[Nima_kyan]

توی پست قبلی گفتم، اگر کلید ترکیبی بگیری اونوقت قرار باشه این کلید ترکیبی توی جدول دیگه ای به صورت کلید خارجی بیاد دردسر داره.

یک سوال، آیا نمیشه جدول مقطع و رشته رو یکی کرد؟؟
یک سوال مهمتر ، TblReshte و TblPriceExam به چه دردی میخوره؟؟ اینو پرسیدم چون هیچ رابطه خروجی ندارند!!(TblReshte با TblStdExam باید رابطه داشته باشه و TblPriceExam هم با TblExam)

دوست عزيز من هم راجبه كليد تركيبي با شما موافقم.
و راجبه سوال اولتون فك كنم اگر قرار بر تركيب جداول باشه شايد بهتر باشه سه جدول با هم تركيب شن، جداول "مقطع تحصيلي" ، "پايه" و "رشته تحصيلي". چون مثلا بايد مشخص شه كه هر رشته مربوط به چه پايه اي هستش.(هر پايه چه رشته هايي داره). ولي شايد دليل جدا كردن سه جدول از هم سعي بر استاندارد بودن بانكمون باشه.
و در جواب سوال دوم جدول TblPriceExam جهت نگهداري قيمت آزمون هاي هر پايه طراحي شده چون آزمون هاي پايه هاي مختلف قيمت هاي مختلفي دارند و طبيعتا هر سال هم قيمت آزمون ها تغيير ميكنه.
و درآخر من فكر ميكنم جدول TblPriceExam بايد با جدول TblStdExam رابط داشته باشه.

[veniz2008]

دوستان نظر منم تا حدود زیادی شبیه به Nima_kyan (http://barnamenevis.org/member.php?155260-Nima_kyan) هست. آیا ادغام سه جدول مقطع، پایه تحصیلی و رشته تحصیلی کار اصولی هست؟. بقیه موارد رو هم که دوستم توضیح دادن. ممنون میشم راهنمایی کنید.