Path: csiph.com!goblin2!goblin.stu.neva.ru!newsfeed2.atman.pl!newsfeed.atman.pl!.POSTED!not-for-mail From: Marek S Newsgroups: pl.comp.lang.php Subject: =?UTF-8?Q?Re=3a_Symfony_4_-_jak_projektowa=c4=87_baz=c4=99_danych_p?= =?UTF-8?Q?od_Doctrine=3f?= Date: Tue, 30 Apr 2019 01:16:48 +0200 Organization: ATMAN - ATM S.A. Lines: 129 Message-ID: References: <5cbf10a8$0$482$65785112@news.neostrada.pl> NNTP-Posting-Host: 89-70-94-204.dynamic.chello.pl Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2; format=flowed Content-Transfer-Encoding: 8bit X-Trace: node2.news.atman.pl 1556579821 2449 89.70.94.204 (29 Apr 2019 23:17:01 GMT) X-Complaints-To: usenet@atman.pl NNTP-Posting-Date: Mon, 29 Apr 2019 23:17:01 +0000 (UTC) User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 In-Reply-To: Content-Language: pl Xref: csiph.com pl.comp.lang.php:16227 W dniu 2019-04-28 o 14:50, Wojciech Bancer pisze: >> Nie, wcale nie 2 sekundy. Pisałem wcześniej, że przy ok pół miliona >> operacji (w ciągu nocy) udało mi się zaoszczędzić 2h pracy serwera >> (50%). Może nawet więcej. Nie pamiętam konkretnych liczb. > > No nie obraż się, ale pokazujesz że nie masz na tyle ogólnej współczesnej > wiedzy odn. architektury systemów by obiektywnie ocenić gdzie optymalizacja > mogłaby być najlepsza. Ależ zgadzam się w 100%! > Może masz rację, ale może nie. Może niekoniecznie > optymalizacja powinna skupiać się na triggerach, może lepsze byłoby > przemodelowanie procesu importu danych. Przemodelowałem obie te rzeczy. Modyfikacja algorytmu importu też wniosła pozytywny wpływ, ale nie aż tak spektakularny. Dobra, załóżmy, że jestem kretynem i metodą prób i błędów spowodowałem zaoszczędzenie czasu pracy serwera. Wpisywałem jedynie przypadkowe znaki z klawiatury. Po dwóch miliardach prób nawet zadziałało. Co z tego wynika? >> ojej... system się nie wyrabia przy 500k. > > A miał się wyrabiać przy pisaniu tej aplikacji? Oczywiście, ze nie. Nikt nie zakładał tak dużego sukcesu firmy w pozyskiwaniu klientów. I o to mi właśnie chodzi. Współczesny informatyk, wg Twojego opisu, to bezmózgi rzemieślnik, który jedynie jest w pełni świadom swoich niedomagań i w związku z tym implementuje byle jaki kod - aby tylko działał w trakcie testów i zaraz po uruchomieniu produkcyjnym. Chwilę potem może się walić... bo nie było w założeniach rzetelności jego pracy. Jeśli można napisać kod dobrze lub źle, nawet jeśli podobna ilość czasu jest na to potrzebna, to lecimy w wariant "źle". Szerze mówiąc, przyznaję Ci rację w tym zakresie. Nierzadko przysłuchuję się rozmowom rekrutacyjnym i to jest niestety cechą frameworkowców. Czasem nie wiedzą czym protecetd różni się od public... To cytat z dziś. >> Gdyby Ci informatycy wzięli się za uczciwą robotę i nawet dla >> niewielkiego początkowo przedsięwzięcia postąpili zgodnie z kunsztem >> programowania zwracając uwagę na detale, to problem wystąpiłby dopiero >> po dojściu do możliwości serwera a nie możliwości kiepskich algorytmów. > > A ja widzę typowe błędy zarządcze. Bo kłopot jest w tym, że zarząd zwykle nie wie czym jest baza danych, API, PHP i inny informatyczny bełkot. Tu pełna zgoda. Jednakże nie bardzo znajduję w tym wszystkim preferowane przez Ciebie wykorzystywanie ich niewiedzy na rzecz własnego lenistwa. > No ale idąc dalej, to jak myślisz, jak ktoś oceni Twoją pracę "za kilka > lat", jak firma rozwinie się jeszcze bardziej, dostawi się jeszcze > kilka maszyn i jednak wyjdzie, że optymalizacje które zrobiłeś teraz > już nie działają i mimo dostawienia maszyn system nadal się czka? > > Ciekawe czy Twój następca wystawi Ci taką samą laurkę jak Ty swoim :) Zajebisty jesteś w tym momencie. :-D Zakładasz zatem, że dobrze napisana wyszukiwarka Google powinna działać na przydomowym serwerze. Mało tego, dostawienie Facebooka i Pinteresta też nie powinno wnieść istotnego obciążenia dla CPU :-D Aha... i łącze 1Mbps spokojnie wydoli. A jak nie wydoli ... to będziemy pisać laurki na to, że jakiś kmiot informatyczny nie jest w stanie pchać przez łącze 1Mbps 10.000x tyle. Tylko pogratulować takiego podejścia. >> Co do w/w optymalizacji, to faktycznie praca była mrówcza. Np. zamiast >> indeksować całe pole typu array() należało rozbić indeks na dwa: >> przeindeksować tylko część tablicy - bo okazało się, że zdecydowana >> większość zapytań właśnie o te części pytała. Podobnie było z >> zapytaniami SQL. Zamiast jakiejś tam konstrukcji zastosowano inną i znów >> progress wydajnościowy. Tymczasem od początku można było zrobić to >> dobrze... > > Rzecz w tym że "dobrze" ma więcej niż jedną postać. > I to jest przedmiotem dyskusji w tym wątku. Tyle tylko, że Ty wymagasz przekroczenia barier fizyki aby nie było beznadziejnie. >>> Query builder *nie* jest żadnym łataniem, ani też żadnym SQLem. >>> Jest narzędziem do budowania zapytań. >>> Jak chciałbyś odpytywać bazę inaczej? >> >> Raw SQL? Doctrine ma implementację czegoś takiego. > > Czyli chcesz używać ORM bez zalet ORM i z wadami ORM. > Fascynyjące :) Próbujesz naginać teraz moje wypowiedzi do tego by pasowały do Twoich szyderstw. Ja planuję używać SQL do insertów/update'ów w sekcjach wymagających wydajności. > Poczytaj o Unit of Work, o cache, > o tym jak się pracuje z obiektami: Sugerujesz, że są próby ratowania koncepcyjnej niedoróbki ORM w kolejnych segmentach Doctrine? > https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/reference/working-with-objects.html > https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/reference/unitofwork.html > https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/reference/caching.html Poczytam, ale nie wszystko na raz. Krok za krokiem przemierzam i testuję famework. >> ...i baza to zrozumie? Nie sądzę. Zawsze na końcu będzie SQL. Resztę >> wypowiedzi dopiszę poniżej. > > No to znowu, po co Ci ORM? Pisałem już: do wszystkiego, co nie musi być wydajne, bo jest za to wygodne. Np. zwykłe formularze fantastycznie proso się integruje z Doctrine. Ich wydajność może być tragiczna - nikt tego nie zauważy nawet. > Ale to *TY* spierniczasz bo nie rozumiesz narzędzia które używasz, > a starasz się go używać tak jakby go nie było i był czysty SQL. Mam nadzieję, że doznam jakiegoś olśnienia i uznam, że 2 zapytania SQL (z czego wynik pierwszego jest ignorowany) są bardziej wydajne niż jedno. -- Pozdrawiam, Marek