🚀 go-pugleaf

On 2019-04-25, Marek S <precz@spamowi.com> wrote:

>> Nie, nie, nie, nie. Nie zrozumiałeś. To co napisałem to:
>> Zamiast przyspieszyć _moze_ 2x procesy w bazie np. przez dołożenie trigerów,
>> wolę mieć opcję stabilnej obsługi zarówno 10, 100 jak i 1000+ userów "na raz")
>> bez straty wydajności, w zależności od potrzeb, przez auto-skalowalne rozwiązania.
>
> Ok, czuję intencję.
> BTW
> Jak tworzysz podkreślenia? Próbowałem _ przed i za, próbowałem __ i 
> kiszka. Być może więcej wyrazowych wyrażeniach próbowałem. Nie pamiętam już.

Przez dodanie _ na początku i na końcu wyrazu (bez spacji).

>>> Ja preferuję inne podejście:
>>> zoptymalizować bazę, a gdy już więcej się nie da - wtedy zająć się
>>> infrastrukturą sprzętową. Tego nie zmienię w sobie.
>> 
>> No i właśnie. Projektujesz system który "ma ścianę" i to dość blisko.
>
> Czy jest coś w tym nagannego, że z wyciskam z serwera max. ilość 
> operacji/s?

Wygląda jak klasyczna niepotrzebna optymalizacja.
Zamieniasz też " na ', żeby zyskać 2 sekundy czasu serwera w rok?

> Może inaczej: proponujesz pousuwać wszelkie optymalizacje z 
> bazy, jak np. indeksy, po to by być daleko od ściany i mieć świadomość, 
> że można dużo poprawić w tejże bazie?

Wszysktie? Nie. Nadmiarowe, stworzone "na wszelki wypadek"? Tak.
To co robisz nosi wszelkie znamiona premature optimization i unnecessary 
optimization. Niby jest wydajnej, ale różnicy nikt tak realnie nie zobaczy,
a Ty tracisz na tym czas.

>> Problem w tym, że na razie "beztroski" to wydajesz się Ty, w angażowaniu
>> ORMa bez zrozumienia idei za nim stojących.
>
> Nie beztroski lecz uczący się. Jednakże już w tym wątku dostałem 
> wytyczne jak "naprawić" ideę ORM w zakresie usuwania/aktualizacji 
> rekordów poprzez banalnie proste zabiegi na udostępnionych przez ORM 
> mechanizmach. Mam na myśli łatanie niedostatków poprzez stosowanie 
> querybuildera etc.

Query builder *nie* jest żadnym łataniem, ani też żadnym SQLem.
Jest narzędziem do budowania zapytań.
Jak chciałbyś odpytywać bazę inaczej?
Nie wszystko na bazie sprowadza się do robienia pojedynczych zapytań
i działania na pojedynczych obiektach.

>>> To ja wiem. To jest korzystanie z SQLa, do którego z awersją podchodzisz
>>> r=traktując go jako raka w ORMie.
>> 
>> Gdzie Ty tam widzisz SQL? o.O
>> To jest wg Ciebie SQL?
>> ---
>> $qb = $em->createQueryBuilder();
>> $qb->delete('Services', 's');
>> $qb->where('s.project = :project');
>> $qb->setParameter('project', $project);
>> ---
>
> Kompletnie nie znam querybuildera a widzę (być może fałszywie) to, co 
> poniżej. Zgaduję, że Services odnosi się do nazwy entity a ta do tabeli 
> o tej samej nazwie. Więc:
>
> "DELETE FROM services s WHERE s.project=$project"

No nie. Query builder zbuduje zapytanie DQL:
https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/reference/dql-doctrine-query-language.html

Uwalnie Ciebie od znajomości struktury (nazw kolumn kluczy, nazw tabeli),
bo sam to ogarnia na podstawie otworzonej przez Ciebie relacji z obiektami
Entities.

A potem ten DQL zostanie przetworzony na coś w stylu:
DELETE FROM services s WHERE s.project_id = " . $project->getId(); // jeśli $project to obiekt
DELETE FROM services s WHERE s.project_id = " . $project; // jeśli $project to prymityw (liczba lub string)

ale już bez Twojego udziału.
Ale tak g gdzieś ostatecznie pod spodem jest wynik w postaci SQL.
Przecież musi być, bazy danych inaczej nie gadają.

Zauważ, że:
 - nie znasz tej nazwy tabeli (doctrine sam ją "ogarnia"
   na podstawie tego jak zdefiniowałeś entity)
 - do $project wstawiasz obiekt entity lub id, a doctrine
   sam sobie poradzi z tym by to miało dla niego sens
   sam też zna nazwę kolumny, na podstawie relacji jaka
   była utworzona w entity

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com