مزایا و معایب دیتابیس واحد یا مجزا برای دوره های مالی

[shayan_delphi]

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

[AminSobati]

شایان جان واقعیت اینه که داشتن همه این اطلاعات در یک دیتابیس با رعایت فقط چند نکته ساده، همون Performanceی رو میده که در دیتابیسهای مجزا بدست میارید. اما باید از زمان Develop کردن نرم افزار مسائلی رو لحاظ کرده باشید که بتونین همه اطلاعات رو در یک دیتابیس نگهداری کنید. مثلا تقریبا اکثر Queryهای شما باید Where داشته باشه روی فیلد تاریخ. پس اگر بدون این موضوع نرم افزار رو تولید کردین، دیگه الان باید حتما به فکر دیتابیسهای مجزا باشید.
اما فرض کنیم برنامه تازه قرار تولید بشه و ما میتونیم انتخاب کنیم. از طرفی مشکل Performance رو هم میگذاریم کنار چون در هر حال نتیجه کار مطلوب خواهد بود، پس مسائل دیگه رو باید در نظر گرفت.
اگرچه شخصا همیشه طرفدار دیتابیس یکپارچه هستم اما باید اذعان کرد که دیتابیسهای جدا هم خالی از لطف نیستند! مثلا اگر نگران حجم Backup هستین، دیتابیسهای جدا بهتر هستند چون الزاما از همه اونها مرتب Backup نمیگیرین. فرضا اطلاعات سال 83 شاید دیگه Edit نداشته باشه پس Backupی که آخرین بار یکسال پیش ازش گرفتین هنوز معتبره. اما با داشتن دیتابیس یکپارچه همیشه سنگینی اطلاعات سال 83 رو هم در خروجی Backup احساس میکنین! از طرفی به خاطر عدم نیاز به رعایت کردن بعضی نکات در Queryها، اساسا Develop کردن با دیدگاه "دیتابیسهای جدا" راحت تره.
دیتابیس یکپارچه هم مزایای خودش رو داره. اگر شما همیشه باید از همه اطلاعات Backup بگیرین، کنترل یک دیتابیس راحت تر از چند دیتابیس خواهد بود. همچنین در گزارشهای یکپارچه در بین سالهای مالی، این کار با سهولت بیشتری انجام میشه چون در دیتابیسهای مجزا شما باید دائما بین Queryهای مختلف از دیتابیسهای مختلف UNION انجام بدین.
پس بعنوان جمع بندی من معتقدم این کار اساسا یک "سبک سنگین" کردنه! به نیازهای خودتون رجوع کنین و ببینین کدوم حالت انعطاف بیشتری داره.
ضمنا راه سومی هم هست که میتونه ترکیبی از دو راه قبلی باشه: همیشه یک دیتابیس Live یا Current داشته باشید، و کل آرشیو هم یک دیتابیس باشه (نه یک دیتابیس جدا برای هر سال مالی). با داشتن این 2 دیتابیس، راه حلهای جدیدی در رویارویی با مسائل پیش پا قرار میگیره.

[A.Farzin]

یک راه‌کار دیگر هم استفاده از Tableهای مختلف برای سالهای مختلف ولی در یک دیتابیس است.
سئوال شما در ارتباط با سیستم حسابداری به نظر می‌رسد و اگر چنین باشد باید گفت در یک چنین سیستمی جداول متعددی هست که بسیاری از آنها به سال مالی ربطی ندارند. ممکن است برحسب شکل طراحی دو یا سه جدولتان به سال مالی مربوط شود. می‌توان اینگونه جداول را برحسب سال به چند جدول شکست. و نامگذاری آنها را طوری گذاشت که با کد بتوان آنها را تعویض کرد. (مثلا Book85، Book86، Book87).
حسن این کار در افزایش سرعت عملکرد برنامه و اداره راحتتر دیتابانک است.
تنها اشکالی که در این شیوه هست کدنویسی بیشتر برای خواندن و تجمیع اطلاعات از چند جدول است. که اگر گزارشی از اطلاعات 2 سال خواسته شد بتواند تهیه کند.

[AminSobati]

یک راه‌کار دیگر هم استفاده از Tableهای مختلف برای سالهای مختلف ولی در یک دیتابیس است.
تکلیف Queryهایی که یکبار نوشته میشن در SPها چی میشه! نام جداول که جلوی From یا Join قرار میگیرند باید مرتب تغییر کنه؟!

[A.Farzin]

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

[AminSobati]

در SQL Server نیازی به این کار نیست. داشتن یک ایندکس Clustered صحیح روی یک جدول به تمام نیاز شما برای Performance (در آرشیو) جواب میده.

[کیوان معینی]

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

[AminSobati]

بستگی به نیاز داره کیوان جان، شاید یک Indexed View بتونه راه حلی ایده آلی باشه

[SYNDROME]

سلام
برای ذخیره اطلاعات در دوره های(سال)مالی ، استفاده از یک دیتابیس یا چندین دیتابیس چه مزایا و معایبی می تونه داشته باشه؟
مسائلی از قبیل حجیم شدن دیتابیس؟از دست رفتن اطلاعات؟سرعت دسترسی؟و...؟
با سلام
اگر DataBase را جدا بگیرید درست است اطلاعات حجیم نمی شود.
ولی اگر بخواهید گزارش از چند دوره مالی بگیرید سخت می شود.
همانظور که امین گفت شما با رعایت نکات ساده می تواندی آنها را در یکجا ذخیره کنید بدون مشکلی.
ولی کلاً باید با توجه به ظرفیت اطلاعات DataBase را عوض کنید(در بعضی از جاها هر 3 سال و در بعضی از جاها هر 10 سال و . . . )
بستگی به میزان ورود اطلاعات دارد.

[Microsoft.net]

یک راه‌کار دیگر هم استفاده از Tableهای مختلف برای سالهای مختلف ولی در یک دیتابیس است.
سئوال شما در ارتباط با سیستم حسابداری به نظر می‌رسد و اگر چنین باشد باید گفت در یک چنین سیستمی جداول متعددی هست که بسیاری از آنها به سال مالی ربطی ندارند. ممکن است برحسب شکل طراحی دو یا سه جدولتان به سال مالی مربوط شود. می‌توان اینگونه جداول را برحسب سال به چند جدول شکست. و نامگذاری آنها را طوری گذاشت که با کد بتوان آنها را تعویض کرد. (مثلا Book85، Book86، Book87).
حسن این کار در افزایش سرعت عملکرد برنامه و اداره راحتتر دیتابانک است.
تنها اشکالی که در این شیوه هست کدنویسی بیشتر برای خواندن و تجمیع اطلاعات از چند جدول است. که اگر گزارشی از اطلاعات 2 سال خواسته شد بتواند تهیه کند.

این روش آماتور ترین راهی بود که به ذهنم می رسید !! تکلیف Relation ها trigger ها ... چی میشه ؟!! حتما از اینها هم استفاده نکردین با این روش بعد از 5 سال تعداد table های شما 5 برابر میشه !! خیلی جالبه برام بدونم این روش چه جوری به ذهنت رسید ؟!!! واقعا یه خسته نباشید باید بهت بگم...

[Microsoft.net]

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

به این جور کد نویسی میگن برنامه نویسی به سبک اسپاگتی !!!