نقل قول: گزارش سازی در جاوا
کسی نیست یه راهنمایی کنه؟؟:متعجب::ناراحت::گریه:
نقل قول: گزارش سازی در جاوا
به نظرم آره باید دوباره همشون محاسبه بشن. چون شما viewتون رو شرطی بر اساس تاریخ خاصی ساختید. اگر اینطور نبود و همه تاریخ ها در اون view وجود داشته باشه خب فقط یک select میشه.
اما به نظرم اینجا درست نیست از view استفاده کنید اگر لازمه برای select هربار view آپدیت بشه. اگر view جوری بود که فقط برای insert/delete/update نیاز به آپدیت داشت و همچنین این عملیات ها تعدادشون به نسبت کم باشه و select باعث تغییر view نشه به نظرم خوبه. ولی اینجا نه. چون view ساختن هم خودش هزینه بره به هر حال.
به نظرم یا بد جدولتون رو طراحی کردید و خیلی اطلاعات رو از هم جدا کردید و هزینه join رو بالا بردید، یا هم اگر راه دیگه ای نیست باید سعی کنید یکم selectهاتون محدود کننده تر باشه. اول هم از جایی شروع کنید که خروجی select کمترین تعداد رو داشته باشه. البته خود دیتابیس ها اکثرا یکسری بهینه سازی دارن و حدس میزنن خروجی چه selectهایی کمتره و اگر بشه اونا رو زودتر انجام میدن.
نقل قول: گزارش سازی در جاوا
نقل قول:
نوشته شده توسط
vahid-p
به نظرم آره باید دوباره همشون محاسبه بشن. چون شما viewتون رو شرطی بر اساس تاریخ خاصی ساختید. اگر اینطور نبود و همه تاریخ ها در اون view وجود داشته باشه خب فقط یک select میشه.
اما به نظرم اینجا درست نیست از view استفاده کنید اگر لازمه برای select هربار view آپدیت بشه. اگر view جوری بود که فقط برای insert/delete/update نیاز به آپدیت داشت و همچنین این عملیات ها تعدادشون به نسبت کم باشه و select باعث تغییر view نشه به نظرم خوبه. ولی اینجا نه. چون view ساختن هم خودش هزینه بره به هر حال.
به نظرم یا بد جدولتون رو طراحی کردید و خیلی اطلاعات رو از هم جدا کردید و هزینه join رو بالا بردید، یا هم اگر راه دیگه ای نیست باید سعی کنید یکم selectهاتون محدود کننده تر باشه. اول هم از جایی شروع کنید که خروجی select کمترین تعداد رو داشته باشه. البته خود دیتابیس ها اکثرا یکسری بهینه سازی دارن و حدس میزنن خروجی چه selectهایی کمتره و اگر بشه اونا رو زودتر انجام میدن.
ممنون از جوابت ولی کامل متوجه نشدم
ببین من چند تا فرم دارم یکی دستمزدا ثبت میشه یکی مواد اولیه قیمتاش ثبت میشه یکی سربارها یکی ضایعات یکی مواد اولیه ای که هر محصول رو میسازه و ....
یعنی فرم ها و تیبل ها جوریه که نمیشه یکی باشه هیچ جوری
در نتیجه تعداد تیبل هام خیلی زیاد شده تقریبا 30 تا تیبل هستش که از هم جدا هستن ولی برای ساختن گزارش نهایی به 90% تیبل ها نیاز هست یعنی از ترکیسب این تیبل ها هستش که میشه قیمت نهایی رو به دست آورد خواستم سلکت های تو در تو بنویسم ولی خیلی خیلی طولانی و زیاد میشد و احتمال اینکه توش اشتباه پیش بیاد زیاد میشد یعنی برای کمتر از نصف این تیبل ها و ادقامشون بیشتر از 70 سطر کد فقط سلکت شد
در نتیجه از ویو استفاده کردم از اونجا که تازه کارم و اولین باره دارم با دیتا بیس اون هم در این حجم و اندازه کار میکنم گفتم بچرسم شاید راه بهتری وجود داشته باشه و شاید اصلا کاری که انجام دادم اشتباه باشه چون همین الانش هم تقریبا 10 تا ویو شده تا یه خروجی کامل به دست اومده
اگه راه بهتری هست لطفا فقط اسمشو هم بگید کافیه میرم سرچ میکنم با اون راه عملیات رو انجام میدیم:قلب:
نقل قول: گزارش سازی در جاوا
نه گفتم که راه دیگه ای به نظر نمیاد با این اوصاف NoSQL هم برای کارتون مناسب به نظر نمیاد که بخوام پیشنهاد بدم. فقط به نظرم لازم نیست همش رو تو یه کوئری بنویسید و بشه بخش های مختلفش رو جدا کرد و بعضی قسمت هاش رو وارد کدهاتون بکنید و به هم مرتبطش کنید به جای اینکه همش رو به دیتابیس بسپارید.
اما باز بهتره در انجمن دیتابیس هم مطرح کنید که بیشتر با این مسائل درگیر هستن، من راه بهتری به ذهنم نمیرسه.
نقل قول: گزارش سازی در جاوا
نقل قول:
یعنی من باید توی برنامم کدی بنویسم که هر بار کاربر تاریخ رو تغییر میده این view های که توشون تاریخ هست همشون آپدیت بشه؟( مثلا 10 تا view همزمان آپدیت بشه بعد select بخوره تا گزارش بدست بیاد؟ )
منظورتون چی ؟
وقتی view را یکبار ایجاد میکنید برای همیشه کامپایل میشه و وقتی اطلاعات روی جداول به روز میشوند در فرم های برنامه نیازی به آپدیت View نیست شما ویو را که اجرا کنید آخرین اطلاعات برای شما بر میگردونه تازه سربار کمتری نسبت به اجرای مستقیم Select داره حتی می تونید به ویوها تون هم شرط هم ارسال کنید که مثلا تاریخ های مورد نظر برای شما واکشی کنه و البته تلفیق Routines ها که البته در MySql به این نام هست در SqlServer به نام Stroed Procedure , User Define Function شناخته میشند با View ها به شدت Performance بالایی برای شما داره معمولا خیلی بهتره که از Select های مستقیم کمتر استفاده بشه .
نقل قول:
این تیبل ها و ادقامشون بیشتر از 70 سطر کد فقط سلکت شد
چون مطمن باشید که وقتی Query Cost Plan با ابزارهای Query Analyzer برای این کوئری 70 خطی بگیرید جواب مفیدی راجع به Performance بهتون نمیده
به هرحال شما باید اول کوئری هایی که دارید به بخش های مختلف تقسیم کنید و در ویو های مختلف پیاده سازی کنید وبعد با استفاده از روتین ها از اونها استفاده کنید.
و اینکه شما در طراجی دیتابیس چقدر از Normalize استفاده کردید وچقدر از deNormalize چیزی نیست که بدون مشاهده دیتابیس متوجه شد.
ولی حدس من این هست که همونطور که دوست عزیز مونم در پست بالا اشاره کرد بیش از حد درگیر نرمال سازی شدید که اینهم اصلا خوب نیست نرمال سازی توام با دی نرمال کردن جداول در برخی مواقع خیلی بهتر جواب میده. اگر بخوام ساده تر بگم منظورم این هست تو برخی جداول اطلاعات تکراری داشته باشید خیلی بهتر از این هست که دیتابیس هزار تکه بشه!!!!
البته ما در SQL Server و یا Oracal راهکارهایی هم داریم که با اینطور نرمال سازی ها هم بتونیم بازدهی بالاتری داشته باشیم ولی خوب در MY-SQL خیلی از این تکنیکها را نداریم.
البته استفاده از ایندکس های مناسب و Relation Ship های معقول منطقی در کنار View ها و صدالبته روتین ها خیلی روی بازدهی پایگاه داده تاثیر داره.
