PDA

View Full Version : گفتگو: تحلیل دیتابیس آموزشگاه



f.beigirad
شنبه 18 خرداد 1392, 16:07 عصر
با سلام دوستان من.

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

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

///ویرایش : لطفا پست آخر را مطالعه کنید : http://barnamenevis.org/showthread.php?402427-%D8%AA%D8%AD%D9%84%DB%8C%D9%84-%D8%AF%DB%8C%D8%AA%D8%A7%D8%A8%DB%8C%D8%B3-%D8%A2%D9%85%D9%88%D8%B2%D8%B4%DA%AF%D8%A7%D9%87&p=1816603&viewfull=1#post1816603


قصد دارم از SQLServer 2008 استفاده کنم.و همچنین از EF استفاده کنم.

ما اینجا با سه دسته از افراد برخورد داریم.
1.دانشجو
2.مدرس
3.کارمند

همچنین کارهای مالی رو هم قراره انجام بدیم.و البته بعد از هر پرداختی یه فاکتور هم به مشتری (دانشجو) خواهیم داد.

جداولی که در نظر دارم تعریف کنم به این صورت هستن:

1) دانشجو : 1.شماره دانشجویی 2.نام 3.نام خانوادگی 4.جنسیت

2) مدرس : 1.شماره مدرس 2.تاریخ عضویت (ثبت)

3) کارمند : 1.شماره کارمندی 2.نقش 3.نام نمایشی 4.نام کاربری 5.رمز عبور 6.وضعیت فعال بودن 7.دلیل محرومیت 8.تاریخ ورود قبلی

جداول 1 و 2 و 3 دارای ستونهای دیگه ای مثل نام و نام خانوادگی و جنسیت و ت ت و کد ملی و غیره هستن که برای کم کردن متن ننشوشتم.

4) دوره ها(کلاس) : 1.شماره دوره 2.عنوان دوره 3.شماره مدرس 4.محل برگزاری 5.شهریه 6.ظرفیت 7.جنسیت 8.تاریخ شروع 9.تاریخ پایان 10.تاریخ آزمون 11.روزهای برگزاری 12.ساعت برگزاری 13.حقوق مدرس

5)امور مالی دانشجو : 1.شماره تراکنش 2.تاریخ 3.شماره دانشجو 4.مبلغ 5.نوع پرداخت(چک یا نقد یا....) 6.شماره کارمند

6) امور مالی مدرس و کارمند : 1.شماره تراکنش 2.تاریخ 3.شماره کارمندی یا مدرس 4.مبلغ 5.نوع پرداخت

7)کتابها : 1.شماره کتاب 2.عنوان کتاب 3.سطح کتاب 4.توضیحات

8)دانشجو و دوره : 1.آیدی 2.شماره دانشجو 3.شماره دوره

9.کتاب و دوره : 1.آیدی 2.شماره کتاب 3.شماره دوره

این نتیجه فکر من از ظهر تا الانه.Aقطعا خیلی مشکل داره .

آیا برای فاکتور هایی هم که چاپ میکنیم نیاز به جدول جداگونه داریم؟
برای دانشجوهایی که شهریه رو در چند قسط میدن چجوری بفهمم چقد پول دادن و چقد باقی مونده ؟(با توجه به اینکه تخفیف هایی هم برای اقشار مختلف لحاظ خواهیم کرد.)
آیا برای صفات مشترک جداول 1 و 2و 3و باید یک جدول جداگونه درست کنم یا هر کدوم رو در جدول خودش ؟

از کسانی که تا آخر خوندن هم متشکر و هم معذرت میخوام که طولانی شد.

alexmcse
شنبه 18 خرداد 1392, 17:25 عصر
آیا برای فاکتور هایی هم که چاپ میکنیم نیاز به جدول جداگونه داریم؟ به نظر من لازم نیست
برای دانشجوهایی که شهریه رو در چند قسط میدن چجوری بفهمم چقد پول دادن و چقد باقی مونده ؟(با توجه به اینکه تخفیف هایی هم برای اقشار مختلف لحاظ خواهیم کرد.)دو جدول بساز یکی برای نقدی یکی برای قسطی
در جدول قسطی (مثلا شما معیین میکنید که دانشجو شهریه خود را در 5 قسط یا 3قسط پرداخت کند ) برای جدول قسط 3 یا 5 فیلد در نظر میگرید
+فیلد های تاریخ که در چه روزی قسط اول و... پرداخت شده است
برنامه را طوری طراحی کنید که موقع ثبت نام از دانشجو به دانشجو اختیار دهد که شهریه را نقدی (جدول نقدی ) یا قسطی (جدول قسطی) پرداخت میکند
البته باید جدول نقدی وقسطی بوسیله فورگین کی به جدول دانشجو ارتباط داشته باشد

آیا برای صفات مشترک جداول 1 و 2و 3و باید یک جدول جداگونه درست کنم یا هر کدوم رو در جدول خودش ؟ در جدول خودش (جدول جداگانه لازم نیست)

Hajivandian
یک شنبه 19 خرداد 1392, 09:31 صبح
قصد دارم از SQLServer 2008 استفاده کنم.و همچنین از EF استفاده کنم.

اگر برنامه قرار نیست، توی محیط شبکه اجرا بشه، پیشنهاد میکنم از دیتابیس Microsoft SQL Compact Edition یا SQlite استفاده کن.


5)امور مالی دانشجو : 1.شماره تراکنش 2.تاریخ 3.شماره دانشجو 4.مبلغ 5.نوع پرداخت(چک یا نقد یا....) 6.شماره کارمند

6) امور مالی مدرس و کارمند : 1.شماره تراکنش 2.تاریخ 3.شماره کارمندی یا مدرس 4.مبلغ 5.نوع پرداخت

برای مدیریت دقیق تر و متمرکز تر امور مالی رو توی یک جدول قرار بده؛ تفکیک اینها هم مدیریت مالی و هم گزارشات سیستم رو در آینده سخت میکنه.


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

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

f.beigirad
یک شنبه 19 خرداد 1392, 09:56 صبح
ممنون از پاسختون

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

آیا میشه کاری کرد ستونهای کد ملی که تو 3 تا جدول جدا جدا قرار دارن بهم مرتبط شن که مثلا یک دانشجو با کد ملی X نتونه به عنوان دبیر ثبت نام کنه؟
(کاری غیر از اینکه قبل ثبت نام همه ی جدول هارو با برنامه چک کنم.)

دیتابیس رو تو سیستم خودم باید با SQL Server بسازم و Compact Edition رو رو سیستم کاربرم نصب کنم.درسته؟

Hajivandian
یک شنبه 19 خرداد 1392, 11:22 صبح
آیا میشه کاری کرد ستونهای کد ملی که تو 3 تا جدول جدا جدا قرار دارن بهم مرتبط شن که مثلا یک دانشجو با کد ملی X نتونه به عنوان دبیر ثبت نام کنه؟
(کاری غیر از اینکه قبل ثبت نام همه ی جدول هارو با برنامه چک کنم.)

این دید اشتباهه به نظر من. مثلا فرض کن یکی از کارمندای همون آموزشگاه میخواد به عنوان دانشجو تو یکی از دوره ها شرکت کنه؟ اگه بیایم محدودیت بزاریم نمیتونه! حالا شاید این امر برای استاد صدق نکنه. که البته جلوگیری برای این کار لازم نیست.

f.beigirad
یک شنبه 19 خرداد 1392, 12:04 عصر
بازم ممنون.

این که SQL Compact از استور پروسیجر پشتیبانی نمیکنه و در تنتیجه من نمیتونم از SP استفاده کنم تا حدی امنیت نرم افزارم رو پایین نمیاره؟


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

این روند کاری درسته؟؟

f.beigirad
یک شنبه 19 خرداد 1392, 14:31 عصر
دوستان برای کد ملی و شماره تلفن که 10 رقمی هستن از int و bigint که نمیشه استفاده کرد.

کار درستیه از nvarchar استفاده کنیم؟

طرز استفاده از numbric چطوریه؟
numbric(2,4) یعنی چی؟

تصمیم گرفتم با SQL Server کار کنم که احیانا اگر خواستم بتونم به راحتی تعمیمش بدم و توی شبکه استفاده کنم.


ای دوستانی که این تحلیل ها برای شما خنده داره و یاد آور خاطره هاتونه.لطفا ما مبتدی هارو هم راهنمایی کنید.

alexmcse
دوشنبه 20 خرداد 1392, 11:41 صبح
دوستان برای کد ملی و شماره تلفن که 10 رقمی هستن از int و bigint که نمیشه استفاده کرد.

کار درستیه از nvarchar استفاده کنیم؟

طرز استفاده از numbric چطوریه؟
numbric(2,4) یعنی چی؟

تصمیم گرفتم با SQL Server کار کنم که احیانا اگر خواستم بتونم به راحتی تعمیمش بدم و توی شبکه استفاده کنم.


ای دوستانی که این تحلیل ها برای شما خنده داره و یاد آور خاطره هاتونه.لطفا ما مبتدی هارو هم راهنمایی کنید.

دوست عزیز میتوانی برای کد ملی از مقدار bigint استفاده کنی 10 رقم باشد
کار درستیه از nvarchar استفاده کنیم؟ موقع ورودی دیتا مثلا در تکست باکس باید آن را کانورت کنی به این صورت
textBox1.Text = "0123456789";
int i = Convert.ToInt32(textBox1.Text);
برای گزارش گیری هم نیاز به جدول نیست میتوان گزارش گرفت (ار پی تی )یا میتوان گزارش را با فرمت پی دی اف اکسپرت کرد

f.beigirad
سه شنبه 21 خرداد 1392, 22:33 عصر
با سلام دوستان.

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



http://s4.picofile.com/file/7799809458/Diagram.jpg



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

پیشاپیش از همتون ممنونم.

f.beigirad
چهارشنبه 29 خرداد 1392, 13:11 عصر
با سلام دوستان من.

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

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

105797


از همه ی دوستان ممنونم

veniz2008
پنج شنبه 30 خرداد 1392, 10:14 صبح
دوست عزیز میتوانی برای کد ملی از مقدار bigint استفاده کنی 10 رقم باشد
سلام.
نیازی به این کار نیست چون قرار نیست بر روی کد ملی اعمالی مثل جمع و تفریق و ... انجام بشه. کافیه نوع فیلد کد ملی رو varchar(10) بگیرید.
تا حد امکان از nvarchar استفاده نکنید چراکه دو برابر نوع varchar فضا اشغال میکنه.


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

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

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

f.beigirad
پنج شنبه 30 خرداد 1392, 21:34 عصر
با تشکر از veniz2008 (http://barnamenevis.org/member.php?155296-veniz2008)


آیا درصد تخفیف کلاس با درصد تخفیف خرید یکسانه یا نه؟خیر.امکان داره برای شهریه 10 درصد و برای کالایی 20 درصد تخفیف منظور شه.


جدول دوم هم جدول اقساط خواهد بود. شامل کد قسط(کلید و identity)، کد دانش آموز، سال آزمون، نوع آزمون، شماره قسط، قیمت قسط، تاریخ قسط، شماره رسید قسط، تاریخ پرداخت و وضعیت قسط (پرداخت شده یا نشده).به نظر من برای هر قسط نیاز به فیلد وضعیت نداریم.بلکه برای امور مالی یه وضعیت باید بذاریم تا بدونیم پرداخت شده یا نه؟
چون ما نمیتونیم برای قسط هایی که پرداخت نشدن داده ای در دیتابیس داشته باشیم(قبل از پرداخت ما نباید رکوردی درج کنیم که وضعیتشو بذاریم "پرداخت نشده"!!)



نمیدونم چرا باید برای تخفیف ها هم جدولی جداگانه داشته باشیم؟

لازم به ذکره این اقساطی که ما قرار میدیم هم برای شهریه هست و هم برای اجناسی که میخره.امکانم هست که دانشجو وسط یه تزم یه کالای دیگه بخره .پس باید اقساط تغییر کنه.{اینم گفتم شاید بتونه کمک کنه}
این مورد رو هم پاسخ بدین دیاگرامی که ساختم رو کامل میکنم و میذارم روی سایت.


با تشکر

veniz2008
پنج شنبه 30 خرداد 1392, 23:30 عصر
خیر.امکان داره برای شهریه 10 درصد و برای کالایی 20 درصد تخفیف منظور شه.
هم میتونید جدول قرار بدید و هم میتونید از setting استفاده کنید. من برای این مورد setting رو ترجیح میدم. دو متغیر Setting و از نوع int تعریف کنید و عدد مربوط به درصد تخفیف رو برای خرید و برای شهریه در اون دو متغیر ذخیره کنید.


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


نمیدونم چرا باید برای تخفیف ها هم جدولی جداگانه داشته باشیم؟همونطور که گفتم یا جدول یا متغیر Setting . باید میزان تخفیف رو یه جایی نگهداری یا نه؟. امسال 10 درصده سال دیگه هم 10 درصده؟ ممکنه بخواد کم و زیادش کنه پس باید یه جایی رو برای نگهداری درصد تخفیف بزاری.
راستی این آموزشگاه طرف قرارداد با جایی نیست؟. مثلا کمیته امداد یا فرهنگیان یا ...
اگر هست بهتره دیگه از setting استفاده نکنی و یک جدول برای تخفیف در نظر بگیری.

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

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

f.beigirad
جمعه 31 خرداد 1392, 01:04 صبح
بازم تشکر از شما دوست عزیز veniz2008

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

کل این مبالغ شهریه و جنس هایی که میفروشن برای یک. دوره اموزشی ۶۰ تومن نمیشه.و حداکثر تعداد اقساط هم ۳ یا ۴ تا هستن.
خیلی ضایع نمیشه من بیام هر کدومو جدا قسط بندی کنم ?

و در ضمن در ایده ی این تو ذهنمه که حساب دانشجویی که برای یک ترم ثبت نام کرده با تخفیف ۵۰ درصد و دوتا کتابم خریده با تخفیف ۱۰ درصد ,رو با هم جمع کنم و تو فاکتورش بیارم جمع مبلغ اینقدر شده.xتومنشو پرداخت کرده .دوتا قسط y تومنیم مونده.

حالا به نظر شما برای انجام این کار بازم نیاز به دوتا جدول اقساط داریم ?

ممنونم از کمکتونم.

f.beigirad
جمعه 31 خرداد 1392, 01:15 صبح
لینک دانلود دیاگرام.البته مربوط میشه به دیشب.

http://s4.picofile.com/file/781024



9993/Document2.zip.html (http://s4.picofile.com/file/7810249993/Document2.zip.html)

veniz2008
جمعه 31 خرداد 1392, 01:28 صبح
همونطور که خودتون هم حدس زدید من چیز زیادی از توضیحات شما متوجه نشدم اما چیزی رو که گرفتم اینا بود :
از کلمه ضایع در طراحی دیتابیس استفاده کردید : ما توی طراحی دیتابیس یه اصولی داریم که اگر اونا رو زیر پا بذاریم، نرم افزار به بیراهه میره و چه بسا مفت هم نیرزه. در چنین حالتی هست که ضایع شدیم نه اینکه بخاطر 60 تومن تفکیک کنیم ضایع بشیم. در طراحی جداولتون بسیار دقیق و سخت گیر باشید. جایی واسه رودرواسی و این جور چیزها اصلا وجود نداره. کار باید دقیق و اصولی باشه.
اینکه گفتید در یک فاکتور بیاد که کل قیمت چقد بوده و چقدر پرداخت کرده و چقدرش مونده و ... منافاتی با توضیحات قبلی من نداره. براحتی میشه بین جدول مختلف و اطلاعات شهریه یا قسط یا خرید یک شخص رو بیرون کشید و درو ن یک فاکتور نمایش داد.
من بیشتر از این نمیتونم توضیحی بدم چون اطلاعاتی که شما به من دادید ناقصه.
شب بخیر مهندس.

f.beigirad
شنبه 01 تیر 1392, 00:26 صبح
با عرض سلام و وقت بخیر

من قسمت مالی رو اینطور تحلیل کردم:
توضیحات لازم رو نوشتم.

105952
1. جدول Mali:
هر کالایی فروخته میشه یه شهریه ای که دریافت میشه یک کار مالیه.فیلد NoeTarakonesh در جدول Mali مشخص میکنه که این کار مالی شهریه هست ، فروش است یا جریمه یا حقوق کارکنان و دبیرانه یا......
مبلغ برای شهریه و فروش اجناس رو میشه با استفاده از جدولهای Sale_Course و Sale_Kala بدست آورد.ولی فیلد Mablagh رو برای این قرار دادم تا اگر کاربرم خواست کاری جز دریافت شهریه و فروش اجناس انجام بده بتونه مبلغ کل رو محاسبه کنه.

2. جدول Vam:
وقتی دانشجو مجموعه ای از کارهای مالی رو انجام میده(مثلا یک دوره ثبت نام میکنه و کتاب میخره) یه مبلغی رو به آموزشگاه بدهکار میشه .یه جورایی مثل وام بانکی میمونه.به مین خاطر اسم جدولمو Vam گذاشتم.
خب طبیعتا یه تعداد قسط داره دیگه!!شایدم طرف خواست و تو یه قسط همشو پرداخت کنه.{فیلدی برای پیش پرداخت قرار ندادم.چرا که پیش پرداخت رو میشه قسط اول نامیدو در جدول اقساط ثبت کرد و تعداد اقساط -در جدول وام- رو برابر با 1 قرار داد }

3.جدول Mali_Vam:
این جدول نیازی به توضیح نداره.چرا که ارتباط بین دوجدول Mli و Vam رو مشخص میکنه.
ما مبلغ کل وام رو با استفاده از این جدول ودستیابی به فیلد GhabelePardakht جدول Mali بدست میاریم و باهم جمع میکنیم.

4.جدول Aghsat:
شاید فیلد Sarresid براتون مبهم باشه که این فیلد در واقع مشخص کننده سررسید قسط مورد نظره{البته اگرما درزمان صدور وام به تعداد اقساط رکورد درج کنیم که مثلا قسط فلان در تاریخ x باید پرداخت شه.این همون تاریخه x ه}
NoePardakht هم برای این گذاشتم که مشخص کنه دانشجو قسط مورد نظر رو چطوری پرداخت کرده؟نقدی ، کارت به کارت، چک یا......


از دوستانی که منو راهنمایی میکنن بینهایت متشکرم.
به خصوص veniz2008 (http://barnamenevis.org/member.php?155296-veniz2008)و و دوست خوبم Hajivandian (http://barnamenevis.org/member.php?188317-Hajivandian)

veniz2008
شنبه 01 تیر 1392, 01:23 صبح
من طراحی شما رو یه نگاه اولیه انداختم (با وجود خستگی سعی کردم که تمرکز کنم). مشکلات زیادی رو این طراحی داره.
مهترین اصل اینه که تفکیک درستی انجام نشده.
بعضی جاها بیهوده جدول جدیدی ایجاد شده ( جدول Mali_Vam ).
در جدول اقساط مشخص نیست هر قسط به چه چیزی تعلق داره (آیا خریده یا شهریه یا ...)
اگر کالایی خریداری شده، اون کالاها به چه تعداد هست.
من روی این نکته که هر جدول باید توصیف کننده یک موجودیت یا رابطه باشه تاکید میکنم. جدول مالی نمیشه هم برای شهریه باشه و هم برای خرید. اینجا باید تفکیک میکردید که نکردید.
مبلغ قابل پرداخت فیلد محاسباتی هست. نباید داخل جدول بیاد که باز هم این نکته رو رعایت نکردید.
و ...
قطعا باید طراحیتون رو دگرگون کنید.
این موارد فعلا به ذهنم رسید.

f.beigirad
یک شنبه 02 تیر 1392, 22:32 عصر
با عرض سلام به همه ی دوستان.

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

تصمیم گرفتم یک کتاب نسبتا کامل راجع به این موضوع بخونم.

امروز کتاب "طراحی و پیاده سازی پایگاه داده ها در SQL Server" رو تونستم تهیه کنم.
عنوان اصلیش اینه : "MCSE traning kit Microsoft SQL server 2000 database"
نوشته ی : Sheldon Robert
انتشارات سها دانش
ترجمه شده.

کسی با این کتاب آشنایی داره؟
خوبه؟بده؟
نظری؟

این تاپیک هنوز رها نشده و من بعد از خوندن کتاب مناسب باز هم بروزش میکنم.

veniz2008
دوشنبه 03 تیر 1392, 14:36 عصر
کتاب خیلی خوبه ولی ...
ولی تجربه به نظر من مهتره. در کنار کتاب هایی که مطالعه میکنید حتما باید بصورت عملی هم کار کنید. تا عملی کار نکنید نمیتونید متوجه بشید اون حرف هایی که تو کتاب ها گفته میشه به چه معناست.
مثلا 100 بار نرمال سازی رو بخونید ولی یه دیتابیس رو باهاش پیاده سازی عملی نکنید (یا رو کاغذ یا توی نرم افزار) به هیچ دردی نمیخوره. هر دوی اینها در کنار هم مهمه. حتما از یک طراحی ساده شروع کنید نه از این طراحی که الان داشتید.
اگر یه دوست داشته باشید که در این زمینه وارد باشه خیلی زیاد میتونه موثر باشه. توی همین سایت هم نمونه های خیلی زیادی از تحلیل پروژه های مختلف وجود داره که میتونه بهتون کمک کنه. کافیه جستجو کنید.
موفق باشید.

f.beigirad
پنج شنبه 06 تیر 1392, 22:59 عصر
کتاب خیلی خوبه ولی ...
ولی تجربه به نظر من مهتره. در کنار کتاب هایی که مطالعه میکنید حتما باید بصورت عملی هم کار کنید. تا عملی کار نکنید نمیتونید متوجه بشید اون حرف هایی که تو کتاب ها گفته میشه به چه معناست.
مثلا 100 بار نرمال سازی رو بخونید ولی یه دیتابیس رو باهاش پیاده سازی عملی نکنید (یا رو کاغذ یا توی نرم افزار) به هیچ دردی نمیخوره. هر دوی اینها در کنار هم مهمه. حتما از یک طراحی ساده شروع کنید نه از این طراحی که الان داشتید.


درود بر شما.

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

هنوزم نمیدونم چرا باید خرید های فروشگاهم رو از پرداخت شهریه ها جدا کنم؟
و نمیدونم چرا باید برای هر کدوم اقساط جدا جدا در نظر بگیم؟


بعضی جاها بیهوده جدول جدیدی ایجاد شده ( جدول Mali_Vam ).
در جدول اقساط مشخص نیست هر قسط به چه چیزی تعلق داره (آیا خریده یا شهریه یا ...)
رابطه ی دو جدول Mali و Vam یک به یک نیست که ایجاد جدول Mali_Vam بیهوده باشه!!
چون یک وام میتونه مجموع مبلغ چند تراکنش مالی (Mali) باشه.
من میخوام هزینه ی کل خرید و شهریه و... با هم جمع شن و یک وام رو تشکیل بدن.آیا این کار اشتباهه؟چرا؟


اگر کالایی خریداری شده، اون کالاها به چه تعداد هست.
حرفتوم کاملا درسته.به نظر خودم ، میشه درجدول Sale_Kala این فیلد رو در نظر گرفت.


مبلغ قابل پرداخت فیلد محاسباتی هست. نباید داخل جدول بیاد که باز هم این نکته رو رعایت نکردید.
کلا این جمله رو متوجه نشدم.


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


اگر یه دوست داشته باشید که در این زمینه وارد باشه خیلی زیاد میتونه موثر باشه.
دلیل اضافه کردن امضای شخصی در پایان پست هام همینه.
در آخر اینو بگم که یکی از دوستانم در تحلیل دیتابیس آزمونگیری که نوشتم خیلی کمکم کرد.از ایشون ممنونم.ولی متاسفانه الان خودشون پروژه گرفتن و وقت آزادی برای صحبت نداریم.


ببخشید که طولانی شد.
با آرزوی موفقیت برای شما

veniz2008
جمعه 07 تیر 1392, 00:46 صبح
درود بر شما.

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

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



رابطه ی دو جدول Mali و Vam یک به یک نیست که ایجاد جدول Mali_Vam بیهوده باشه!!
چون یک وام میتونه مجموع مبلغ چند تراکنش مالی (Mali) باشه.
من میخوام هزینه ی کل خرید و شهریه و... با هم جمع شن و یک وام رو تشکیل بدن.آیا این کار اشتباهه؟چرا؟
اینطوری نیست که ما بیایم بین هر دو جدول یک جدول ایجاد کنیم و کلید هر جدول رو داخل این جدول قرار بدیم و بگیم یه رابطه ساختیم. این کار کاملا اشتباهه و هیچ جایی چنین چیزی رو نگفتن. کافی بود فیلد MaliID رو بزاری تو جدول Vam . دیگه نیازی به جدولی به نام Mali_Vam نداری.
مبلغ قابل پرداخت = مبلغ کل - تخفیف
شما باید مبلغ کل و تخفیف رو ذخیره کنید. ذخیره کردن مبلغ قابل پرداخت اشتباه هست به همون دلایلی که قبلا گفتم.
راهی رو که دارید میرید اشتباه هست.
از تحلیل پروژه های کوچیک شروع کنید.
این لقمه برای یک مبتدی بزرگه.
موفق باشید.

f.beigirad
یک شنبه 09 تیر 1392, 14:14 عصر
درود بر شما

ممنون از راهنماییتون.



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

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

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

veniz2008
یک شنبه 09 تیر 1392, 17:10 عصر
درود بر شما

ممنون از راهنماییتون.


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


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

f.beigirad
دوشنبه 10 تیر 1392, 01:08 صبح
با سلام و درود فراوان
با تشکر از توضیحاتتون.



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

:اشتباه:اشتباه از من بوده که نتونستم به کاملا منظورمو برسونم.ببخشید.
دانش آموز الان ثبت نام میکنه و همین الان هم دوتا کتاب میخره.برای اینا ما یک وام تعریف میکنیم.
برای ترم بعد و خرید های بعد هم یک وام دیگر.



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

بابت توضیحات مفیدتون واقعا ممنونم.
به نظرم باید فکر دیگه ای کنم.:متفکر:

f.beigirad
سه شنبه 11 تیر 1392, 00:14 صبح
درود.

خواستم بگم من بیخیال بخش وام ها شدم.نه که همینوجوری بیخیال شم.2*2=4 کردم دیدم نیازی به این کار نیست و کاربرد زیادی در آینده برای این نرم افزار نخواهد داشت.
بخش فروش کالا رو هم از جدول دانشجوها جدا کردم.یعنی فرقی نداره که یه دانشجو چیزی بخره یا یه غریبه.فقط یه فیلد نام مشتری در نظر گرفتم.
بخش شهریه ها رو هم دانشجو میتونه خودش کم کم پرداخت کنه.تاریخی برای سر رسید ها و مبلغ قابل پرداخت قسط نذاشتم.

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


یکم درباره ی جدول هام توضیح میدم:
بخش فروشگاهم رو دو جدول تا حالا تشکیل دادن.
جدول معاملات : کد معامله -کد کاربر - نام مشتری -خرید یا فروش
جدول کالاهای معاماتی : کد-کد معامله-کد کالا - تعداد

به نظر شما من باید تمام کارهای مالی رو تو یه جدول پیاده سازی کنم؟(مثلا هزینه های خرید و فروش و دریافت شهریه رو تو یه جدوای به نام مالی ذخیره کنم.)
یا در انتهای فیلد های جدول کالاهای معامله شده فیلد/هایی برای کارهای محاسباتی بذارم.

لازم به ذکره کد کالا از جداول دبگه ای میاد.

با تشکر

veniz2008
جمعه 14 تیر 1392, 19:09 عصر
درود.

خواستم بگم من بیخیال بخش وام ها شدم.نه که همینوجوری بیخیال شم.2*2=4 کردم دیدم نیازی به این کار نیست و کاربرد زیادی در آینده برای این نرم افزار نخواهد داشت.
از مشکلات نترسید دوست من.
مگه میشه آموزشگاهی بحث قسط بندی شهریه نداشته باشه؟؟؟!! :متعجب:

بخش فروش کالا رو هم از جدول دانشجوها جدا کردم.یعنی فرقی نداره که یه دانشجو چیزی بخره یا یه غریبه.آفرین. داری همکاری میکنی. بالاخره یه حرف ما رو در عمل پذیرفتی :لبخند:

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

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

میخوام برای محاسبات مالیم برای دانشجو ها ابتدا دوره ها رو مرور کنه و هزینه رو براورد کنه بعدش پرداختی هاشو ازش کم کنه.اینو اصلا متوجه نشدم.
چه کسی مرور کنه؟
کامل توضیح بده.


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


به نظر شما من باید تمام کارهای مالی رو تو یه جدول پیاده سازی کنم؟(مثلا هزینه های خرید و فروش و دریافت شهریه رو تو یه جدوای به نام مالی ذخیره کنم.)
یا در انتهای فیلد های جدول کالاهای معامله شده فیلد/هایی برای کارهای محاسباتی بذارم.
تفکیک تفکیک تفکیک.
اینطوری ادامه ندید. حرف گوش بدید و از تجربه دیگران استفاده کنید.
من اگر 1000 تا پست دیگه هم بدم فایده نداره. چراکه این پست ها، از پایه مطالب رو نمیگه. شما باید از پایه شروع کنید و مفاهیم رو یاد بگیرید. یادگیری مفاهیم اولیه وقت زیادی نمیخواد. تمرین کردن اونهاست که نیاز به زمان داره. همونطور که قبلا هم گفتم از تحلیل های ساده و پروژه های کوچیک شروع کنید. پروژه هایی که حدودا 5 تا جدول رو داره . این جداول با هم در ارتباط هستن. این پروژه ای که شما انتخاب کردی حداقل نیاز به 20 تا 25 تا جدول داره. من خودم چند وقت پیش مدیریت آزمون های یک آموزشگاه رو پیاده سازی کردم. 35 تا جدول داره. اینم بگم که 35 تا جدول هیچی نیست ولی برای شروع کار یک مبتدی خیلی زیاد به نظر میاد. اگرمفاهیم رو بر روی پروزه های کوچیک در حد 5 جدول یاد بگیرید،براحتی میتونید اونو بر روی تعداد جداول زیاد هم پیاده سازی کنید. این راهی هست که همه ما طی کردیم.
باید وقت بذارید و پله پله جلو برید.
موفق باشید.

f.beigirad
شنبه 15 تیر 1392, 19:02 عصر
درود


مگه میشه آموزشگاهی بحث قسط بندی شهریه نداشته باشه؟؟؟!! :متعجب:
بله.چرا که قسمتی از مبلغ رو در ابتدای ثبت نام ترم جدید پرداخت خواهد کرد.و الباقی هم تا قبل از ترم بعدی.
اگر بدهکاری داشته باشد حق ثبت نام در ترم بعد را نخواهد داشت.
"من با مدیر آموزشگاه صحبت کردم اینو از من خواست."



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



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



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



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



اینطوری ادامه ندید. حرف گوش بدید و از تجربه دیگران استفاده کنید.
من اگر 1000 تا پست دیگه هم بدم فایده نداره. چراکه این پست ها، از پایه مطالب رو نمیگه. شما باید از پایه شروع کنید و مفاهیم رو یاد بگیرید. یادگیری مفاهیم اولیه وقت زیادی نمیخواد. تمرین کردن اونهاست که نیاز به زمان داره. همونطور که قبلا هم گفتم از تحلیل های ساده و پروژه های کوچیک شروع کنید. پروژه هایی که حدودا 5 تا جدول رو داره . این جداول با هم در ارتباط هستن. این پروژه ای که شما انتخاب کردی حداقل نیاز به 20 تا 25 تا جدول داره. من خودم چند وقت پیش مدیریت آزمون های یک آموزشگاه رو پیاده سازی کردم. 35 تا جدول داره. اینم بگم که 35 تا جدول هیچی نیست ولی برای شروع کار یک مبتدی خیلی زیاد به نظر میاد. اگرمفاهیم رو بر روی پروزه های کوچیک در حد 5 جدول یاد بگیرید،براحتی میتونید اونو بر روی تعداد جداول زیاد هم پیاده سازی کنید. این راهی هست که همه ما طی کردیم.
باید وقت بذارید و پله پله جلو برید.
موفق باشید.

اول از همه بگم که جز شما و آقای حاجیوندیان و من فرد دیگه ای تو این بحث شرکت نمیکنه.(اینم از تجربه دیگران!!)

اینطور که شما میگید نیست.اگر بخوام همه چیزو بگم باید به اندازه چند صفحه A4 بنویسم.(در ضمن امکانشم هست برخی از جاهارو جا بندازم).و هیچکس جز ما 3 تا هیچکس وقتشو بذاره و بخونه و تجربه خودشو در اختیارم بذاره.

نمیدونم چرا شما اصرار دارین روی پروژه های کوچیک.این پروژه خیلی هم بزرگ نیست.پروژه بزرگ یه برنامه حسابداری حرفه ایه.پروژه ای توش با انواع حسابهای تفضیلی و جاری و چک و قرار داد و هزار مفهوم و موجودیت دیگه ارتباط داره.نه این مدیریت آموزشگاه که حتی جدولی برای مشتریان و طرف حساب خاش نداره.نه این برنامه ای که با چک سر و کار نداره.
با 5 جدول کاری نمیشه کرد که بیام و تامیمش بدم و با 35 جدول کار کنم.این پروژه زیاد برزگ نیست.
مشکل من هم همینه که مفهوم و موجودیت و ارتباط رو به طور کامل نمیشناسم و نمیدونم کجا جدول بسازم کجا نسازم.
تو آزمونگیری که نوشتم با 12 جدول کار کردم.مشکلی هم نبود.از کلید خارجی و غیره هم استفاده کردم.با Linq هم کوئری زدم.

ممنونم از پاسخ ناامید کنندتون:ناراحت::ناراحت::نار حت:

veniz2008
شنبه 15 تیر 1392, 20:45 عصر
درود


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


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


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


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


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

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

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

تو آزمونگیری که نوشتم با 12 جدول کار کردم.مشکلی هم نبود.از کلید خارجی و غیره هم استفاده کردم.با Linq هم کوئری زدم.من اون پروژه رو ندیدم و نمیدونم طراحیش به چه صورتی هست ولی در این پروژه چیزی که مشخص هست اینه که شما در طراحیتون اصول کار رو رعایت نمی کنید.

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

f.beigirad
پنج شنبه 20 تیر 1392, 00:32 صبح
با عرض سلام و درود بر شما
با تشکر از صحبتها و راهنمایی های مفید veniz2008 (http://barnamenevis.org/member.php?155296-veniz2008)

با اینکه شما میگید زیاد به راهنمایی هاتون عمل نمیکنم و همش اشتباه میکنم ولی به

توی یادگیری بذارید پوست کلفت و پر رو باشید. میخوام عمل کنم.ببخشید دیگه:لبخند::لبخند::لبخند:


این بخش مالی دیتابیسمه:
///خواهش میکنم Save کنید بعد ببینید.توضیحات فارسی جلوی فیلدها موجود هست///
107011

جداول که مشخصه چی به چین.

سوالات:
1) آیا درسته برای هر کالایی که خریده میشه یا فروخته میشه یک فیلد تخفیف در نظر بگیرم؟
2) اگر به دو جدول خریدها و فروشها توجه کنید متوجه میشوید که دارای Coloumn خای برابری هستند.آیا درسته من این دو جدول رو تلفیق کنم و یک فیلد دیگه اضافه کنم به جدول جدید که بفهمم آیا خریده یا فروش؟
3) استفاده از نوع دیتای money برای مقادیر پولی درسته؟ اصولیش چیه؟

تعداد جدولها زیاد نیست.خواهش میکنم یکم توجه کنید.

ممنونم

Direlap
پنج شنبه 20 تیر 1392, 01:43 صبح
اول از همه بگم که جز شما و آقای حاجیوندیان و من فرد دیگه ای تو این بحث شرکت نمیکنه.(اینم از تجربه دیگران!!)

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


منم خواستم تو این بحث شرکت کنم و با توجه به اینکه خودمم میخوام یه همچین برنامه ای در آینده بنویسم واسم خوبه.
حداقلش اینه که شاید نظر من باعث به وجود اومدن ایده جدیدی بشه. شاید

1) به نظر من کالایی که خریده میشه نیازی به درج تخفیفش نیست. چون نیازی هم نداریم به این فیلد و قیمت ها بیشتر اوقات تغییر میکنن و ثابت نیستن که بخواهیم تخفیف رو هم درج کنیم. برای فیلد کالای فروخته شده هم به نظر من نیازی نیست چون میتونیم توی تنظیمات برنامه این قسمت رو درج کنیم تا هر وقت مدیر خواست این درصد رو تعیین کنه و در فاکتور فروش هم این قسمت مشخص میشه که با تخفیف بوده یا نه. یکی از دلایل هم اینه که مدیر شاید بخواد به طور فصلی تخفیفشو عوض کنه.

3)درسته ولی نمیدونم اصولیه یا نه (به این خاطر میگم چون حتی برای بعضی مواقع شماره تلفن رو از نوع عددی انتخاب نمی کنیم و نوعشو nvarchar میگیریم)

veniz2008
پنج شنبه 20 تیر 1392, 13:08 عصر
سوالات:
1) آیا درسته برای هر کالایی که خریده میشه یا فروخته میشه یک فیلد تخفیف در نظر بگیرم؟
کالایی که امروز فروخته میشه باید درصد تخفیفش هم باهاش ثبت بشه. ممکنه فردا درصد تخفیف همون کالا رو کم یا زیاد کنید. این افزایش یا کاهش ربطی به خرید دیروز نداره. لحظه ای که مشتری خرید میکنه،ملاک اون زمان است. نمیشه روز بعدش بزنید زیرش و بگید درصد تخفیف مثلا کم شده.


2) اگر به دو جدول خریدها و فروشها توجه کنید متوجه میشوید که دارای Coloumn خای برابری هستند.آیا درسته من این دو جدول رو تلفیق کنم و یک فیلد دیگه اضافه کنم به جدول جدید که بفهمم آیا خریده یا فروش؟من اگر کسی چیزی رو ندونه و اشتباه کنه اصلا ناراحت نمیشم ولی اگر مطلبی رو چندین بار توضیح بدم و شخص مقابل توجه نکنه جدا" ناراحت میشم. من هم در این تاپیک و هم در پیام خصوصی به شما گفتم که این دو جدول فیلدهاشون یکسان نیست. وقتی آموزشگاه از یک موئسسه خرید میکنه، باید کد موئسسه رو ثبت کنیم تا بفهمیم خرید از کجا صورت گرفته. شما باز ورداشتی کد مشتری رو گذاشتی توی جدول "خریدهای آموزشگاه Buy" که چی بشه؟.


3) استفاده از نوع دیتای money برای مقادیر پولی درسته؟ اصولیش چیه؟قبلا توی پیغام خصوصی کامل این موارد رو توضیح دادم.
فیلدهای money مناسب برای ما کاربران ایرانی نیست. اگر جمع داده هایی که برای یک فیلد ذخیره میکنید از عدد دو میلیارد و 147 میلیون و ... بیشتر نمیشه از نوع int برای مبلغ استفاده کنید. لینک زیر ظرفیت انواع داده های عددی رو نشون میده :
http://msdn.microsoft.com/en-us/libr...sql.80%29.aspx (http://msdn.microsoft.com/en-us/library/aa933198%28v=sql.80%29.aspx)



1) به نظر من کالایی که خریده میشه نیازی به درج تخفیفش نیست. چون نیازی هم نداریم به این فیلد و قیمت ها بیشتر اوقات تغییر میکنن و ثابت نیستن که بخواهیم تخفیف رو هم درج کنیم. برای فیلد کالای فروخته شده هم به نظر من نیازی نیست چون میتونیم توی تنظیمات برنامه این قسمت رو درج کنیم تا هر وقت مدیر خواست این درصد رو تعیین کنه و در فاکتور فروش هم این قسمت مشخص میشه که با تخفیف بوده یا نه. یکی از دلایل هم اینه که مدیر شاید بخواد به طور فصلی تخفیفشو عوض کنه.
همونطور که گفتم باید درصد تخفیف همراه کالای خریداری شده ثبت بشه. اتفاقا بخاطر همین تغییرات احتمالی، باید درصد تخفیف ثبت بشه وگرنه اگر 100% مطمئن بودیم که قیمت تخفیف تغییر نمیکنه دیگه نیازی به درج کردنش نبود و موقع حساب از جدول مقدار تخفیف رو میخوندیم.


3)درسته ولی نمیدونم اصولیه یا نه (به این خاطر میگم چون حتی برای بعضی مواقع شماره تلفن رو از نوع عددی انتخاب نمی کنیم و نوعشو nvarchar میگیریم) در مورد نوع داده برای شماره تلفن و کد ملی ما از میتونیم از نوع های char، varchar و nvarchar استفاده کنیم و از نوع int و کلا نوع های عددی استفاده نمیکنیم چراکه در ابتدای شماره تلفن ها 0 وجود داره که نوع های عددی نمیتونن این 0 ابتدایی رو ذخیره کنن ( 0 ابتدایی فاقد ارزش مکانی هست). دلیل اینکه نوع char رو هم آوردم بخاطر این هست که طول تمامی شماره تلفن ها با احتساب پیش شماره (چه همراه و چه تلفن ثابت) 11 کاراکتر هست ( (11)char ) و طول تمامی شماره ملی ها 10 کاراکتر هست. ( (10)char ). اما توصیه میکنم برای اعداد از nvarchar استفاده نکنید چراکه نوع داده nvarchar دو برابر نوع داده varchar فضا اشغال میکنه. فقط برای داده هایی که مقادیر فارسی دارند از nvarchar استفاده کنید. پس برای تلفن و کد ملی از char یا varchar استفاده کنید. من خودم همیشه از varchar استفاده میکنم.
در پایان یک نکته رو هم بگم: برای توضیحات Description که در جدول cost استفاده کردید نوع داده رو nchar نگیرید. چون ما نمیدونیم طول توضیحات چند کاراکتر هست. ممکنه 100 کاراکتر باشه ممکنه 700 کاراکتر. وقتی (500 )nchar میگیرید یعنی به اندازه 500 بایت حتما فضال اشغال میشه. حالا sql کاری نداره شما 100 کاراکتر فرستادی یا 500 کاراکتر. تمام فضایی رو که در نظر گرفتید (500 بایت) رو اشغال میکنه که این اصلا بهینه نیست. پس در چنین حالاتی که طول رشته ارسالی از قبل مشخص نیست حتما از خانواده varchar ها استفاده کنید که در اینجا چون نوع داده ارسالی فارسی هست بایستی از نوع nvarchar کمک بگیرید. برای توضیحات اگر فکر میکنید که توضیحات ممکنه زیاد باشه از nvarchar(max استفاده کنید. خوبی نوع های varchar و nvarchar اینه که دقیقا به همون اندازه ارسال شده فضا اشغال میشه. درسته nvarchar(max در نظر گرفتید ولی اگر 100 کاراکتر بفرستید دقیقا به همون میزان فضا اشغال میشه و بیهوده فضای اضافی در نظر گرفته نمیشه.
توی پیام خصوصی هم خدمتتون عرض کردم اینجا هم بازم اینو میگم:
تاکید میکنم که این راهی که میرید اشتباه هست. من بیشتر از این دیگه ادامه نمیدم چون مطمئنم این راه هیچ سودی برای شما نداره.
شما فقط میخواید هرطوری شده این پروژه رو بنویسید. ولی به چه قیمتی؟
شما قراره با مباحث مالی سر کار داشته باشید. قبلا هم گفتم وقتی پول میاد وسط هم باید خوشحال بود(درآمد زایی) و هم نگران. مباحث مالی شوخی نیست. یه 0 جابه جا بشه پدر آدم در میاد. باید اول خوب تحلیل کردن و طراحی اصولی کردن رو یاد بگیریم و بعدش سراغ چنین پروژه هایی بریم.
اگه یه نرم افزار تحویل مشتری بدید که سیستم مالیش درست کار نکنه، میدونید چه اتفاقی می افته؟
برنامه نوشتن فقط کد زدن نیست.
برنامه نوشتن فقط کار با LINQ نیست.
قدم اول و مهمترین قدم، تحلیل و طراحی صحیح هست. اینم چیزی نیست که آدم یه شبه یا 1 هفته ای یاد بگیره. به مرور زمان و در طی پروژه های مختلف، عیب های خودمون رو در زمینه تحلیل پیدا و رفع میکنیم.
بین "توی یادگیری بذارید پوست کلفت و پر رو باشید" و "لجاجت" تفاوت هست دوست عزیز.
با پشتکار زیاد اول مفاهیم و اصول اولیه رو یاد بگیرید و بعدش سراغ نوشتن چنین برنامه هایی برید.
موفق باشید.

f.beigirad
پنج شنبه 20 تیر 1392, 14:36 عصر
با سلام و درود بر شما دوستان.

از شما veniz2008 (http://barnamenevis.org/member.php?155296-veniz2008)هم بسیار متشکرم و هم عذر میخوام که ناراحتتون کردم.

حقیقتا به نظر خودم این پروژه از نظر مالی زیاد سطح بالا نیست.پروژه ی کوچک تری پیدا نکردم که با مباحث مالی سر و کار داشته باشه و من بتونم با موجودیت های کمتری کارهای مالی انجام بدم.

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


من اگر کسی چیزی رو ندونه و اشتباه کنه اصلا ناراحت نمیشم ولی اگر مطلبی رو چندین بار توضیح بدم و شخص مقابل توجه نکنه جدا" ناراحت میشم. من هم در این تاپیک و هم در پیام خصوصی به شما گفتم که این دو جدول فیلدهاشون یکسان نیست. وقتی آموزشگاه از یک موئسسه خرید میکنه، باید کد موئسسه رو ثبت کنیم تا بفهمیم خرید از کجا صورت گرفته. شما باز ورداشتی کد مشتری رو گذاشتی توی جدول "خریدهای آموزشگاه Buy" که چی بشه؟.من بازم عذر خواهی میکنم.
من فرق بین موسسه و مشتری هایی که از آموزشگاه خرید میکنند رو نمیدونم(از نظر ویژگی هاشون).
من هر دوی این هارو در جدول Customers ذخیره میکنم.
جدول Customers هم برای موسساتی هستن که ازشون کالا میخریم و هم برای اشخاصی هستند که بهشون کالا میفروشیم.
فیلدهای این جدول هم عبارت اند از CustomerID , CustomerName , RegisterDate .

به هیچ وجه آدم لج بازی نیستم و سوالاتی که میپرسم از روی ندونستنه.نه لج بازی و غیره.


فیلدهای money مناسب برای ما کاربران ایرانی نیست. اگر جمع داده هایی که برای یک فیلد ذخیره میکنید از عدد دو میلیارد و 147 میلیون و ... بیشتر نمیشه از نوع int برای مبلغ استفاده کنید.

ببخشید دوباره سوالمو تکرار کردم.الان فهمیدم چرا برای ما کاربران ایرانی نیست.



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

veniz2008
پنج شنبه 20 تیر 1392, 18:53 عصر
حقیقتا به نظر خودم این پروژه از نظر مالی زیاد سطح بالا نیست.پروژه ی کوچک تری پیدا نکردم که با مباحث مالی سر و کار داشته باشه و من بتونم با موجودیت های کمتری کارهای مالی انجام بدم.
مفهوم سختی یک مفهوم نسبی هست. برای یک نفر، اولین بار یک برنامه ساده تک جدولی رو مینویسه میگه برنامه سختی بود و یکی دیگه به یک برنامه 60 جدولی میگه پیچیده. به قول انیشتن :
" اگر برای 2 ساعت با یک دختر زیبا در پارک بنشینیم به نظر می‌رسد که 2 دقیقه گذشته، ولی اگر برای 2 دقیقه بر روی بخاری بنشینیم به نظر می‌رسد که 2 ساعت می‌گذرد. این نسبیت است!".

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


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

f.beigirad
پنج شنبه 20 تیر 1392, 23:21 عصر
با عرض سلام و درود فراوان بر شما دوستان


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

پس بهم کمک کنید تا کم کم جدا سازی و تفکیک رو یاد بگیرم.
این هم به چشم.جداول موسسات و مشتری هامو جدا میکنم.

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


با تشکر