Co jest bardziej wydajnym i "lepszym" rozwiązaniem Opcje

[awakening]

Witam,

Natknąłem się na problem poniekąd natury filozoficznej. Muszę zrealizować dość skomplikowaną operację na danych z bazy i widzę dwie możliwości rozwiązania zadania:

Rozwiązanie 1. Pobrać wszystkie dane na raz, jednym zapytaniem i potem "obrobić" je w kodzie. Dokładnie chodzi o zsumowanie wartości produktów według grup do których należą, czyli pobieram wszystkie produkty jednym zapytaniem, następnie iteruję po nich i sumuję wartości przypisując je do tablicy z grupami produktów.

Rozwiązanie 2. Stworzyć dwa oddzielne widoki w bazie danych (tak mi wychodzi ze struktury bazy, każdy z nich będzie miał ok. dwa JOIN'y) a następnie w kodzie przy zapytaniu połączyć kolejnym JOIN'em te dwa widoki. To rozwiązanie nie wymaga iterowania po tablicy w kodzie, ani wykonywania żadnych innych "brzydkich" operacji na danych. To rozwiązanie podoba mi się bardziej ze względu na czystość w kodzie i łatwość utrzymania kodu, ale mam małe obawy co do wydajności tego podejścia.


Czy istnieją jakieś "best practices" w takich przypadkach? Lepiej dane "obrabiać" po stronie bazy danych, czy w kodzie?

[awakening]

Na razie używam widoków ze względów praktycznych. Jako frameworka używam CakePHP, w którym tworząc zapytanie "ręcznie" muszę zadbać o ochronę przed SQL Injection, tworząc widok w bazie ten problem odpada i jest po prostu szybciej, a na problemy z uprawnieniami jeszcze się nie natknąłem. Pewnie za jakiś czas i tak czeka mnie refaktoring i widoki zostaną zastąpione "customowymi" zapytaniami w modelach.

[Pyton_000]

Jako frameworka używam CakePHP, w którym tworząc zapytanie "ręcznie" muszę zadbać o ochronę przed SQL Injection, tworząc widok w bazie ten problem odpada i jest po prostu szybciej

Wybacz ale takiej bzdury jeszcze nie słyszałem.
Widok to nic innego jak ogromne zapytanie/a zwracające ileś tam kolumn. W efekcie piszesz dokładnie dokładnie tak samo jak zwykłe zapytanie, z różnicą że nie wybierasz tabeli tylko widok jako źródło danych.

Więc gdzie ta ochrona

Fakt przy widoku można ograniczyć się co Model::findBy...() i z głowy, a przy zwykłym query filtrowanie niezbędne.

A problemy z uprawnieniami... Zrób obie eksport widoku i spróbuj zaimportować do innej bazy i innego użytkownika to zobaczysz

Ten post edytował Pyton_000 28.08.2014, 21:38:04

[awakening]

Wybacz ale takiej bzdury jeszcze nie słyszałem.
Widok to nic innego jak ogromne zapytanie/a zwracające ileś tam kolumn. W efekcie piszesz dokładnie dokładnie tak samo jak zwykłe zapytanie, z różnicą że nie wybierasz tabeli tylko widok jako źródło danych.

Więc gdzie ta ochrona

Fakt przy widoku można ograniczyć się co Model::findBy...() i z głowy, a przy zwykłym query filtrowanie niezbędne.

A problemy z uprawnieniami... Zrób obie eksport widoku i spróbuj zaimportować do innej bazy i innego użytkownika to zobaczysz

Zdaję sobie z tego sprawę, że patrząc na to od tej strony widok niczym nie różni się od "normalnej" tabeli. Co do SQL Injection "ochrona" to może zbyt duże określenie, ale po prostu nie muszę pamiętać o sanityzacji danych wprowadzanych przez użytkownika, poza tym łatwiej jest mi modyfikować widok w kliencie bazy danych niż "surowe" zapytanie w kodzie php. Więc na obecnym etapie tak jest wygodniej, a nic nie stoi na przeszkodzie, żeby za jakiś czas przenieść zapytanie z widoku do modelu.

Problem z eksportem w moim przypadku nie istnieje importuję do tej samej bazy i tego samego użytkownika, tyle, że na serwerze produkcyjnym.