Tworzę aplikację, a jedną z jej funkcji będzie harmonogramem osoby - wiesz, aby utworzyć harmonogramy pracy dla pracowników dla bieżących i następnych miesięcy, gdzie pisać zmiany, liście chorych, dni itp.

W tej chwili zaprojektowałem strukturę za pomocą formatu JSON, tak jak:

enter image description here

Tutaj pole schedule zawiera harmonogram dla odpowiedniego miesiąca dla odpowiedniego członka personelu w formacie JSON, w ten sposób: [{"date": "2020-10-01", "shift": "B"},{"date": "2020-10-02","shift": "B"}, ...].

Ta struktura działa i wybrała go, ponieważ nie będzie przeciążać DB z tonami wpisów dla każdego dnia pomnożonego przez ilość członka personelu. Ale zdałem sobie sprawę, że nie będę w stanie przeszukać niektórych dziedzin, będę musiał również obliczyć całkowitą godzinę pracy (i inne godziny) w moim PHP i JS, co oznacza, że wiele prac i obciążenia serwera.

Druga wersja jest wykonanie tabeli z just id (int), staff_id (int), date (date), value (string), gdzie zmiana (wartość) będzie przechowywana dla każdego członka personelu na każdy dzień. Ale mogę założyć, że będzie dość ciężkie po tym, powiedzmy, rok użytkowania z 10 członkami personelu (w dzierżawach 3650 wpisów). Ale ułatwi to wyszukiwanie danych, wykonaj raporty statystyczne, wykonują obliczenia godziny (przy użyciu tylko JS) i uprością kod serwera.

staff_id będzie zawierał identyfikator członka personelu i będę uzyskać dostęp do tych danych za pomocą elokwentnego związku.

Dla Ciebie jako eksperta, jaka wersja jest lepsza i dlaczego (mówienie o wydajności aplikacji)? Czy ilość wjazdu DB nie wpłynie na to ilość?

Str.s. Ignorujmy teraz funkcje eksportujące, ale rozumiem, że będę mógł wyeksportować tę tabelę, przy użyciu tylko wersji 2 z tego.

P.P.S. Używam MySQL (dla środowiska dev) i mariadb (do inscenizacji i produkcji).

Dziękuję Ci!

-1
Max Krizh 22 listopad 2020, 17:02

1 odpowiedź

Najlepsza odpowiedź

Unikaj przechowywania danych strukturalnych w RDBMS w JSON

MySQL i takie są RDBMSS (relacyjne systemy zarządzania bazami danych). Jeśli możesz zdefiniować strukturę tabel pod względem kolumn, powinieneś zawsze , należy unikać przechowywania danych w JSON podczas korzystania z RDBMS. Przyczyna Zapytania dotyczące bazy danych JSON są prawdopodobne wolniejsze (wymaga analizowania jsona, a ponieważ kolumny JSON mogą przechowywać niestrukturalne dane).

Nie będzie również zaskakujące, że przechowywanie danych z formatem równoważnym JSON zajmie więcej przestrzeni, ponieważ powtarzasz klucz "date" i "shift" każdy rząd. Spowoduje to również przejście na obciążenie sieciowe, o którym mówię później. Jak MySQL przechowuje dane "porównywalne" do CSV. Możesz spróbować tej witryny CSVJSON Właśnie znalazłem w Google Search, i obserwowałem, jak wiele spacji JSON zużywa.

Również prawdopodobnie będziesz mniej elastyczny z zapytaniami i nie będzie w stanie skorzystać z niektórych funkcji Lavel (naprawdę ważne) .

Poradzam przenosić harmonogramy w innej tabeli, tworząc relację jednego do wielu (harmonogramy do zmiany).

Wtedy będziesz mógł zrobić coś takiego, zakładając, że tabela w zrzucie ekranu nazywa się schedules i kolumna schedule jest przekształcona w tabelę o nazwie shifts.

class Schedule extends Model {
  function shifts() {
    return $this->hasMany(Shift::class);
  }
}
$staffSchedule = Schedule::whereStaffId(1)->first();
$numOfShifts = $staffSchedule->shifts()->count(); // You can query build off of `shifts()`
$shifts = $staffSchedule->shifts; // Magic property that returns a collection of shifts

Oblicz wszystko za pomocą SQL, jeśli to możliwe, a następnie ramy sieciowe serwera. Obliczenia po stronie klienta jest ostatnim ośrodkiem.

Powody:

  • Zakłada się, że serwery są silniejszymi maszynami.

  • Powracające wyniki pośrednie wymagają dużo ruchu sieciowego.

    Twoja aplikacja będzie wolna, jeśli klienci muszą pobrać MBS danych z wolnym Internetem. Zoptymalizuj się w przeniesieniu jako małej sieci w sieci przez możliwe, nad próba przeciążenia obliczeń do strony klienta.

  • Hydrating Modele Lavel z wyników DB Używać więcej niepotrzebne zasoby komputerowe.

    Czasami można nawet osiągnąć limit pamięci PHP, jeśli masz do czynienia z dużą ilością rzędów w połączeniu z złym kodem

  • Obliczenia w PHP prawdopodobnie będą wolniejsze niż w SQL.

    Często możesz przejść przez kilka relacji, ten db dostęp napowietrznych naprawdę spowalnia obliczeń. na przykład Otrzymałeś n modele i chcesz policzyć każde z ich zmian.

    // Just a toy example. No one would realistically do this.
    $schedules = Schedules::where(/*...*/)->get(); // 1 SQL call returns n objects
    $totalShiftCount = $schedules->map(
       fn (Schedule $schedule) => $schedule->shifts()->count()
    )->sum(); // n SQL calls. BAD! Avoid scaling SQL calls to number of rows.
    

Lavel byłby jeden po jednym poczekać na wynik SQL dla tego wiersza i skonstruować model reprezentujący dane wiersza przed uruchomieniem następnego SQL. To ten napowietrznik spowalnia wykonanie .

Unikaj używania modeli Lavel, jeśli chcesz coś obliczyć, ale wymagałoby dostępu do tysięcy wierszy i nie użyje modeli w inny sposób. Jeśli nie możesz utworzyć swojego zapytania za pomocą Larvel Query Builder, formularz z użyciem Surowe wyrażenia. Staraj się pisać 1 zapytanie SQL , co robi wszystko, czego potrzebujesz.

Zaufaj mi, obliczanie czegoś za pomocą modeli Lavel zamiast czystej SQL jest Multitudes wolniej . Przekazanie niepotrzebnych danych do strony klienta często zajmuje większy opłatnik na swoim serwerze, ponieważ wysyłasz Unicode kodowane dane JSON, zamiast wykonywać obliczenia na serwerze.


Nie jestem pewien, czy odpowiedziałem na wszystkie twoje obawy, ale nie możesz skomentować poniżej, jeśli masz coś, co chcesz wyjaśnić.

1
Daniel Cheung 22 listopad 2020, 17:41