[PHP] Cotygodniowa wysyłka ofert Opcje

[zelu]

Witam,

mam problem natury algorytmicznej. Piszę aktualnie skrypt, w którym użytkownicy się zapisać do poszczególnych kanałów, a w tych z kolei pojawiają się co jakiś czas systemowe wiadomości. Wiadomości wyświetlają się w sidebarze, ale przy dopisaniu się do kanału można wybrać również opcję wysyłania wiadomości mailem. Dostępne są możliwości wysyłki natychmiastowej, raportu raz w tygodniu, albo brak e-maili. Nie ma problemu z wysyłką natychmiastową i brakiem e-maili. Zaciąłem się jednak przy wysyłce maili raz na tydzień.
Jak wiadomo różni użytkownicy mogą się zapisać do różnych kanałów, a więc każdy dostanie inne wiadomości w swoim mailu. Moje pytanie więc, jak pobrać te dane z bazy? Schemat jest następujący:

user:
- id
- email

channel
- id
- name

message:
- id
- title
- content
- channel_id

channel_user:
- id
- channel_id
- user_id

Można oczywiście pobrać najpierw użytkowników, a później dla każdego usera w pętli for pobrać odpowiednie wiadomości. Nie chciałbym jednak robić tego w ten sposób. Macie może jakieś inne pomysły?


Pozdrawiam
Marcin

[thek]

Nie.. Nie polegniesz z prostej przyczyny. Te pętle są bowiem małe, mają po kilka cykli góra. Nie są to kolosy więc. Poza tym używając konstrukcji w stylu foreach( explode( $row['kanały'] AS kanal ) ) {tutaj operacje na tablicy wpisów_kategorii} czy coś w ten deseń bardzo szybko operujesz na wpisach tablicowych. Tak więc może i są to zagnieżdżone pętle, ale króciutkie. Nie posiadające tysięcy przebiegów.

EDIT: A tu odpowiedź dla Wykrywacza:
A więc... Dopóki jest to wciąż ten sam użytkownik, to musi być wszystko pakowane jako treść jednego maila. Stąd pierwszy w ORDER BY jest user. Dopóki nie zmienia się też kategoria to jest ok. Ale w przypadku kilku chcesz chyba wiedzieć która wiadomość której kategorii się tyczy (nie wszystko na hurra tylko jakoś rozgraniczone). To więc też musisz kontrolować i najlepiej jeśli po kategorii jest sortowanie. Dlatego drugi w ORDER BY jest kanał. Do tego momentu (poza kontrolą kategorii) się zgadzamy oboje chyba.

Budowa tablicy jest rozwiązaniem elastyczniejszym. Pozwala Ci na łatwiejszą kontrole nad danymi. Zwróciłem już uwagę na problem porcjowania wyników, ale nie jest on jedyny. W przypadku modyfikacji musisz przebudowywać skrypt. Jest po prostu nieskalowalny. W razie zaś próby wykorzystywania tego do czegoś innego niż wysyłka maila jedynie (wspomniana przeze mnie możliwość tworzenia indywidualnego kanału RSS użytkownika) musimy tworzyć nowy skrypt metodą kopiuj-wklej i zmień fragmenty, ponieważ nie przewidujesz jakiegokolwiek operowania na danych poza tym jednym blokiem instrukcji. Czy nie prościej obsłużyć te same dane innym widokiem? Zamiast wysłać je do widoku maila poślę do rss (IMG:style_emoticons/default/smile.gif) Struktura zawiera o wiele mniej zdublowanych danych (parametry to dane usera/ów i tablica kategorii z wiadomościami). Jest elastyczna i w przypadku zmian o wiele prostsza do zarządzania.

To co widzisz z wierzchu inaczej działa od strony silnika łączenie tabel przecinkiem tworzy iloczyn kartezjański ich rekordów, z którego dopiero warunki eliminują nie pasujące do wzorca łączenia. Przy operowaniu na wielotysięcznych rekordowo tabelach jest to już niestety powoli odczuwalne nawet z zastosowaniem indeksów. Nie bez powodu określa się w ON warunki łączenia (IMG:style_emoticons/default/smile.gif) Inna sprawa, że silnik bazodanowy napisane przez nas zapytania stara przetworzyć do optymalizowanej wersji. Nie przypomnę sobie teraz, ale na stronie dokumentacji mysql czytałem o tym, że są one już po stronie silnika konwertowane także do innych zapytań, które mają na celu je zoptymalizować te napisane przez użytkownika.