Wykonywanie obliczeń w MySQL vs PHP

Grałbym w mocne strony każdego systemu.

Logika agregacji, łączenia i filtrowania oczywiście należy do warstwy danych. Jest szybszy, nie tylko dlatego, że większość silników DB ma 10 lat optymalizacji właśnie w tym celu, ale minimalizujesz dane przenoszone między bazą danych a serwerem WWW.

Z drugiej strony większość platform DB, z których korzystałem, ma bardzo słabą funkcjonalność do pracy z poszczególnymi wartościami. Rzeczy takie jak formatowanie daty i manipulacja ciągami znaków po prostu są do bani w SQL, lepiej wykonywać tę pracę w PHP.

Zasadniczo używaj każdego systemu do tego, do czego został zbudowany.

Jeśli chodzi o konserwowalność, o ile podział na to, co dzieje się tam, gdzie jest jasny, rozdzielenie ich na rodzaje logiki nie powinno powodować większego problemu, a już na pewno nie wystarczy, aby zniwelować korzyści. Moim zdaniem klarowność kodu i łatwość utrzymania to bardziej spójność niż umieszczenie całej logiki w jednym miejscu.

Odp.:konkretne przykłady...

Wiem, że nie o to ci chodzi, ale daty to prawie szczególny przypadek. Chcesz mieć pewność, że wszystkie daty wygenerowane przez system są tworzone na serwerze WWW LUB w bazie danych. Postępowanie w inny sposób spowoduje pewne podstępne błędy, jeśli serwer bazy danych i serwer WWW są kiedykolwiek skonfigurowane dla różnych stref czasowych (widziałem, że tak się dzieje). Wyobraź sobie na przykład, że masz createdDate kolumna z wartością domyślną getDate() który jest stosowany na wstawce przez DB . Gdybyś miał wtedy wstawić rekord, używając daty wygenerowanej w PHP (np. date("Y-m-d", time() - 3600) , wybierz rekordy utworzone w ciągu ostatniej godziny, możesz nie uzyskać tego, czego oczekujesz. Jeśli chodzi o warstwę, na której należy to zrobić, wolałbym DB, ponieważ, jak w przykładzie, pozwala na użycie domyślnych wartości kolumn.
W przypadku większości aplikacji zrobiłbym to w PHP. Łączenie imienia i nazwiska wydaje się proste, dopóki nie zdasz sobie sprawy, że czasami potrzebujesz zwrotów grzecznościowych, tytułów i inicjałów środkowych. Poza tym prawie na pewno znajdziesz się w sytuacji, w której chcesz mieć imię, nazwisko ORAZ kombinację zwrotów grzecznościowych + imię + nazwisko. Łączenie ich po stronie bazy danych oznacza, że przenosisz więcej danych, chociaż tak naprawdę jest to dość niewielkie.
Zależy. Jak wyżej, jeśli kiedykolwiek będziesz chciał używać ich osobno, lepiej pod względem wydajności wyciągnąć je osobno i połączyć w razie potrzeby. To powiedziawszy, chyba że zbiory danych, z którymi masz do czynienia, są ogromne, prawdopodobnie istnieją inne czynniki (takie jak, jak wspomniałeś, łatwość konserwacji), które mają większe znaczenie.

Kilka praktycznych zasad:

Generowanie przyrostowych identyfikatorów powinno odbywać się w DB.
Osobiście lubię moje domyślne zastosowanie przez DB.
Przy wyborze wszystko, co zmniejsza liczbę rekordów, powinno być wykonane przez DB.
Zazwyczaj dobrze jest robić rzeczy, które zmniejszają rozmiar zestawu danych po stronie bazy danych (jak w powyższym przykładzie łańcuchów).
I jak mówisz; porządkowanie, agregacja, podzapytania, łączenia itp. powinny zawsze znajdować się po stronie bazy danych.
Ponadto nie rozmawialiśmy o nich, ale wyzwalacze są zwykle złe/niezbędne.

Istnieje kilka podstawowych kompromisów, z którymi musisz się zmierzyć, a równowaga naprawdę zależy od Twojej aplikacji.

Niektóre rzeczy zdecydowanie – za każdym razem – powinny być wykonywane w SQL. Wykluczanie niektórych wyjątków (takich jak daty) dla wielu zadań SQL może być bardzo niezgrabny i może pozostawić logikę na uboczu. Podczas przeszukiwania bazy kodu pod kątem odniesień do określonej kolumny (na przykład) jest łatwo przeoczyć te zawarte w widoku lub procedurze składowanej.

Wydajność jest zawsze brana pod uwagę, ale w zależności od aplikacji i konkretnego przykładu może nie być duża. Twoje obawy dotyczące łatwości konserwacji i prawdopodobnie bardzo ważne, a niektóre z wymienionych przeze mnie korzyści związanych z wydajnością są bardzo niewielkie, więc uważaj na przedwczesną optymalizację.

Ponadto, jeśli inne systemy uzyskują bezpośredni dostęp do bazy danych (np. w celu raportowania lub importu/eksportu), skorzystasz z posiadania większej ilości logiki w bazie danych. Na przykład, jeśli chcesz importować użytkowników bezpośrednio z innego źródła danych, w SQL zaimplementowano coś takiego jak funkcja sprawdzania poprawności wiadomości e-mail.

Krótka odpowiedź:to zależy. :)