not optimized for Big queries

[kamioon]

So so good functions and useful but if we have near 200,000 records the operation speed of "where" and "group by" decreased near about 0.001 of normal date.

[zoghal]

درود بر شما بله هنگام گروپ بای این مشکل وجود دارد و راه حلی برایش پیدا نکردیم. البته بهتره بگم وقت روی تست و پیدا کردن راهکار بهتر پیدا نشده. اگر پیشنهادی دارید بگید تا بررسی کنمش شاید بهتر شد.

[kamioon]

سلام بر شما این تک تک روکورد ها فانکشن درگیر تبدیل تاریخ است بنده زیاد اطلاع ندارم در این حوزه اما مثلا برای گروپ راه حلی ندارد که بعد از پایان کوئری انجام شود؟ راه حل دیتابیسی دیگر که فکر کنم مفید خواهد بود این هست که برای یک بازه مثلا ۲۰ ساله کل روزهای شمسی معادل میلادی را وارد دیتابیس کنیم که چیزی حدود ۷۳۰۰ روکورد می شود بعد با جوین و ..متناسب شمسی را پیدا کنیم. این قاعدتا پردازش دارد اما به مراتب بسیار سریعتر از راه حل فعلی است

[zoghal]

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

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

[azerafati]

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