Data początku i końca wynajmu. Jak wyliczyć dni wynajmu w miesiącu/roku |
Data początku i końca wynajmu. Jak wyliczyć dni wynajmu w miesiącu/roku |
31.08.2019, 21:12:21
Post
#21
|
|
Grupa: Zarejestrowani Postów: 6 761 Pomógł: 1822 Dołączył: 11.03.2014 Ostrzeżenie: (0%) |
Nie ma sensu robić daty ze stałej daty, po prostu wstaw na sztywno 2013-01-01 bez MAKEDATE, to też Ci sugerowałem.
Starczy Ci do 2040 roku. Przy założeniu, że startowy rok to 2013. -------------------- |
|
|
31.08.2019, 22:21:56
Post
#22
|
|
Grupa: Zarejestrowani Postów: 45 Pomógł: 0 Dołączył: 17.07.2011 Ostrzeżenie: (0%) |
Bo robię coś źle i zapytanie:
zwraca mi pusty wiersz EDIT: Chyba teraz będzie dobrze:
Ten post edytował wachcio 31.08.2019, 22:23:32 |
|
|
31.08.2019, 22:32:02
Post
#23
|
|
Grupa: Zarejestrowani Postów: 6 761 Pomógł: 1822 Dołączył: 11.03.2014 Ostrzeżenie: (0%) |
ORDER BY nie jest potrzebne.
-------------------- |
|
|
1.09.2019, 14:54:50
Post
#24
|
|
Grupa: Zarejestrowani Postów: 45 Pomógł: 0 Dołączył: 17.07.2011 Ostrzeżenie: (0%) |
ORDER BY nie jest potrzebne. To szczegół ale ok dzięki Próbowałem na innej tabeli zrobić również raport. Z założenia miał dodać i pogrupować koszty miesiącami. Ale niestety poległem. Jestem chociaż blisko rozwiązania? DESCRIBE costs; +----------------+-------------+------+-----+-------------------+----------------+ | Field | Type | Null | Key | Default | Extra | +----------------+-------------+------+-----+-------------------+----------------+ | ID | int(11) | NO | PRI | NULL | auto_increment | | category_id | smallint(6) | NO | | NULL | | | entry_owner_id | smallint(6) | NO | | NULL | | | value | smallint(6) | NO | | NULL | | | description | text | YES | | NULL | | | cost_date | date | NO | | NULL | | | date_added | timestamp | NO | | CURRENT_TIMESTAMP | | +----------------+-------------+------+-----+-------------------+----------------+ DESCRIBE cost_categories; +------------+-------------+------+-----+-------------------+----------------+ | Field | Type | Null | Key | Default | Extra | +------------+-------------+------+-----+-------------------+----------------+ | ID | int(11) | NO | PRI | NULL | auto_increment | | owner_id | smallint(6) | NO | | NULL | | | category | tinytext | NO | | NULL | | | date_added | timestamp | NO | | CURRENT_TIMESTAMP | | +------------+-------------+------+-----+-------------------+----------------+ SELECT * FROM costs; +----+-------------+----------------+-------+-------------------------------------------------+------------+---------------------+ | ID | category_id | entry_owner_id | value | description | cost_date | date_added | +----+-------------+----------------+-------+-------------------------------------------------+------------+---------------------+ | 1 | 1 | 2 | 204 | | 2019-08-31 | 2019-08-31 18:50:26 | | 2 | 2 | 2 | 50 | domestos, zmywaki, płyn do mycia naczyń, mopy | 2019-07-30 | 2019-08-31 18:52:08 | | 3 | 3 | 2 | 400 | Naprawa dzrzwi | 2019-08-22 | 2019-08-31 23:44:08 | | 4 | 3 | 2 | 50 | Naprawa łóżka | 2019-08-22 | 2019-08-31 23:44:17 | | 5 | 4 | 2 | 200 | Płytki | 2019-08-22 | 2019-08-31 23:44:46 | | 6 | 1 | 2 | 400 | coś | 2019-07-31 | 2019-08-31 18:50:26 | | 7 | 1 | 2 | 300 | coś | 2019-07-31 | 2019-08-31 18:50:26 | | 8 | 4 | 2 | 400 | cosss | 2019-08-22 | 2019-08-31 23:44:46 | +----+-------------+----------------+-------+-------------------------------------------------+------------+---------------------+
Ten post edytował wachcio 1.09.2019, 14:54:43 |
|
|
1.09.2019, 16:06:10
Post
#25
|
|
Grupa: Zarejestrowani Postów: 95 Pomógł: 7 Dołączył: 27.10.2015 Ostrzeżenie: (0%) |
Czemu na siłę próbujesz to zrobić w MySql? Powiedziałeś że robisz to w Node.js - tam jesteś dobry - to zrób sobie funkcję np: (pseudokod)
która zwróci Ci dane w formie raportu i jednocześnie policzy jak długo to trwało 1) wykonuj zapytania pojedynczo a całą logike sumowania zrób po stronie node.js - zobaczysz jaki będzie czas wykonania. 2) Następnie zmodyfikuj tą funkcję żeby pobierała wszystkie dane potrzebne do raportu jednym zapytaniem select * ... i grupowała tak samo jak w 1) Jeżeli czasy wykonania raportu nie będą zadowalające to wtedy będziesz mógł myśleć o optymalizacji. Ale gwarantuje Ci że nie będzie to potrzebne. |
|
|
1.09.2019, 17:24:09
Post
#26
|
|
Grupa: Zarejestrowani Postów: 45 Pomógł: 0 Dołączył: 17.07.2011 Ostrzeżenie: (0%) |
Dobry to za duże słowo Lepszy niż w MySQL i może masz rację chyba trzeba będzie trudniejsze zapytania rozbijać i obrabiać w node.js
|
|
|
2.09.2019, 20:48:38
Post
#27
|
|
Grupa: Zarejestrowani Postów: 95 Pomógł: 7 Dołączył: 27.10.2015 Ostrzeżenie: (0%) |
Zrobiłem mały teścik jak to będzie wyglądać dla danych:
Jak widać masz tutaj całe lata 2020-2022 wynajęte kod w PHP który nie jest zoptymalizowany (iteruje dzień po dniu) ale pokazuje jak długo taki raport będzie się generował w najgorszym możliwym scenariuszu - czyli konieczność przejścia przez cały rok.
Wynik:
Chyba czas rzędu 0.03 sek. jest wystarczający. Natomiast to samo ćwiczenie w MySQL:
Jaki widać szybciej jest nawet robić to po stronie backendu niż w samym MySQL |
|
|
3.09.2019, 06:59:00
Post
#28
|
|
Grupa: Zarejestrowani Postów: 6 761 Pomógł: 1822 Dołączył: 11.03.2014 Ostrzeżenie: (0%) |
javafxdev, ale chyba nie osiągasz takiego czasu w MySQL na tych danych, które podałeś? Ja u siebie mam 1.1-1.2s dla ok. 65 tys. wierszy.
-------------------- |
|
|
3.09.2019, 21:45:37
Post
#29
|
|
Grupa: Zarejestrowani Postów: 95 Pomógł: 7 Dołączył: 27.10.2015 Ostrzeżenie: (0%) |
Dla dokładnie
Wynik: 6
Tylko zauważ że ja dałem jeszcze e*10000 - bo potrzebuję dla dat od 1970 roku. Ciekawe ile będzie w PHP się liczyło dla 65k wierszy no cóż w PHP:
Po modyfikacji kodu w PHP:
Jak widać samo pobranie 100k wierszy idzie szybko natomiast liczenie przerwałem przy 50k i trwa to już prawie minutę. W samym SQL nie udało mi się doczekać (nie czekałem dłużej niż 3 min). |
|
|
4.09.2019, 08:42:52
Post
#30
|
|
Grupa: Zarejestrowani Postów: 6 761 Pomógł: 1822 Dołączył: 11.03.2014 Ostrzeżenie: (0%) |
Ja przy dodaniu 1000 oraz 10000 do UNION miałem czas 4 minuty 36 sekund (dla 65 tys. rekordów).
Przy samych 1000, 32 sekundy. A przy ograniczeniu ostatniego UNION do 4 (tak aby osiągnąć ok. pełne 10 lat), 11 sekund. Tak więc nie jest tak różowo. Trzeba wybrać optymalne rozwiązanie liczenia. Ewentualnie można liczyć na bieżąco niepoliczone rezerwacje i kumulować wynik w odrębnej tablicy. -------------------- |
|
|
4.09.2019, 09:17:15
Post
#31
|
|
Grupa: Zarejestrowani Postów: 1 834 Pomógł: 225 Dołączył: 20.03.2005 Skąd: Będzin Ostrzeżenie: (0%) |
Ja osobiście uważam, że lepiej na bieżąco rezerwacje uzupełniać w osobnej tabeli np. reservations_calendar i w niej stworzyć pozycje: `dt`(date), `id_house` (int), `booked` (0,1)
Wtedy mamy proste zapytanie:
Ten post edytował Tomplus 4.09.2019, 10:25:16 |
|
|
4.09.2019, 09:29:53
Post
#32
|
|
Grupa: Zarejestrowani Postów: 6 761 Pomógł: 1822 Dołączył: 11.03.2014 Ostrzeżenie: (0%) |
P.S. W formacie jest drobny błąd. Ten post edytował trueblue 4.09.2019, 09:50:02 -------------------- |
|
|
4.09.2019, 10:29:01
Post
#33
|
|
Grupa: Zarejestrowani Postów: 1 834 Pomógł: 225 Dołączył: 20.03.2005 Skąd: Będzin Ostrzeżenie: (0%) |
Sądzę że w momencie gdy użytkownik kliknie `rezerwuję` to mają zaktualizować się rekordy z booked 0 na 1, więc sprawdzanie stanu rezerwacji może odbywać się na bieżąco.
|
|
|
4.09.2019, 20:02:46
Post
#34
|
|
Grupa: Zarejestrowani Postów: 95 Pomógł: 7 Dołączył: 27.10.2015 Ostrzeżenie: (0%) |
Podsumowując:
1) Można zrobić to zapytanie w MySQL - ale będzie wolno (w pewnych przypadkach, Twój hobbistyczny projekt tego nie odczuje) 2) Można zrobić liczenie w backendzie - będzie szybciej - w zależności jak bardzo przysiądziesz do optymalizacji liczenia (ale nie ma sensu się nad tym skupiać lepiej dowieźć inne funkcjonalności bo Twój projekt tego nie odczuje) 3) Można zrobić to tak jak zasugerował Tomplus - czyli dać lepszą strukturę w bazie danych - nie trzymać okresami tylko dzień po dniu - wtedy jak Ci z rezerwacji wypadnie jakiś dzień to nic nie musisz zmieniać - a w obecnej wersji będziesz musiał rozbić to na dwa rekordy - wtedy nie ma znaczenia czy będziesz liczył w MySQL czy backendzie bo będzie szybko (i w Twoim przypadku to chyba najlepsze rozwiązanie) Wybierz mądrze bo możesz wybrać tylko jedno |
|
|
Wersja Lo-Fi | Aktualny czas: 20.04.2024 - 10:40 |