Kod do tego to Ja Ci moge conajwyżej za chajsy udostepnić.
Wyniki masz w screenach, we wcześniejszym poście.

Założenie jest proste, masz 10 rekordów, które mają po 10 dzieci i każde z tych dzieci ma 10 dzieci. Ma być pole przechowujące kolejność.
Nieograniczona ilość zagłębień, wiadomo jak będzie 255 nic się nie stanie.

hahaha, dobre mrc

http://www.awesomescreenshot.com/image/211...fe91b0995964e7e

Ilość node 1111;

to na górze to czas?

tak różnica microtime(true)

Mowa oczywiście o czasie generowania samej struktury, nie wliczam w to czasu requestu...

Czyli 0.4 sekundy trwało utworzenie takiej tablicy z zagnieżdżeniami z 1111 rekordów?

Ty wiesz, jak napisalem posta to mialem troche wyrzutow sumienia ze po tobie pojechalem. Ale juz mi przeszlo. Lol.

Ty "mistrzu", w ktorym miejscu ja to porownalem do zwyklego zapytania? Ja mowilem wlasnie o zapytaniu pobierajacym zagniezdzone dane opartym na drzewku IP

Mialem racje pare dni temu by olewac ten temat ale jakos dzisiaj przy sobocie mnie podkorcilo i zajrzalem.... rety....

Tak.

up...

Ba wliczam w to czas pobierania danych z BD.

To jest nested set, zmień teraz kilka leftów i rightów w różnych rekordach w bazie jakkolwiek i ciekawe, czy Ci się wszystko nie rozjedzie?

To po pierwsze.
Po drugie samo zapytanie wraz z wygenerowaniem takiej zagnieżdżonej tablicy u mnie trwa również około pół sekundy.
Reszta to czas ogarnięcia requesta przez Laravel, jeśli zrobiłbym to na czystym php miałbym zbliżony wynik do Twojego z tym, że bez wrażliwych danych.

Zastanawia mnie w jaki sposób wygenerowałeś tą tablicę z rekordów? Pętlami, rekurencją, warunkami?



Wdziałem to rozwiązanie, nie jest elastyczne.
Po co przechowywać kolejność w 00000000001, 00000000002, jeśli np. liczba rekordów wynosi 12.
Po za tym aktualizacja i dodawanie też jest pewnie dziwne, bo trzeba pewnie sprawdzać tą dziwna kolejność dla rodzica każdego i dopiero dodać dziecko, co komplikuje niepotrzebnie sprawę.

To nie jest istotne. Jeśli robi się zmiany w transakcji to nic nie ma prawa się rozjechać.


To też nie istotne. Chciałeś czas to dałem Ci czas. Pokaż swój. Czyli czas pobierania z BD + generowanie struktury.

U mnie request z wypluciem danych trwa <3s.


Jak to sam powiedziałeś:

" Kod do tego to Ja Ci moge conajwyżej za chajsy udostepnić."

Więc nie ważne jak, ważne że wynik jest taki sam, a czas 100x mniejszy. Smuteczek

2 sekundy to ma być szybko, no proszę Cie. Ja wcześniej źle spojrzałem myślałem ze robisz to 2 ms

Ale tu nie chodzi o to czy zapytanie zrobiłeś jakieś mega skomplikowane tylko o utrzymanie tego, wróć za pól roku i będziesz myślał jak to działa.

No nie wiesz bo o testach wgl nie słyszałeś, bo jesteś ignorantem i wiedzę masz wybiórcza, przykład lib do testów jednostkowych https://phpunit.de/ a jest ich dużo więcej rożnych.

pól sekundy to nadal więcej

Napisałem wcześniej, że robię to jedną pętlą. Co z tego, że używasz transakcji. Wrażliwe dane to wrażliwe dane.
Plus bardziej skomplikowane dodawanie i update.

Pisałem już wcześniej, że nested set jest gorszy niż moje rozwiązanie, a Ty mi z nested set wyjeżdżasz, chociaż tyle, że generujesz tablice z zagnieżdżeniami szybko, a nie np. rekurencyjnie to nadrabiasz.



To Ja Cię proszę...

Dobra, bo historia się powtarza, stosujcie sobie nested set.
Znałem to rozwiązanie wcześniej, ale nie spełnia moich oczekiwań, natomiast obecne całkowicie, przy stracie do nested set kilku dziesiątych sekundy ma bezpieczniejsze dane i łatwiejszą modyfikację.

Jakie wrażliwe dane o czym Ty gadasz.
Wiesz wgl co to jest transakcja?

Rób tak dalej, a potem się dziwić, że programiści PHP uważani są za tych gorszego sortu

Nie chcesz nested set to weź MPTT

Takie, że się rozjadą wszystkie jak wystąpi błąd.

Tak wiem co to jest transakcja człowieku.

Nie mogęęęęę.
Bawcie się w transakcję, Ja nie muszę



Rozmawiając z Tobą, można odnieść takie wrażenie.

Własnie zaprzeczyłeś sobie pierwszym zdaniem.

Chyba wystarczy, kiedyś może zmienisz firmę, przestaniesz pisać kod sam wtedy się przekonasz.

No ale czego można wymagać od juniora

Itak propsy za to, że próbujesz i jakoś to działa, bo czasem ktoś wymyśla swoje dziwne rozwiązania, a potem przychodzi tu bo mu kod nie działa.

[PHP] pobierz, plaintext 
function createTree($category, $left = 0, $right = null) {
    $tree = array();
    foreach ($category as $cat => $range) {
        if ($range['left'] == $left + 1 && (is_null($right) || $range['right'] < $right)) {
            $tree[$cat] = createTree($category, $range['left'], $range['right']);
            $left = $range['right'];
        }
    }
    return $tree;
}
 
$tree = createTree($category);
[PHP] pobierz, plaintext 

O i jest pętla do nested set


Na pewno nie tego, że zrozumie, że lepiej jest przy dodawaniu, aktualizacji i usuwaniu rekordu zastosować jedno zapytanie niż kilka w transakcji, gdzie nawet przy testowaniu poleceń sql można popełnić błąd w samym kodzie polecenia i kod się wykona, transakcja przejdzie, ale będziemy mieli źle dodane rekordy w wartościach right i left, ale to nic...

Rozmawiając z Tobą com, wyciągam wnioski, że junior to bardziej stan umysłu niż staż pracy.

Zawsze można popełnić błąd, ale transakcje są po to, żeby jak się rekord ma nie dodać to żeby się nie dodał, a nie jak wywali błąd to żeby nagle cały system siadł.



Gratulację, nwm czym się kierowałeś, że na to wpadłeś ale juniorem można być całe życie jak się nie będzie potrafiło pisać dobrego kodu i nie będzie się patrzeć na niego szerzej niż tylko w obrębie małego fragmentu który się napisało.

Kierowałem się własnymi odczuciami z rozmowy z Tobą.



Transakcja nie wychwyci, że dodajesz złą wartość dla lft lub rgt.

Dodawanie:

[PHP] pobierz, plaintext 
SELECT @myRight := rgt FROM nested_category
WHERE name = 'TELEVISIONS';
 
UPDATE nested_category SET rgt = rgt + 2 WHERE rgt > @myRight;
UPDATE nested_category SET lft = lft + 2 WHERE lft > @myRight;
 
INSERT INTO nested_category(name, lft, rgt) VALUES('GAME CONSOLES', @myRight + 1, @myRight + 2);
[PHP] pobierz, plaintext 

kontra


Usuwanie:

[PHP] pobierz, plaintext 
LOCK TABLE nested_category WRITE;
 
SELECT @myLeft := lft, @myRight := rgt, @myWidth := rgt - lft + 1
FROM nested_category
WHERE name = 'GAME CONSOLES';
 
DELETE FROM nested_category WHERE lft BETWEEN @myLeft AND @myRight;
 
UPDATE nested_category SET rgt = rgt - @myWidth WHERE rgt > @myRight;
UPDATE nested_category SET lft = lft - @myWidth WHERE lft > @myRight;
 
UNLOCK TABLES;
[PHP] pobierz, plaintext 

kontra:

[PHP] pobierz, plaintext 
delete from items where id = x
[PHP] pobierz, plaintext 

Nie znalazłem updatu, ale jest za pewne równie pokręcony, kontra zwykły:

[PHP] pobierz, plaintext 
UPDATE items
SET parent_id=value1,the_order=value2,...
WHERE id=id;
[PHP] pobierz, plaintext 

Przy stracie jednej lub dwóch dziesiątych sekundy w zapytaniu.
No co kto woli, na siłę nikomu nie wepchnę.

Jeszcze mógłbym się kłócić, jeśli bym rekursywnie tabelę generował i by to trwało łącznie 12 sekund, ale w tym przypadku? Dajcie spokój...

Zrobiłem jeszcze jeden test przy użyciu tego rozszerzenia ORM.

1) Generowanie losowych kategorii

a ) 10 rodziców mających po 10 dzieci, ich dzieci mają po 20 dzieci
b ) 20 rodziców mających po 10 dzieci, ich dzieci mają po 10 dzieci

W obu przypadkach to się generowało ok. 88 sekund, musiałem zwiększyć set_time_limit.

2) Wyświetlanie tego drzewa, czas od. 0.5 sek do nawet 1 s, przy użyciu tego rozwiązania które podałem w poprzednim poście. Nie biorę pod uwagę zastosowania Fragment::load() i Fragment::save() w celu przyspieszenia za kolejnym odświeżeniem.

No to masz wybór pomiędzy nested set, a moim rozwiązaniem, gdzie mojego rozwiązania nie ma w całości podanego tutaj i raczej nie będzie.

No i nie powiesz mi że jesteś więcej niż juniorem jakich tu wielu w tłumie.



Jakim niby cudem miało by się to wydarzyć, jak ręcznie tego nie ustawiasz, patrząc na ten kod który pokazałeś. Sorry ale magicznie one się tam nie pozmieniają nagle.

Zresztą to nie ja się przy nested set upierałem


A wiesz ile błędów ja mogę zrobić w Twoim zapytaniu, które to sortuje jak będę musiał coś pozmieniać..

A w ogóle to jest jeszcze "lepsze", bo prostsze od tego twojego ale nie odbiorę Ci tej przyjemności poszukania sobie.

normalnym cudem, że zrobisz jakiś błąd w zmiennych lub obliczeniach wartości przy modyfikacji rekordów.


Nie powiesz mi, że pracujesz zawodowo jako programista. Pewnie jesteś jakimś wykładowcą lub nauczycielem w technikum, tam na teoriach można lecieć

com, a mam pytanie, słyszałeś o html?

Analizując to co tu jest:
https://github.com/dfox288/kohana-nested-se...Nested/Sets.php

to przy wstawianiu, modyfikacji czy tam usuwaniu węzłów jest wszędzie taki schemat:

[PHP] pobierz, plaintext 
        try
        {
            $this->_db->begin();
            // dowolne operacje na węzłach
            $this->_db->commit();
        }
        catch (Exception $e)
        {
            $this->_db->rollback();
            throw $e;
        }
[PHP] pobierz, plaintext 

Czyli wszędzie transakcje (zakładam że chodzi o InnoDB). I w jaki sposób przy dowolnej modyfikacji drzewa to może się rozwalić? Zakładam że ten kod tego rozszerzenia jest sprawdzony i dobrze przetestowany.

Nie ma sensu dalej ciągnąć tej dyskusji bo żadne argumenty nie trafiają do autora.
Na dodatek ma swoje super hiper przetestowane rozwiązanie które mu działa. On się w tym odnajduje. Nie ma co tu więcej strzeępić ryja bo Autor szanowny od samego początku założył temat żeby się "pochwalić" ale nie przyjmować krytyki.

No nic, życie zweryfikuje...

Nie wiem co czytasz, ale szybko to zmien.... drzewka IP wygladaja tak: id1.id2.id10.id100 i tak sobie robisz do bolu.
Ale w praktyce nie ma potrzeby do "bolu" wiec nawet jakby bylo ograniczenie to i tak by sie nic nie stalo


@Omenomn ja rozumiem twoj punkt widzenia i rozumiem twoje rozwiazanie. "Zajebistosc" twojego rozwiazania to tylko i wylacznie fakt ze jest niewrazliwe na to, jak ktos recznie zmieni dane w bazie i twoje drzewko sie nie rozpieprzy bo ty wszystko na bierzaco wyliczasz. Tak, to prawda. Ja to widze.
Szkoda, ze ty nie widzisz innej wady swojego systemu: przez to, ze wyliczasz wszystko na biezaca, to twoje rozwiazanie jest cholernie wolne. Dostrzezesz to moze kiedys na wiekszej ilosci danych i na wiekszej liczbie userow jak system zacznie ci mulic niemilosiernie. Bo w to ze dasz sie przekonac teraz to juz nie licze.

Zaleta nested set czy IP czy innych stuktur drzewiastych jest to, ze sa szybkie przy odczycie. Twoj skrypt nawet do piet im nie dosiega szybkoscia. Tak, to prawda, jak ktos recznie zacznie gmerac w bazie to szlag to trafi, ale w praktyce nikt nie jest tak glupi by w to wkladac recznie paluchy. Po to sie wlasnie tworzy zarzadzanie tymi strukturami z poziomu panelu zarzadzania a nie bezposrednio na bazie.

Popracujesz kiedys na normalnych projektach z normalnym ruchem to zrozumiesz. Poki co bawisz sie w swojej piaskownicy i myslisz ze odkryles eureke... Do czasu

Jedna dziesiąta sekundy różnicy na tysiącu rekordach to naprawdę takie zamulanie, że szkoda gadać, to Ja nie wiem po co w ogóle są pętle i funkcje i procedury w sql skoro ich używanie tak zamula selecta aż o 0.1 sekundy!!!

Używanie biblioteki do nested set jest za pewne bezpieczne, ale mi się tam nested set nie podoba z przyczyn, które już wcześniej wymieniłem.

Dziecko drogie kochane, skup sie, bo wiecej razy powtarzac nie bede: 1000 rekordow to jest zadna liczba dla bazy. Chocbys mial nie wiem jak skopane zapytanie to dla bazy to jest jak puszczenie baka i tyle. Odpala se to na milionie rekordow to pogadamy.

To bylo po pierwsze.
A po drugie juz ci mowilem: twoje zapytanie powinno zajmowac nie 0.38 a 0.0038. Ale dzis sobota, widze kolega zmeczony

edit:
a, i jeszcze jako praca domowa na niedziele, to pokaz mi zapytanie ktore w twojej cudnej strukturze zwroci mi cale poddrzewo dla elementu o id=15

Pokaż mi aplikację php w której na raz odpalasz milion rekordów i to jeszcze kategorii?

Nie jestem Twoim dzieckiem zdystansuj ziomek.


Jak jesteś ślepy i nie widziałeś screena to nie mój problem.

Nie ma takowej, chyba ze ty taka napiszesz Dlatego zadalem ci prace domowa: pokaz mi zapytanie ktore pobierze subdrzewo dla elemtu o id = 15 Udowodnij, ze nie jestes dziecko

Sam napisales ze twoje zapytanie dla 1000 rekordow wykonuje sie 0.38 czy jakos tak wiec nie wyzywaj mnie od slepcow

Ten screen? http://i.imgur.com/7nkQN6T.png
Nie wiem kto tu potrzebuje okularów

Bo tyle wynosi.




Zastanów się człowieku po co chcesz coś testować na milionie rekordów, skoro nigdy nie będzie to do takich celów wykorzystane...
Ty lepiej sobie zadaj pytanie nad sensem swoich wypowiedzi.

Dlaczego by nie? Tworząc rozwiązanie ono ma działać na każdym zbiorze danych, czy to będzie 1 element czy milion to ma zawsze działać, a nie, że jak przekroczysz jakaś tam magiczna granice to system siądzie, bo autor nie przewidział. Odpal sobie teraz te milion razy 1000 userów którzy pobiorą sobie teraz to drzewko naraz. Dlatego jesteś nadal juniorem bo patrzysz bardzo płasko na swój kod i brak Ci wiedzy i umiejętności. Nie dasz sobie głowy uciąć, że to nawet nie dla miliona a dla jakiegoś innego zbioru wgl w sensownym czasie się wykona.


Owszem pracuje dłużej od Ciebie.
Poczytaj sobie książki mądrych ludzi, blogi uncle boba i innych a potem się wypowiadaj.

i widać jak się nosisz przez to, nie zaakceptowałbyś, że ktoś krócej w branży robi to lepiej od Ciebie

Choćby dlatego, że każde złożone zapytanie używające funkcji będzie dłużej się wykonywać na milionie rekordów niż zwykły select z sortowaniem po kilku polach i to nie tylko dotyczy kategorii, ale różnego rodzaju wyciągania danych, a to, że na milionie rekordów będzie długo to durny argument, który kompletnie nie może sprawiać, że odrzuca się jakieś zapytanie, "bo na milionie rekordów" ...

Jeżeli potrafi się wyciągnąć złożone dane w jednym zapytaniu to już jest sukces, a jak ktoś mówi, że, bo na milionie rekordów.. to nie ma pojęcia o czym mówi.

A czy ja twierdze, że jestem jakimś guru, daleko mi jeszcze do tych wielkich, ale człowiek się ciągle doskonali, za to Ty sorry ale ani stażem, ani doświadczeniem nie dorównujesz nikomu w tym wątku.



Powiedz to architektowi od jakiegokolwiek systemu to powie Ci panie tam są drzwi.

No chyba ze robi się stronę dla cioci



Brawo jesteś najlepszym programista na świecie Zrób literówkę i szukaj igły w stogu siana

Coraz bardziej się tylko pogrążasz.

Kod też można napisać w 1 pliku, poco obiektowość przecież to spowalnia, piszmy proceduralne, bądźmy jak facebook kiedyś

To, że dłużej to robisz, nie znaczy, że lepiej, mimo, że każdym postem starasz mi się to udowodnić...

Zapytania są statyczne, więc jak stworzysz dobre zapytanie to nie ma żadnych literówek, tylko go używasz ile wlezie.

Widać, że jesteś zwolennikiem prostych selectów, ale jakbyś się nauczył złożonych zapytań to byś zrozumiał o czym mówię.

Nigdzie nie twierdziłem, że to że pisze się kod więcej lat oznacza, że w każdym przypadku robi się to lepiej. Można się uczyć od lepszych i czerpać wzorce, można być ignorantem tak jak ty, zwolennikiem własne najlepsze. To działa na krótka metę, za jakiś czas nie będziesz wiedział co ten kod robi. A jak ktoś odziedziczy to po Tobie, to klient usłyszy słynne panie kto panu to tak spie..lił.



Dzisiaj, za 5 dni trzeba będzie coś zmienić, poprawić.



Panie myślisz, że nie pisałem widoków/procedur i innych magii się nie robiło.. Robiło się, tylko jakbyś miał jakieś pojecie to zawsze powinno się eliminować wąskie gardła, takim bez wątpienia jest db.

Jestem zwolennikiem czystego kodu. Który zarazem jest prosty, przejrzysty, łatwo testowalny, samo-dokumentujący się itd.

Jak zaczniesz pracować nad systemami z dużą ilością użytkowników z dużą ilością danych i operacji to zmienisz zdanie...

Ten wątek idealnie pasuje do tego działu

Nwm jak reszta ale chyba już wszyscy się zgodzą że temat można uciąć, autor nadal pozostał ignorantem, życie zweryfikuje kiedyś.

Idź pracować do OLX/Allegro lub Facebooka tam czekają na Ciebie A jak lubisz tak Laravela, to zrób forka i wrzucaj tam swoje innowacje, tak wspaniały umysł to skarb, szkoda żeby się marnował

to do tego co napisał com, dodam tylko, że to że wydaje Ci się, że robisz coś lepiej, nie znaczy że tak jest, mimo że każdym postem starasz się nam to udowodnić

Amen

Amen definitywnie. Piaskownice czas zamknac bo dzieci za duzo piasku zjadly

Acha, czyli wymysliles zajebiste rozwiazanie ale zapomniales dodac ze ono dziala tylko dla paru rekordow. A dla wiekszej liczby rekordow nie ma po co wymyslac czegos lepszego bo nikt inny z twojej piaskownicy nie probowal zbudowac zamku z piasku tylko same babki znaczy ze nikt inny nie buduje zamkow. Brawo, twojej logiki nie da sie podwazyc