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?

Twoje pierwsze rozwiązanie:
A) jest "brzydkie"
B) wywali się przy większej ilości rekordów z powodu PHP'owego memory_limit

Co do drugiego rozwiązania to widoki w MySQL są złem, chociażby ze względu na przenośność (są problemy z uprawnieniami i użytkownikami). Poza tym jeśli możesz to zrobić za pomocą widoku, to możesz też zwykłym zapytaniem. Efekt jest ten sam - i tak MySQL musi przemielić wszystkie dane.

Więc ja bym chyba był za 3. opcją - jedno bardziej rozbudowane zapytanie.

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.

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.

Wydaje mi się, że @Pyton_000 bardziej miał na myśli, że dane w widoku nie zależą od parametrów wejściowych. Więc czy jako źródło wybierasz widok, czy "czyste" zapytanie, to różnicy w bezpieczeństwie nie ma żadnej, bo nie będzie tam żadnych parametrów wejściowych.

Raczej o:

[SQL] pobierz, plaintext 
SELECT col1, col2,col3 FROM tabela JOIN cos USING(cos) .... WHERE id = 2
[SQL] pobierz, plaintext 

a

[SQL] pobierz, plaintext 
SELECT col1, col2,col3 FROM widok WHERE id = 2
[SQL] pobierz, plaintext 

I tu i tu przekazujemy ten sam parametr. Tyle że widok daje nam proste zapytanie, ale parametry te same.
Więc może autor wyjaśni ocb