باز هم مسئله سال مالی و عملیات اختتامیه

[nasrin_sf]

میدونم تاپیک تکراریه ولی چون اخرین بحث حدودآ مال 6 ماه پیشه ، فکر کردم بد نیست دوباره

تکرار بشه . search کردم توی آخرین تاپیک آقای ثباتی فرموده بودند:

================================================
ضمنا راه سومی هم هست که میتونه ترکیبی از دو راه قبلی باشه: همیشه یک دیتابیس Live یا Current داشته باشید، و کل آرشیو هم یک دیتابیس باشه (نه یک دیتابیس جدا برای هر سال مالی). با داشتن این 2 دیتابیس، راه حلهای جدیدی در رویارویی با مسائل پیش پا قرار میگیره.

=================================================
مسئله در مورد مزایا و معایب ایجاد دیتا بیس واحد یا مجزا برای سالهای مالی متفاوت هست.

دیتا بیس من فیلد تاریخ یا همان دوره مالی رو داره ، اما میخواستم از این روش سومی که جناب ثباتی گفتن استفاده کنم چون نمیخوام روی تمام کوئری ها دوباره شرط date بگذارم.

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

[SYNDROME]

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

[mhadvi_mahmaood]

در SQl server 2005 میتوانید از پارتیشنیگ استفاده کنید.

[AminSobati]

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

[nasrin_sf]

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

در مورد دیتابیس آرشیو وcurrent که شما مطرح کرده بودین بنظرم جالب بود. ساختار آرشیو همان ساختار current ؟ یا اینکه تلفیقی از جداول خاص که اطلاعات انها به سالهای بعد منتقل میشه رو در این دیتابیس میشه قرارداد( برای هر سال مالی یک جدول در دیتابیس ارشیو) در این صورت مشکل گزارشگیری یکپارچه حل میشه <<احتمالآ!!
برنامه به db current متصله.سالهای قبل از سال جاری رو هم که .MDF و .LDF هاشونو داریم میشه هر بار کاربر سال مالی خاصی رو انتخاب کرد فایلهای دیتا فایل و لاگ فایل مربوطه در دیتابیس جاری قرار بگیرند؟ در سیستمهای تحت شبکه مشکل ایجاد میکنه؟!!!!! بنظر شما راه حل بهتر و صحیحتر کدومه؟در مورد آرشیو و CURRENT توضیح بیشتر بدین حیلی خوب میشه :) ...با توجه به هدف برنامه من و روشی که که گفتم راه درست و سریع کدومه؟
سیستم انبار با VB
BEST REGARDS

[AminSobati]

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

[Microsoft.net]

به نظر من تو سیستم های مالی استفاده از چند دیتابیس و انتقال اونها از یکی به یکی دیگه اشتباه محضه . تمام تغییرات رو باید روی همه دیتابیس ها اجرا کنید . موقع اتصال چندین کانکشن رو باید هندل کنید . convert اطلاعات از یک سال مالی به سال مالی دیگه بسیار وقت گیر میشه . عملیات افتتاحیه و اختتامیه حسابها دردسر ساز میشه . بعضا مجبور میشید چند version مختلف از سورس داشته باشید (یکی مال 85 یکی مال 86 و ...) چون مدام دارید به سیستم امکانات اضافه میکنید . 100% عملیات چک به مشکل بر میخوره چون چکهایی هست که تو سال قبل داده یا گرفته شده و موعد وصولش سال بعده یا ممکنه برگشت یا خرج بشه در سال دیگه و ...
خلاصه کلام اینکه دردسرش اینقدر هست که 1-2 ثانیه تاخیر احتمالی به خاطر سرعت رو نشه تحمل کرد

[SYNDROME]

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

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

[Microsoft.net]

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

دوست عزیز در 99% سیستم های مالی به ازای هر روز کاری یک سند در سیستم ثبت میشود که در بدترین حالت 365 سند در یک سال میشه هر سند هم به طور متوسط از 2 تا 1000 سطر ردیف سند داره که در کارخونه جات و جاهایی که خیلی حسابرسی داردن به ندرت به 200-300 سطر در یک سند میرسه که ما بدترین حالتشو 1000 * 365 گرفیتم که میشه 365000 رکورد در یک سال. کدینگ حسابداری هم که با حساب گروه و کل و معین و تفصیلی و 1 سطح شناور به طور متوسط بیشتر از 1000 رکورد نمیشه و برای تمام سالها ثابته
حالا به نظر شما 366000 رکورد در سال برای بانک قدرتمتند SQL خیلی زیاده ؟ پس اون شرکتهایی که با رکوردهای میلیاردی دارن کار میکنن باید 1 میلیون دیتابیس داشته باشن و 1 میلیون تا سورس کد متفاوت ؟!!

به نظر من همون طور که استاد ثباتی فرمودن اشکال در طراحی بانک و نداشتن تجربه و دانش فنی لازم برای بهینه کردن کویری هاست که باعث شده شما این تعداد رکورد اندک رو که برای SQL خیلی پیش پا افتاده است حجم خیلی زیاد تصور کنید !

[SYNDROME]

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

[mhadvi_mahmaood]

چرا هیچکی به من توجه نمی کنه :(
با پارتیشنینگ مشکل حل نمیشه؟

[SYNDROME]

در SQl server 2005 میتوانید از پارتیشنیگ استفاده کنید.

چرا هیچکی به من توجه نمی کنه :(
با پارتیشنینگ مشکل حل نمیشه؟

بهتر بود کمی توضیح می دادید.
شاید هم SQL دوستمان 2005 نیست.
موفق باشید

[mhadvi_mahmaood]

شاید دومش رو نمی دونم چکار کنم. خلاصه این یک راه حل هستش اگر دیدن که با این کار مشکلشون حل میشه و خیلی کار راحت تره با توجه به شرایط میتونن تصمیم بگیرن که از 2005 استفاده کنند یا نه.
پارتیشتینگ در 2005 این قابلیت رو میده شما داده ها رو بر اساس یک فیلد خاصی دسته بندی کنید. مثلا" روی فیلد تاریخ ما پارتشنینگ میکنیم و میگیم که اطلاعات سال 1386 روی فایل گروپ 1 باشه و اطلاعات قبل از سال 1386 روی فایل گروپ 2 . هنگامی که ما یک جستجوی میکنیم که فقط مربوط به سال 1386 میشه دیگه sqL server با اطلاعات سال 1386 به پایین کاری نداره. اینکار دقیقا" مثل این است که شکه دو دیتا بیس داشته باشید یک برای سال جاری و دیگری برای سال های گذشته. اگر هم که یک کوئری بخواید بگیرید خیلی ساده میتونید روی کل سالها کوئری بگیرید. بدون اینکه بخواید چند دیتابیس رو به هم متصل کنید. تازه چون هنگام کوئری گرفتن اطلاعات از چند پارتیشن خونده میشه اینکار میتونه به صورت پارالل انجام بشه پس سرعت کوئری بالاتر از حالت عادی هم میره.

[nasrin_sf]

دوست عزیز ممنون از توجهتون. ولی sql من 2000 هست

[mhadvi_mahmaood]

به نظر شما این امکان جالب در SQL server 2005 و اینهمه مشکلی که شما با SQL server 2000 داری ارزش مهاجرت به SQl server 2005 رو نداره؟ چیزی به انتشار نهایی SQL server 2008 نمونده اونوقت شما هنوز دارید از SQL 2000 استفاده میکنید؟