Temat: Problem czysto algorytmiczny

Mam do zrobienia następującą rzecz i za cholerę nie mogę od 2 godzin nic sensownego zmyślić. (Może to przez te drinki z Żubrówką)

Chodzi o system płatnych linków SMS. Sam system mam już okodowany i zingegrowany z allpay.pl, chodzi o wyświetlanie. W pasku mają być 3 kolumny, w każdej z nich tytuł linka oraz pod spodem URL. Sprawa jest bardzo prosta, ktoś wysyła SMS, dostaje kod, wprowadza kod, link, tytuł i link zostaje zapisany do bazy. Link jest widoczny na stronie przez 6 dni, to też nie stanowi problemu. Klient zażyczył sobie rotacji owych linków przy każdym odświeżeniu witryny. Coś na wzór billboardów z dużych miast. Jeśli więc mam 10 wpisów w tabeli o numerach ID od 1 do 10, to przy pierwszym odpaleniu witryny widzimy w rubryce link ID 1, w drugiej link ID 2, a w trzeciej link ID 3. Przy kolejnych odświeżeniu witryny widzimy w 1 rubryce link ID 2, w drugiej link ID 3 a w trzeciej link ID 4. Koniec współgra z początkiem - zupełnie jak wstęga Mubu`sa.

Kombinowałem z LIMIT'ami oraz zapisem aktualnego ID do pliku przy każdym odświeżeniu, ale rezultaty mam mizerne. Jakąś tęższa główka ma dobry pomysł?

Dzięki.

Temat: Problem czysto algorytmiczny

Do pliku ci to nic nie da.
Co jeśli wejdzie 100 osób jednocześnie?

Zapisz w cookie aktualne ID a przy następnym odświeżaniu pierwszą pozycje zwiększ o 1.

Nad skryptem nie myślałem ale tak wstępnie bym to widział.

Temat: Problem czysto algorytmiczny

Co rozumiesz przez mizerne rezultaty? ;)

Przy zalozeniu, ze zwiekszamy iteracje dla kazdego odswiezenia strony, a nie dla danego uzytkownika, Twoje rozwiazanie jest jak najbardziej sluszne - proste i latwe w implementacji, zgodnie z zasada KISS (Keep It Simple Stupid).

@Mariusz Mikołajek: Wystarczy zalockowac (flock()) zapis pliku i nie bedzie z tym problemu. Albo uzyc SQLitea.Michał G. edytował(a) ten post dnia 08.09.07 o godzinie 18:28

Temat: Problem czysto algorytmiczny

Michał G.:
Co rozumiesz przez mizerne rezultaty? ;)

Sama implementacja problemu z LIMITami jest nawet dobra, ale nie mam pomysłu co z końcówką listy ;].

Należy jeszcze uwzględnić możliwość kasowania linków przez Admina (id - primary, autoincrement, unique).

Temat: Problem czysto algorytmiczny

Aaa takie buty ;)

Najlatwiejszym sposobem bylo by uzycie selecta:

SELECT * FROM linki WHERE id >= <zapisane_id> LIMIT 3

Po pobraniu rekordow sprawdzamy ile dostalismy wynikow.

Jezeli mniej niz zero to pobieramy z poczatku kolejne 3 rekordy.

Jezeli wiecej niz zero ale mniej niz 3 to pobieramy dodatkowo z poczatku roznice sumy otrzymanych rekordow oraz maksymalnej liczby rekordow do wyswietlenia (czyli w naszym przykladzie 3).

Teraz wystarczy tylko wyswietlic liste i w przypadku gdy ilosc rekordow jest wieksza od zera to zapisac ID drugiego rekordu (lub pierwszego w przypadku gdy mamy tylko jeden).

Banalne rozwiazanie ale to pierwsze co mi przyszlo do glowy ;)

Mozna by tez pokusic sie o kazdorazowe pobieranie nadmiarowych danych i pobierac zawsze od zapisanego IDka 3 rekordy oraz 3 pierwsze (laczac te zapytania przez UNION).
A w pozniejszym etapie wyswietlac tylko pierwsze trzy.

Dodanie calej logiki do procedury skladowej powinno takze nieco przyspieszyc dzialanie.

Temat: Problem czysto algorytmiczny

Dobry pomysł.

Przyznam szczerze, że myślalem też o parsowaniu wyników SQL do tablicy w pętli, po czym odwoływać się poprzez ID z pliku właśnie do indeksów z tablicy. I tak prosty algo, jeśli id z pliku-2 = liczba rows'ów, to zapisujemy pirewsze dwa i trzeci bierzemy z indexem[0]. jesli id z pliku-1 = num rows, to bierzemy do 3-elementowej tablicy 1 element i nastepnie 2 z brzegu [0] i [1] i resetujemy ID w pliku gdy jest rowne num_rows.

Nie wiem czy bedzie to optymalne.. ale tablica też smokiem nigdy nie będzie - wpis widnieje 6 dni,a jego koszt to 9zł, biorąc pod uwagę wielkość serwisu nie przewiduję więcej jak 40-50 linkow w bazie.