PDA

View Full Version : سوال: میشه بانک رو جوری طراحی کرد که تغییرات رو نگه داره؟ ایده م اصولیه؟(با برنامه نویسی یا طراحی بانک؟)



sahel65
پنج شنبه 03 مرداد 1392, 13:33 عصر
سلام عزیزان؛ وقتتون بخیر؛
یک سوال داشتم؛
ببینید من میخوام یک برنامه بانک اطلاعات افراد شاغل در یک سازمان کوچیک بنویسم.
برای مرحله اول میخوام جدول اطلاعات ثابت رو از اطلاعات حقوقی جدا کنم، که فکر کنم بهتر باشه.
برای این مرحله ازتون سوال داشتم.
بانک رو به چه نحوی طراحیش کنم که اگه فردی مثلا آدرسش عوض شد، آدرس قبلی رو هم داشته باشم؛ (البته بدون اینکه شخصی که با برنامه کار میکنه از این موضوع اطلاع داشته باشه یا اصلا دونستن این موضوع ممکنه بدردش نخوره! جهت اطلاع خودم میخوام بدونم) و اینکه در پایان سال ببینم یه نفر چه تغییراتی داشته؟
همچنین برای اینکه تعداد تغییرات برای یه شخص ثبت بشه؛ یه فیلد درست کنم و هر وقت فیلد دیگه ای دچار تغییر یا همون Update شد به Counter اون اضافه کنم؟
در این زمینه چه راه حلی دارین؟ چطوری انجامش بدم که هم تغییرات ذخیره بشه و هم اطلاعات قبل از تغییر یک شخص.

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

csharpprogramer88
پنج شنبه 03 مرداد 1392, 16:03 عصر
این سوال منم هست مثلا توی جدول حقوقی اگه در یکسال سه دفعه حقوق کارگران تغییر کنه چطوری باید ثبتش کنیم؟ که اطلاعات قبلی هم حفظ بشه؟

samadblaj
پنج شنبه 03 مرداد 1392, 16:10 عصر
سلام باید برای برنامه تون امکان event گذاری رو ایجاد کنید این مورد رو بررسی کیند به نتیجه مورد نظر میرسید.
هیچ تغییر در ازلاعات از چشم شما دور نمیماند./

veniz2008
پنج شنبه 03 مرداد 1392, 16:20 عصر
بانک رو به چه نحوی طراحیش کنم که اگه فردی مثلا آدرسش عوض شد، آدرس قبلی رو هم داشته باشمسلام.
میتونید به اینصورت عمل کنید. فرض کنید میخواید برای محل زندگی یک شخص که ممکنه چندین بار تغییر کنه این کار رو انجام بدید :
در جدولی که اطلاعات ثابت ثبت میشه آخرین محل زندگی رو ثبت کنید ولی یک جدول دیگه هم ایجاد کنید شامل کلید (identity) ، نام کاربری و آدرس. در این جدول آدرس قدیمی اشخاص رو ذخیره کنید. یعنی شخصی که فقط یک آدرس داره در این جدول هیچ رکوردی براش ثبت نمیشه ولی اگر شخصی ادرسش تغییر پیدا کرد، ابتدا آدرس فعلیش رو درون این جدول ذخیره میکنید و بعد با یک دستور update ، در همون جدول اطلاعات ثابت، آدرس جدید رو بروزرسانی میکنید. نیازی هم به فیلد counter ندارید، کافیه در جدول دوم یک
select Count(UserName) from TblAddress where UserName = @UserName بزنید، عدد برگشت داده شده تعداد تغییرات رو نشون میده. برای فیلدهای دیگه هم میشه به همین صورت یک جدول دیگه ایجاد کرد. چون احتمالش کمه که این جداول در عمل استفاده بشه، بنابراین نباید نگران هزینه join بین جداول بود، مگر اینکه در عمل کاربرد این جداول فرعی واقعا زیاد باشه که گفته های شما این مطلب رو نشون نمیده.
موفق باشید.

Hkarimi
پنج شنبه 03 مرداد 1392, 16:29 عصر
سلام.

والا من با روش Event گذاری آشنا نیستم. جریانش چیه؟ لینک به درد بخوری هس بذارید تا یاد بگیرم...

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

roolinjax
پنج شنبه 03 مرداد 1392, 19:30 عصر
سلام
به نظر من بهترین کار اینه که یه کپی از دیتابیس تون رو با نام "دیتابیس تغییرات" کنار پروژه تون داشته باشید
و توی هر جدول از بانکتون در "دیتابیس تغییرات" سه تا فیلد اضافه کنید : 1- تاریخ بازنگری 2- عمل صورت گرفته (حذف یا ویرایش) 3- فیلد تغییر یافته
با این عمل اولا روی همه فیلدهای جداولتون میتونید این کارو انجام بدید ، درثانی تاریخ و ساعت تغییرات رو می تونید داشته باشید ، از طرفی هم برای ویرایش و هم برای حذف می تونید این به اصطلاح لاگ فایل رو داشته باشید و هم اینکه فیلد تغییر یافته رو هم درج می کنید که مطالعه ی لاگ فایل راحت تر بشه
فیلدهای دیگه هم میشه اضافه کرد مثلا فیلد علت تغییر یا فیلد توضیحات که خوب بسته به اینکه چقدر میخواید این عمل با کیفیت انجام بشه میتونه اضافه بشه (برای هوشمندی بیشتر برنامه تون)

hojjatshariffam
پنج شنبه 03 مرداد 1392, 20:09 عصر
نمی دونم اصولی هست ولی این کارم می تونید بکنید
یه فیلد برای بی اعتبار کردن ردیف بزاری که بشه اون ردیف رو بی اعتبار کر مثلا حذف
بعد برای تغییرات یه ردیف جدید ایجاد کنید که اطلاعات ویرایش شده تو اون باشه
می تونی علت ویرایش رو هم یه فیلد دیگه در نظر بگیرید
موقع نمایش اونهایی که فیلد تغییرات براشون ثبت شده رو نمایش ندید در این صورت هر بار ویرایش کنید ردیف حذف نمی شه فقط فلگ حذف یا ویرایش براش ثبت میشه

sahel65
پنج شنبه 03 مرداد 1392, 21:17 عصر
دوستان عزیزم، از همه تون ممنونم که به سوالم اینقدر خوب جواب دادین.
ولی فکر کنم پاسخ دوست عزیزمون Veniz2008 کارآیی بهتر و استاندارتری داره. فقط آقا Veniz من هر دو تا جدول رو طراحیش می کنم؛ اگه امکانش هست بعدش بازم راهنماییم کنید که جدول رو از همین ابتدا بصورت بهینه و خوب درستش کنم. ممنونم از لطف و زحمات شما.

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

توی هر جدول از بانکتون در "دیتابیس تغییرات" سه تا فیلد اضافه کنید : 1- تاریخ بازنگری 2- عمل صورت گرفته (حذف یا ویرایش) 3- فیلد تغییر یافته
با این عمل اولا روی همه فیلدهای جداولتون میتونید این کارو انجام بدید ، درثانی تاریخ و ساعت تغییرات رو می تونید داشته باشید ، از طرفی هم برای ویرایش و هم برای حذف می تونید این به اصطلاح لاگ فایل رو داشته باشید و هم اینکه فیلد تغییر یافته رو هم درج می کنید که مطالعه ی لاگ فایل راحت تر بشه
ممنونم؛ ولی میشه یه مقدار بیشتر باز کنید مسئله رو ؟ یعنی من دقیقا یه جدول دیگه با همون اطلاعات داشته باشم و اسمش رو بذارم مثلا changes و تو این فیلدهای مورد نظر شما رو اضافه کنم؟خب اینجوری اگه جدول اصلی دچار تغییرات شد ؛ هر تغییر رو تو این بانک هم ذخیره کنم؟ روی فیلد قبلی؟

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

باید برای برنامه تون امکان event گذاری رو ایجاد کنید این مورد رو بررسی کیند به نتیجه مورد نظر میرسید.
ممنونم از شما ؛ چشم تحقیق می کنم؛ ولی امکانش هست شما هم یه مقدار بیشتر توضیح بدید؟

hojjatshariffam
پنج شنبه 03 مرداد 1392, 23:18 عصر
ممنونم ازت که راهنماییم کردی و وقتت رو برام صرف کردی ؛ ولی به نظر شما آیا با این کار به اصطلاح دچار افزونگی و به نوعی زیاد شدن سطرهای یک جدول نمیشیم؟ حالا درسته کل اطلاعاتی که من میخوام ثبت کنم کمتر از 400 نفر هستن ولی به نظرتون اصولی هستش؟

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

roolinjax
جمعه 04 مرداد 1392, 18:23 عصر
ممنونم؛ ولی میشه یه مقدار بیشتر باز کنید مسئله رو ؟ یعنی من دقیقا یه جدول دیگه با همون اطلاعات داشته باشم و اسمش رو بذارم مثلا changes و تو این فیلدهای مورد نظر شما رو اضافه کنم؟خب اینجوری اگه جدول اصلی دچار تغییرات شد ؛ هر تغییر رو تو این بانک هم ذخیره کنم؟ روی فیلد قبلی؟
بله دقیقا درست فهمیدید ، نظر من اینه که یا یه کار نباید انجام بشه یا باید با کیفیت انجام بشه
وقتی شما دارید یه همچین کاری رو انجام میدید بهتره این عمل روی همه ی فیلدهای شما صورت بگیره
از طرفی توضیحات مربوط به تغییرات اونقدری کامل باشه که با مطالعه ی این لاگ فایل (فایل ثبت وقایع) همه چیز رو بشه فهمید.
فیلد تاریخ بازنگری کمک می کنه که ترتیب تغییرات رو متوجه بشید (به قول خودتون اول تهران بعد اصفهان و بعد مشهد)
تغییرات شما میتونه حذف یا ویرایش باشه که باز نیاز به فیلد بعدی حس میشه که نوع عمل رو در لاگ فایل مشخص کنه
فیلد تغییر یافته هم نشانگر اینه که در اثر این تراکنش یا این تغییر تغییرات روی کدوم فیلد بوده که البته بهتره بهش بگی فیلد توضیحات چون ممکنه در یک ویرایش چندین فیلد دچار تغییر بشن که همگی باید در فیلد توضیحات مشخص بشن.

امیدوارم کامل گفته باشم.

veniz2008
جمعه 04 مرداد 1392, 20:48 عصر
نمی دونم اصولی هست ولی این کارم می تونید بکنید
یه فیلد برای بی اعتبار کردن ردیف بزاری که بشه اون ردیف رو بی اعتبار کر مثلا حذف
بعد برای تغییرات یه ردیف جدید ایجاد کنید که اطلاعات ویرایش شده تو اون باشه
می تونی علت ویرایش رو هم یه فیلد دیگه در نظر بگیرید
موقع نمایش اونهایی که فیلد تغییرات براشون ثبت شده رو نمایش ندید در این صورت هر بار ویرایش کنید ردیف حذف نمی شه فقط فلگ حذف یا ویرایش براش ثبت میشه


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

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

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

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

sahel65
شنبه 05 مرداد 1392, 11:02 صبح
Veniz عزیز ممنونم؛ آره با توجه به توضیحاتی که شما دادید و در واقع با در نظر گرفتن اینکه روش شما کمترین افزونگی و یا تکرار اطلاعات غیر لازم رو داره، پس روش شما بهینه تر از روش سایر دوستان عزیز هست. از سایر دوستان عزیزم مجددا سپاسگزارم.

roolinjax
یک شنبه 06 مرداد 1392, 18:10 عصر
این روش هم بهینه نیست.
1. حجم تقریبا دو برابری دیتابیس.
2. با هر تغییر، انتقال اطلاعات از یک دیتابیس به دیتابیس دیگه
3. مقایسه دیتابیس اصلی با دیتابیس تغییرات
و ...
اصلا بهینه نیست. به فکر داشتن دیتابیس دوم نباشید.
همچنین اگر جدول جداگانه داشته باشه، عمل ویرایش روی همه فیلدها انجام نمیگیره. در فرم اطلاعات، مقدار فعلی فیلدهای هر رکورد گرفته میشه، زمانیکه بر روی دکمه ویرایش کلیک میشه، اول با چند if ساده چک میشه که مقدار کدوم فیلدها تغییر کرده، به ازای هز فیلدی که مقدارش تغییر کرده بود، به جدول مربوطه وصل میشیم و مقدار قبلی رو درونش درج میکنیم. حتی میشه در جدول اصلی هم فقط روی همون فیلد (ها) که تغییر کردن، عمل ویرایش رو انجام داد هر چند ویرایش تمام فیلدهای یک رکورد (با وجود تغییر نداشتن اکثرشون) عمل زمانبری نیست.
در مورد تاریخ هم نیازی نیست. وقتی ما یک فیلد identity داشته باشیم، رکوردها بصورت متوالی ذخیره میشن و رکوردی که اول بیاد معنیش اینه که زودتر ثبت شده و در واقع قدیمی تر هست.
چیزی که توی ذهن منه با چیزی که شما گفتین زمین تا آسمون تفاوت داره
اولا الان سال 2013 هست نه عصر کامپیوترهایی با لامپ خلا که مشکل کمبود فضا وجود داشته باشه
دوما روش من کلی بود و الزاما نیازی به ایجاد باک جدید نیست و میتونی این جداول تو همین دیتابیس ایجاد بشه
سوما مهم کارایی و انعطاف پذیری سیستمیه که طراحی میشه نه اینکه ببینیم برای مثلا یه عمل ویرایش چندتا ثبت باید اتفاق بیفته
چهارما در سیستمی که من توی ذهنم دارم بحث فقط سر این نیست که ترتیب تغییرات به چه صورته که با یه فیلد identity داستان حل بشه ، من حرف از ایجاد لاگ فایل زدم که مسلما وجود فیلد تارخ و زمان رو الزامی میکنه.
در هر صورت تحلیلتون در مورد روش من جای بسی تعجب و شگفت داشت که باعث مسرت کوتاه مدت بنده شد :لبخندساده:

veniz2008
یک شنبه 06 مرداد 1392, 19:48 عصر
چیزی که توی ذهن منه با چیزی که شما گفتین زمین تا آسمون تفاوت داره
اولا الان سال 2013 هست نه عصر کامپیوترهایی با لامپ خلا که مشکل کمبود فضا وجود داشته باشه
دوما روش من کلی بود و الزاما نیازی به ایجاد باک جدید نیست و میتونی این جداول تو همین دیتابیس ایجاد بشه
سوما مهم کارایی و انعطاف پذیری سیستمیه که طراحی میشه نه اینکه ببینیم برای مثلا یه عمل ویرایش چندتا ثبت باید اتفاق بیفته
چهارما در سیستمی که من توی ذهنم دارم بحث فقط سر این نیست که ترتیب تغییرات به چه صورته که با یه فیلد identity داستان حل بشه ، من حرف از ایجاد لاگ فایل زدم که مسلما وجود فیلد تارخ و زمان رو الزامی میکنه.
در هر صورت تحلیلتون در مورد روش من جای بسی تعجب و شگفت داشت که باعث مسرت کوتاه مدت بنده شد :لبخندساده:
بزرگی میگه : "اگر برای یک اشتباه ، 1000 دلیل بیاوریم می شود 1001 اشتباه."
آقای 2013!. بحث بر سر فضا نیست بحث بر سر جستجو بین مثلا 100 هزار رکورد هست یا 200 هزار رکورد. وقتی حجم دیتابیس رو دو برابر میکنی زمان جستجو برای پیدا کردن یک رکورد بیشتر میشه.
در مورد بودن جداول در همون دیتابیس، فرقی وجود نداره. اتصال بین دو جدول مختلف و بررسی داده های اون دو جدول هم زمانگیر هست.
اتفاقا تاکید منم روی کارایی و سرعت هست. روش شما ضد کارایی و سرعت هست. فکر کردی ثبت و حذف و ویرایش کردن اسباب بازی هست؟. عزیزم همه اینا حساب و کتاب داره. اینطور نیست بگی حالا 10 تا آپدیت چه فرقی با یکی آپدیت میکنه یا درج در 10 جدول چه فرقی با درج در 1 جدول میکنه.
از همین روش های کیلویی استفاده میکنید که وضع نرم افزارهای مملکت به این شکل هست.
وقتی میخوای یک موضوعی رو مطرح کنی، کامل توضیح بده تا همه متوجه بشن چی مد نظرت هست تا همه بتونن از نظرات مفیدت استفاده کنن.
امیدوارم مسرتت به جای کوتاه مدت شدن، بلند مدت و متداوم باشه.

fakhravari
یک شنبه 06 مرداد 1392, 19:49 عصر
به هر حال جداولی میخواهید که با تریگر بدون هیچ سختی میتونید نگه دارید.

sahel65
دوشنبه 07 مرداد 1392, 14:07 عصر
Veniz عزیز ؛ حالا بعد از اینکه برای اطلاعات پرسنل این کار رو کردیم برای جداول حقوق چی؟ ممکنه شخصی تو سال 2 بار حقوقش عوض بشه، یکبار بهش سنوات بخوره و یکبار دیگه مثلا مدیر تشخیص بده که ایشون صلاحیت افزایش حقوق رو داره یا اصلا گروهش ارتقا پیدا کنه! بازهم همون سناریو رو بریم جلو؟ یعنی منظورم اینه که اگه تغییراتمون هم زیاد باشن بازم اشکالی نداره؟
آخه دوستمون هم در اینجا پرسیده بود که:

این سوال منم هست مثلا توی جدول حقوقی اگه در یکسال سه دفعه حقوق کارگران تغییر کنه چطوری باید ثبتش کنیم؟ که اطلاعات قبلی هم حفظ بشه؟


ممنونم.

به هر حال جداولی میخواهید که با تریگر بدون هیچ سختی میتونید نگه دارید.
میشه یکم بیشتر یا با مثال توضیح بدید؟ ممنون

veniz2008
دوشنبه 07 مرداد 1392, 18:07 عصر
Veniz عزیز ؛ حالا بعد از اینکه برای اطلاعات پرسنل این کار رو کردیم برای جداول حقوق چی؟ ممکنه شخصی تو سال 2 بار حقوقش عوض بشه، یکبار بهش سنوات بخوره و یکبار دیگه مثلا مدیر تشخیص بده که ایشون صلاحیت افزایش حقوق رو داره یا اصلا گروهش ارتقا پیدا کنه! بازهم همون سناریو رو بریم جلو؟ یعنی منظورم اینه که اگه تغییراتمون هم زیاد باشن بازم اشکالی نداره؟
آخه دوستمون هم در اینجا پرسیده بود که:

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