Cześć. Naście lat temu napisałem coś w rodzaju forum jednowątkowego dla najbliższych znajomych. To właściwie wylistowane wiadomości jedna pod drugą. Bardziej to wygląda jak "aktualności" dodawane przez różnych ludzi. Działa do dziś, ale nadal na php 5.3 (chyba). W każdym razie jest to bardzo, ale to bardzo paskudny kod. Chciałem to sobie unowocześnić, podciągnąć pod PSR, "uobiektowić" że się tak wyrażę. Czyli napisać od nowa, zachowując obecne funkcjonalności, ulepszając je i dodając co nieco nowości.

I tutaj mam kilka pytań, próśb o porady:

1. Będzie klasa Message, zwierająca właściwości wiadomości, tj. 'text', 'author' oraz 'dateTime' z tabeli MESSAGES, oraz kilka innych, z innych tabel z bazy, ale o tym za chwilę. Obiekt tej klasy będę tworzyć przy dodawaniu nowej wiadomości, edytowaniu istniejącej, usuwaniu wiadomości oraz wyświetlaniu wielu wiadomości na stronie (tutaj $obj = new Message; w pętli dla każdego rekordu wiadomości). Dobrze rozumuję?

2. Każda wiadomość może być 'read' lub 'unread' przez każdego usera. Tabela będzie wyglądać tak: ID, ID_MESSAGE, ID_USER. Tyle wg mnie wystarczy, bo rekord istnieje tylko jeśli wiadomość jest 'unread' przez danego usera. Ma to sens?
2a. Jak rozumiem - status odczytania/nieodczytania jest również właściwością wiadomości i powinienem to załadować do tablicy (zawierającej ID_USERów, którzy tej wiadomości nie przeczytali) do obiektu klasy Message. Tak?

3. Podobnie jak ad2. każdy user może sobie oznaczać wiadomości jako 'favourite' czy tam 'toRemember' albo 'important'. Tutaj postępuję identycznie jak w przypadku właściwości read/unread.

4. Na stronie jest kilka rzeczy wyświetlanych w zależności od tego co ja (jedyny admin/moderator) wpiszę w odpowiednie okienko widoczne tylko dla mnie. Np. mam formularze do wpisania 'następne spotkanie (data)' , 'u kogo' , 'prowadzący' itd. Potem to się wyświetla w treści strony. Jak do tego podejść w kontekście trzymania informacji oraz OOP? W bazie takie rzeczy trzymać? Dla 'u kogo' jest potrzebna jedna kolumna, ale np dla 'liderboard' są już 3. No i dla każdej z tych informacji jest raptem po jednym rekordzie potrzebnych, więc baza chyba bez sensu. W pliku txt więc? To będzie raptem kilkanaście słów z tych wszystkich formularzy.
4a. Jak to ubrać w klasy/klasę?

5. Chcę zaimplementować porządny edytor z bbcode, coś jak tutaj na forum. Polećcie jakiś.

6. Myślę nad ulepszeniem wyszukiwania we wpisach, bo obecnie mam to realizowane przez zwykłe SELECT * FROM tabela WHERE 'text' LIKE '%$szukanaFraza%'. Jest jakaś możliwość lepszego szukania po bazie? Z oczywistych względów roboty google po mojej stronie nie hulają

7. Polećcie jakiś moduł do uploadu plików - przeciąganie pliku do okienka uploaduje go od razu, itd.


To chyba na tyle na razie. Pewnie coś jeszcze się urodzi, a na pewno więcej będzie jak się za to zabiorę. Proszę o opinię powyższego i rady. Dzięki.

1,2,3 - tak

4 Ja kiedys mialem na to tabele w bazie z polami:

KEY, VALUE

a potem na stronie jak mialem cos wyswietlic to poprostu,
$properties->getByKey()
i juz

" ale np dla 'liderboard' są już 3."
To nic nie zmieniasz. poprostu jako key dajesz: liderboard1, liderboard2, liderboard3 To tylko przyjlad, ty zamiast 1,2,3 mozesz dac bardziej czytelne suffix.

Oczywiscie tych par KEY VALUE jest stosunkowo malo wiec jednym zapytaniem pobieram wszystkie zamiast przy kazdym KEY generowac zapytanie do bazy.

6. No wszystko zalezy co i z jaka skutecznosciachcesz szukac. Twoje aktualne rozwiazanie, oprocz faktu ze jest podatne na SQLINjection (brak bindownia) jest ok. Wydaje mi sie ze nie potrzebujesz niczego innego na chwile obecna

Dzięki nospor!

Ad 4 - brzmi sensownie. Wszystko zmieszczę w jakichś 10-12 rekordach.

Ad 6 - dodam jeszcze opcje wyszukiwania 1) dokładny match, 2) dowolne słowo z wpisanej frazy i 3) case sensitive. Powinno styknąć. Natomiast zainteresował mnie TEN artykuł i MATCH o którym wcześniej nie wiedziałem. Czy to jest bardziej optymalne niż WHERE?

To pytanie nie ma sensu. MATCH uzywa WHERE, albo raczej to WHERE uzywa MATCH

To co pokazales to inny rodzaj przeszukiwania tekstu, bardziej "ludzki". Potestuj, sprawdz, moze bedzie ci lepiej pasowal w aplikacji

Match wydaje mi się użyteczny przy przeszukiwaniu więcej niż jednej kolumny. U mnie będę szykać tylko w jednej, więc chyba nie ma co wydziwiać.

Widze znowu nie doczytales do konca artykulu. Match robi zdecydowanie wiecej niz tylko skrot w szukaniu pod dwoch kolumnach

Nie no czytałem cały. Wiem o dodatkowych opcjach jak na przykład szukanie fraz pokrewnych - wszystkich wystąpień słów z szukanej frazy. To mi się wydaje ogólnie bardzo przydatne przy przeszukiwaniu nie za długich stringów.