Wpis z mikrobloga

@wanar: jest to plik, który wykonuje obliczenia "forecastu", czyli przewiduje zapotrzebowanie na części w przyszłości na podstawie popytu przez ostatnie trzy lata. Aproksymuje to funkcją liniową oraz kwadratową, nakłada na to sezonowość i wypluwa wartości na najbliższe trzy miesiące.

Mniej więcej to działa tak, że podajesz numer części, on pobiera z bazy danych historię zamówień, ilość materiału w magazynach i złożone zamówienia, łączy to w całość, biorąc pod uwagę też dodatkowe
@DarkAlchemy: Prognozowanie to gruby temat i przełożenie tego na SQLa łatwe nie będzie, masa zabawy z odwzorowaniem funkcji z excela. A gdyby zamiast robić to bezpośrednio na SQLu, działać dalej na excelu, ale użyć makra w vba do zaciągania automatycznie danych z bazy?
Bo podejrzewam ze działa to obecnie mniej więcej tak, że w arkuszu masz zapisane formuły i ręcznie klepiesz odpowiednie dane z bazy do odpowiednich pól żeby wyliczyć prognozę?
@wanar: dane są zaciągane z bazy automatycznie, jedyna ingerencja użytkownika to podanie numeru części. Zaimplementowałem nawet funkcjonalność automatycznego pobrania z bazy listy numerów, liczenia i wrzucenia najważniejszych obliczeń na serwer, ale niektóre części potrafią się liczyć nawet 10 minut, więc jakby komuś zależało na szczegółach i chciał to ponownie przeliczyć to jest to masa czasu. Sam nie wiem czy przepisanie tego do SQL by przyspieszyło obliczenia, ale na pewno łatwiej byłoby
@DarkAlchemy: Generalne podejście do tego typu tematów jest takie, że wyniki oblicza się w nocy/w kolejce, a po obliczeniu zachowuje się je w bazie, żeby użytkownik miał do tych informacji szybki dostęp. Myślałeś o użyciu Pythona - to jest język wręcz stworzony do tego typu zadań?

A 10 minut wykonywania się skryptu wydaje się być dość mocno niezoptymalizowane. Może powinieneś poszukać wąskich gardeł w algorytmie.
@MarcusPlinius: Właśnie taki jest zamysł, puszczenia tego w nocy, a potem tylko użytkownik ma dostęp do zapisanych wyników w bazie.

Nie wiem, ogólnie chodzi o to, że jedna część liczy się ok. 1-2 s, z czego większość czasu zabiera pobranie danych z bazy. Jednak w jednej części może być ich tak naprawdę nawet 500, i wtedy czas się wydłuża do tych 10 minut, bo każda musi być przeliczona osobno i dopiero
@DarkAlchemy: Możesz to gdzieś wrzucić (np. na priv), żebym mógł na to zerknąć? Bo ilości rzędu 500-1000 to dla baz danych śmieszne ilości. Przy milionach można by się zastanawiać nad czasem rzędu kilku sekund, ale nie przy setkach i na pewno nie w minutach. Nie robisz przypadkiem czegoś w pętli i nie umieściłeś w niej czegoś co jest czasochłonne, a mogło być poza nią?
@MarcusPlinius: Nie wiem czy mogę podrzucić, bo to jednak firmowy plik i nie ja tworzyłem wszystko ;)
Mnie się wydaje, że przy tych setkach głównym problemem, poza czasem pobrania z bazy, który jednak jakimś ułamkiem sekundy jest (a każda część pobiera ok. 7-8 tabel, oczywiście wszystko na jednym połączeniu tworzonym na początku), to ociężałość samego Excela i jego obliczeń oraz sposobu prezentacji danych, który często opiera się na kopiowaniu zawartości komórek
@DarkAlchemy: Ok, jasne. To Ci mogę powiedzieć tyle - migracja tego do bazy (np. mysql) i zrobienie obliczeń albo kwerendami, albo Pythonem powinno Ci skrócić czas obliczeń do góra kilku sekund. W Pythonie robiłem jakiś czas temu narzędzie dla siebie, które wykonywało transformacje i obliczenia dla ok. 2 mln wierszy wczytywanych z pliku tekstowego i zajmowało to mniej niż sekundę. Do tych poziomów powinieneś dążyć.