[PHP, AJAX] Prośba o poradę

[Inco]

Też "gratuluje" koncepcji, tylko nie rozumie po co komuś w taki wypadku baza danych, tak jak Slawek22 napisał lepiej już zapisywać do pliku tą strukturę kategorii. Całą ta idę z zapisywaniem kategorii do pola tekstowego, to całkowite zaprzeczenie relacyjnych baz danych !

[Kul]

przy select jesli chcial bys pobrac strony z jakiejs tam kategori robisz WHERE c_id LIKE "%,@id,%", bez explode

Gratuluje "trafności koncepcji" wykorzystania klauzuli LIKE w wydajnej aplikacji.

Mion moj drogi kolego:> mowiac o wydajnosci masz na mysli ile set tysiecy wierszy zapisanych w tej bazie?!!! bierzesz pod uwage długość i typ pola?!!!

Inco

zapisywania do pola tekstowego?!!! zaprzeczenie ralacyjnych baz danych? i lepiej w pliku trzymać? no i zdecydowanie szybszy dostep do danych, a i bezpieczenstwo na wyzszym poziomie czyli uwazasz ze miedzy id kategorii zapisanym w tabeli pages (p_id, p_url, c_id) w postaci 1,5,7 nie mozesze zajsc relacja z tabela category(c_id, c_name, c_masterID)? polecam Ci ten link.

[Mion]

mowiac o wydajnosci masz na mysli

Mam na myśli prawidłowe praktyki programistyczne na etapie tworzenia nowego kodu aplikacji do których bynajmniej twój pomysł się nie zalicza

[Kul]

jesli katalog bedzie przyjmowal 50 stron dziennie to po 5 latach zapytanie bedzie sie wykonywalo w ciagu 0,7s.

[Inco]

Kul, chyba nie mamy o czym rozmawiać, bo jeśli uważasz że wykonywanie się jednego zapytania na poziomie, czy nawet całego skryptu na poziomie 0.7 sekundy, w wypadku katalogu jest czymś normalnym. To nie chciał bym używać twoich aplikacji, lub uruchamiać na swoim serwerze.

Odpowiem jeszcze na twoje pytanie: Tak można nazwać to co napisałeś jakąś relacją, podobnie jak liczydło można nazwać komputerem

[Kul]

przepraszam, zabraklo zera - 0,07 (ale to byl mocny argument, liczy sie ).

tak, zdecydowanie liczydlo mozna nazwac komputerem a WHERE c_id IN (1,2,3) relacja.

dodatkowo pamietaj ze tabla w ktorej chcial bys trzymac powiazania, zawieralaby ilosc wiersz rowna = ilosc stron x ilosc kategorii do ktorych sa dodane (po 5 latach (50 stron dziennie) byloby to 300 000 wierszy przy zalozeniu ze kazda strona zostala dodana do 3 kategorii) - teraz zobacz o ile wieksza liczba danych musi byc zaprzegana od zapytania i jak te zapytania musisz rozbudowywac (kazde bazujace na relacji strona - kategoria). oczywiscie miej na wzgledzie to ze dodatkowa tabela w bazie, to dodatkowe zapytania(np. przy dodawaniu nowej strony), dodatkowe tablice, dodatkowe zmienne, dodatkowe funkcje weryfikujace spojnosc danych itd. teraz zadaj sobie trzy pytania: co ta relacja da Ci w przyszlosci(w przypadku tego katalogu stron), co da Twoim uzytkownikom, a o ile wiecej kodu bedziesz musial napisac. jak juz sobie odpowiesz przelicz to na $ i juz masz pierwsza lekcje z projektowania !!!

[MMP]

ctrl+c i ctrl+v i wszystkim zajmuje się baza danych, że komuś się chciało to publikować

[zoreander]

WHERE c_id LIKE "%,@id,%"

Coś takiego w kategoriach dyskwalifikuje skrypt do pracy z jakimś konkretnym obciążeniem. Widziałem to na "żywym" przykładzie.

[General_Depet]

Jako że piszę właśnie nowy skrypt katalogowy obserwuje wątek z ciekawości i mimo iż profesjonalnym programistą nie jestem (i tego co ważniejsze nie ukrywam) to jednak chciałbym zwrócić Waszą uwagę że liczy się nie tylko wydajność kodu ale również jego przejrzystość, prostota i czytelna struktura SQLa. I teraz tak:

przy select jesli chcial bys pobrac strony z jakiejs tam kategori robisz WHERE c_id LIKE "%,@id,%", bez explode

Jasne można tak zrobić - zaoszczędzisz całą jedną tabelę od relacji - like obsłuży rekord (chociaż moim zdaniem nie do tego służy) ale co w panelu administratora gdy moderator będzie chciał "odpiąć" jedną kategorię/podkategorię ? Napiszesz się wtedy znacznie więcej skomplikowanego kodu niż gdybyś zrobił to na osobnych relacjach np. id|id_kat|id_strony

Po co Ci do tego cały kombajn jakim jest jQuery ?

Po to, że jest bardzo wygodny w obsłudze.... Jak komuś żal tych dodatkowych megabajtów transferu może ładować biblioteki z repozytoriom google

Problem z jQuery (przynajmniej u mnie) jest w tym że do każdego formularza muszę pisać osobne odwołanie do ajaxa w jQuery w head. W przypadku mojej prostej funkcji którą podałem na poprzedniej stronie ajaxa inicjuje krótki js zawarty w zdarzeniu np. onClick="change('index.php?action=ajax&id=21', 'ajax', '', 'GET')" - problem jest tym istotniejszy gdy chcemy mieć POSTowy ajaxowy formularz wywołany innym ajaxem (wtedy document.getElementById.value poszczególnych elementów musi znajdować się w pliku tego 2 formularza bo zawarty w head pierwszego pliku nie zadziała).

[Inco]

przy select jesli chcial bys pobrac strony z jakiejs tam kategori robisz WHERE c_id LIKE "%,@id,%", bez explode

Jasne można tak zrobić - zaoszczędzisz całą jedną tabelę od relacji - like obsłuży rekord (chociaż moim zdaniem nie do tego służy) ale co w panelu administratora gdy moderator będzie chciał "odpiąć" jedną kategorię/podkategorię ? Napiszesz się wtedy znacznie więcej skomplikowanego kodu niż gdybyś zrobił to na osobnych relacjach np. id|id_kat|id_strony

Lepiej tego nie można było ująć ale założę się że Kul zaraz znajdzie i na to rozwiązanie, które będzie przypominało budowanie szybowca z betonu ( pewnie się da to zrobić, tylko po co )

Zresztą nic się nie oszczędza bo dane są i tak składowane jako string, przeszukiwanie stringa będzie dużo mniej wydajne niż inta, nawet po zbudowaniu indexu dla tego pola, tym bardziej że dane są bardzo specyficzne.

[Kul]

Zresztą nic się nie oszczędza bo dane są i tak składowane jako string, przeszukiwanie stringa będzie dużo mniej wydajne niż inta, nawet po zbudowaniu indexu dla tego pola, tym bardziej że dane są bardzo specyficzne.

pages (100 000 rekordow)

category (1000 rekordow)

pages_caregory (300 000)

https://like-test.home.pl/

zastanawiam sie ile tysiecy dodanych witryn chcial bys wyswietlac na jednej liscie kategorii

bo jesli np chcial bys wyswietlic ich 30, to w efekcie like zwiekszylo by wydajnosc o 40% :>

[slawek22]

Kul no proszę cię, myślałem, że jesteś rozsądny człowiek tym czasem upierasz się, że kategoria ma być na polu tekstowym i like. Ja również, jak każdy rozsądny człowiek tutaj nie chciałbym korzystać z tak pisanych aplikacji. Pewnie admini którzy czytają ten topic zgrzytają zębami.

Na prawdę wątpię, że piszesz jakiekolwiek aplikacje, jeśli masz problem z wykonaniem tak prostej rzeczy jak kategorie, bo to są podstawy wykorzystania baz danych. Na 2-im roku na studiach tego uczą.

bo jesli np chcial bys wyswietlic ich 30, to w efekcie like zwiekszylo by wydajnosc o 40% :>

Chyba o tyle by ją zmniejszyło. To jest niby taki "dobry pomysł"? Tracić 40% na jednej kwerendzie?

Co do like - to jest optymalizowane. Nieznacznie, tzn. nie tak jak są optymalizowane zapytania const. Aż sobie z ciekawości wykonałem w pętli takie zapytanie - przy wyłączonym cache na indeksowanym polu char (100k rows).

Normalne zapytanie (=): 0.03 ms

Like: 0.11 ms

oczywiscie miej na wzgledzie to ze dodatkowa tabela w bazie, to dodatkowe zapytania

Inner / outer join. Ilość tabel nie ma żadnego związku z ilością zapytań do bazy (jeśli się te zapytania potrafi dobrze napisać). Bo znam magików którzy przy 2 tabelach robią 2 kwerendy a "inner join" ma u nich postać kodu w PHP, z resztą to taka sama "magia" jak robienie kategorii na like Teraz mi powiedz, jak w takim rozwiązaniu wygląda spójność danych i klucze obce Co robisz, gdy np. chcesz sobie wyświetlić obrazki pod kategorią. Na tak "świetnie zaprojektowanej" bazie, będzie to explode w PHP i dodatkowa kwerenda zamiast dodatkowej linijki INNER join która to wszystko "zrobi" automatycznie bez udziału PHP.

Zresztą nic się nie oszczędza bo dane są i tak składowane jako string

Pomyśl sobie Inco co się stanie przy bardziej rozbudowanej kategorii, kiedy każdy rekord będzie miał masę niepotrzebnych danych (bo baza nie będzie znormalizowana). Nie dość, że taka baza będzie ogromna, każda kwerenda będzie się wykonywała w nieskończoność to pomyśl sobie co się stanie np. przy usuwaniu lub zmianie nazwy kategorii

Zamiast jednej kwerendy do tabeli kategorii kwerenda w pętli na całej bazie. Dodasz sobie przez przypadek kategorię z literówką, będziesz chciał poprawić - to czekać cię będzie kilka minut przerwy na kawę (przy większym katalogu). Pewnie w tym czasie jeszcze jakiś system bezpieczeństwa zadziała i ubije tak napisany skrypt.

Klucz obcy do tabeli kategorii to 4 lub 2 bajty, taka nazwa kategorii przy like to minimum kilkanaście bajtów. Nie licząc indeksów. Zajebiaszcze rozwiązanie

Gdyby skrypty katalogów kosztowały po 1000PLN to bym zrozumiał pisanie takiego czegoś. Ale jest tyle dobrych i darmowych skryptów...

[Kul]

Patrz, nawet jak mozesz dotknac testu wydajnosci na zywych danych nadal twierdzisz ze w tym przypadku like nie jest wydajniejsze podziwiam to spojrz na cyferki i zapytania w tym linku ktory umiescilem. faktycznie nie bralem pod uwage katalogu stron z obrazkami kategorii ;D [rozumiem ze wykluczasz umieszczenie obrazka kategorii w tabeli category] w sumie jak by w kazdej kategorii jeszcze jakas muzyczke w tle podczepil to by bylo jeszcze bardziej kozacko ;D fantastycznie ze wykonales taki test na "100k rows" ;D tylko dobrze by bylo jesli test odzwierciedlal by te konkretnie zagadnienie. ps. jesli zdarzysz mi zrobic kawe w czasie wykonywania UPDATE category SET c_name = "poprawna nazwa" WHERE c_id = "5" to place 1000 zl, jak w tym czasie zadziala "system bezpieczenstwa" to place dwa ;D o stary ;D ogolnie bardzo brawurowa wypowiedz, gratuluje ;D

[Inco]

Pomyśl sobie Inco co się stanie przy bardziej rozbudowanej kategorii, kiedy każdy rekord będzie miał masę niepotrzebnych danych (bo baza nie będzie znormalizowana). Nie dość, że taka baza będzie ogromna, każda kwerenda będzie się wykonywała w nieskończoność to pomyśl sobie co się stanie np. przy usuwaniu lub zmianie nazwy kategorii

Nie musisz mi tego tłumaczyć, dla mnie ta idea jest tak absurdalna, że mam dość nad nią się rozwodzić. Kul widocznie żyjesz w świecie równoległym u mnie tak jak u Sławka takie zapytania jak proponujesz wykonują się dużo wolniej, niż w sposobie klasycznym. Nie mam czasu, a głupią dyskusję, wiec rób sobie jak chcesz.

[Kul]

czyli co? macie jeden komputer na caly akademik? czy w tym samym pokoju mieszkacie? :) u Was moze tak;) na serwerze home.pl troche szybciej (pomijam to ze to nie te same zapytania itd ), no ale skoro zamierzacie stawiac katalogi stron na komputerach domowych to ja juz nie mam watpliwosci ze kryzys dotka rowniez rynku "seo"

ps. ten link ktory zamiescilem operuje na zywych danych na serwerze home.pl (odswiez sobie strone, parametry zapytania generowane sa losowo).