Temat: Hinduskie kwiatki :-)

Tam w europie, przy odpowiednich kwalifikcjach w Polsce też można zarobić kilkaset tysięcy zł rocznie bez większego problemu. W indiach jest dokładnie tak samo.

Rozchodzi się o rzeszę nisko wykwalifikowanych pracowników IT z niewielkim doświadczeniem. Typowe rozwizanie to setki wyrobników na wschodzie i małe competency center na zachodzie.

Z Hindusami są pewne problemu kulturowe
1) kastowość społeczeństwa
2) związany z kastowością szeroko rozumiany nepotyzm
3) parcie szybkie awanse - tam jak nie dostaniesz awansu po pół roku to zmieniasz pracę. Ale dostają, co niekonieczie przekłada się na więdzę i doświadczenie.

To im nie pomaga i rzutuje na wizerunek, co nie zmienia faktu że różne babole są robione i na wschodzie i na zachodzie i nie należy się z tego śmiać a edukować.

Temat: Hinduskie kwiatki :-)

przez europe rozumialem tez Polske :) w koncu jestesmy w EU nie :)

Temat: Hinduskie kwiatki :-)

Ten temat jak i temat obok:

Optymalizacja bazy danych mySQL

powinny oba być.

Jednak oba różnią się zawartością merytoryczną.

W pierwszym Szanowni Panowie, zamiast poprowadzić topik jako trivie czyli post kwiatka, post opisu co w kodzie powyżej jest do dupy

przechodzimy od merytorycznej treści w stronę filozofowania o przyczynach ekonomicznych i całym syfie wokół pracy, która z reguły przynosi satysfakcje i pieniądze.

Przemysław R.:

a czego oczekujesz od niewolnika? ze będzie się starał

W topiku obok ktoś kto ma pomysł, a może nie za dużo doświadczeń otrzymuje
garść dobrych wskazówek i wydaje się, że wkrótce będzie jeszcze bardziej zadowolony.

Może by tak, darować sobie personalne wycieczki, i zamiast obśmiewania się, czy rozważania pierdów około-płacowych zrobić z tego topika po prostu trivie?

Co na to moderator?

Post 1 i 13 zostaje, reszta postów idzie to przyklejonego topika na górze pt. co nas wk*** w pracy i jakie są perspektywy?

:D

Temat: Hinduskie kwiatki :-)

Paweł P.:
Co na to moderator?

Pewnie śpi, leń jeden.

Post 1 i 13 zostaje, reszta postów idzie to przyklejonego topika na górze pt. co nas wk*** w pracy i jakie są perspektywy?

Nie ma takiej funkcjonalności żeby podzielić temat :(

Temat: Hinduskie kwiatki :-)

Jak ktos chce poczytac o takich kwiatkach to polecam:
http://thedailywtf.com/

b.

Temat: Hinduskie kwiatki :-)

Mogę podsumować to co najwyżej tak: każdy się kiedyś uczył... :)

Więcej wyrozumiałości, Panowie!

Temat: Hinduskie kwiatki :-)

Racja, lecz jest różnica między nauką strzelania na poligonie a na froncie:) Nie tylko można samemu oberwać, ale zaszkodzić komuś..
Oczywiście wiem po sobie. Czasem jak przeglądam jakiś swój kod sprzed paru lat to... ehem.

Temat: Hinduskie kwiatki :-)

z hinduskich kwiatków:

- cała logika na procedurach składowanych
- transakcja wg nich to select * from albo pojedynczy insert (jedyna operacja na bazie w ramach procedury)
- redundancja danych
- trzymanie po kilka kluczy obcych w jednej kolumnie (komórce) - wartości rozdzielone przecinkami

Temat: Hinduskie kwiatki :-)

Łukasz Schabek:
Racja, lecz jest różnica między nauką strzelania na poligonie a na froncie:) Nie tylko można samemu oberwać, ale zaszkodzić komuś..
Oczywiście wiem po sobie. Czasem jak przeglądam jakiś swój kod sprzed paru lat to... ehem.

A to wszyscy tak mają, nie licząc żyjących legend którzy bajty wypijali z mlekiem matki. Ale jakoś tak to leciało: "zapomniał wół że cielęciem był" ;) Trochę dystansu do wszystkiego Panowie. Każdy kiedyś popełniał błędy, każdy poprawiał kiedyś błędy po kimś. Byłoby pięknie i wspaniale gdyby każda firma miała 100% szczelny system QA, z szefami projektu szczodrze obdarzającymi godzinami na implementację testów... A rzeczywistość sobie;)

Temat: Hinduskie kwiatki :-)

Jan Kosmala:
z hinduskich kwiatków:

- cała logika na procedurach składowanych

A ja tu nie widzę problemu, jak się dało i działało w akceptowalny sposób... Chyba że generowanie interfejsu było robione w sqlu.

Temat: Hinduskie kwiatki :-)

Adam O.:

Jan Kosmala:
z hinduskich kwiatków:

- cała logika na procedurach składowanych

A ja tu nie widzę problemu, jak się dało i działało w akceptowalny sposób... Chyba że generowanie interfejsu było robione w sqlu.

prawdziwy programista brzydzi sie procedurami :)

to takie nie ORM-owe, hmm za to szybkie

Temat: Hinduskie kwiatki :-)

Nie żebym kogoś bronił czy ganił, ale:

Ad zliczania: SQLową funkcję count wykorzystuje się w zapytaniach grupujących i o ile dobrze pamiętam MySQLa, to w zapytaniu SELECT * nie da się użyć count. O jakim liczeniu PHPem mówisz, jeśli o funkcji mysql_num_rows() to jest to jak najbardziej prawidłowe pobranie informacji o ilości wierszy zwróconych przez bazę.

Ad ilość zapytań: o ile dobrze pamiętam, to w MySQLu jest podobnie jak w MSSQLu w kwestii puli połączeń, tzn można zdefiniować ilość połączeń jakie będą cały czas otwarte do bazy i przekazywanie ich do silnika PHP. Ponadto istnieje też funkcja mysql_connect() która otwiera stałe połączenie do bazy. Tak więc strat wydajnościowych nie ma na otwieranie/zamykanie połączeń. Inna kwestia to umiejscowienie logiki przetwarzania, ich wykonanie wydaje mi się nizbyt głupie, bo o ile dobrze zrozumiałem to dla każdego wiersza z tabeli packages jest wybierany jeden wiersz z tabeli repositories. Można oczywiście napisać pojedyńcze zapytanie, stworzyć logikę obrabiania danych w PHP, ale jest jedno ale, zapytanie będzie mało czytelne, kod obrabiający dane też. Tak jest zrobione w możliwie najprostszy sposób i wcale nie mniej wydajny.

Ad konwersji: po czym wnioskujesz, że baza była tworzona w MSAccess i potem konwertowana, bo tu nic takiego nie pokazałeś. Ponadto jeżeli była zrobiona struktura bazy (tabele, kolumny, klucze) i następnie wygenerowanie kodu SQL który to tworzy w MySQL, no cóż, powtórzę się, zrobiono to w możliwie najprostszy sposób. MS Access ma całkiem fajny i przyjazny IDE to takich prac, do MySQL nie ma podobnych narzędzi (nie licząc phpmyadmin, ale może nie ma ichniejszej wersji językowej).

Ad limitowania: nie za bardzo rozumiem o czym tu piszesz, ale jeśli mówimy o jakimś nietypowym pagingu, to cóż, powtórzę się, tak było najprościej.

Podsumowując - hindusi wzorują się w technologiach IT na Amerykanach, a Amerykanie natomiast nie mają wcale ochoty wymyślać skomplikowanych rzeczy, wręcz przeciwnie, robią wszystko w prosty sposób, bo taki jest najlepszy - najłatwiej przeanalizować działanie, wyszukać błędy i je poprawić. My Polaczki natomiast mamy tendencję do maksymalne zwięzłości, ale tym samym skomplikowaniem roboty. Tylko że jak coś po roku lub więcej okazuje się, że trzeba poprawić, to nawet sam autor nie wie, o czym pisał i o co chodziło. Wiem to sam po sobie - kilkukrotnie tworzyłem podobny kod kilka razy, bo przy potrzebie zmian po dłuższym okresie czasu, nie wiedziałem co ja napisałem i gdzie mam wprowadzić zmiany, do czasu aż nauczyłem się tworzyć kod jak naprostszy do napisania, analizowania, poprawiania, modyfikowania.

Pozdrawiam
Marek

PS: Ad procedury składowane: nie rozumiem o co wam chodziło, przecież procedura składowana wykonuje się najwydajniej, bo w procesie serwera bazy, bez konieczności przesyłania danych, pakowania/rozpakowania itd. One są po prostu najwydajniejsze, a programista ma tworzyć wydajny kod.

Krzysztof Eugeniusz Kotkowicz:

Jan Rudnik:
"Uważam po prostu, że selekcja naturalna powinna wykluczać bezmyślnych klepaczy kodu z rynku."
a Tobie Kolego nigdy w zyciu nie zdazylo sie zrobic czegos bezmyslnie? Kazdy popelnia bledy, a najwiecej Ci ktorzy twierdza ze ich nie popelniaja...

Czym innym jest pomyłka, czym innym brak podstaw.

Uważasz za błąd to że programista:
-zlicza ilość rekordów PHPem, a nie funkcją count(*) w SQL?
-tworzy kod, który wykonuje zapytanie, by potem dla każdego wynikowego rekordu tego zapytania wykonać kolejne zapytanie (przy 47 tysiącach rekordów), po czym to samo powtarza 3 razy w kodzie strony (3x47000=141 tysięcy zapytań dla jednego index.php)
-tworzy bazę w MS Access potem konwertuje ją bezmyślnie do mysql.
-Używanie select * from, by potem PHPem limitować ilość wierszy do 50/30/10/1.

Ja nie uważam tego za pomyłki. Ja uważam to za znaczne braki w wiedzy, na temat dziedziny w której się działa.

I zauważ, że jest różnica między "człowiek, który popełnił pomyłkę", a człowiek, który bezmyślnie klepie kod.Marek K. edytował(a) ten post dnia 01.12.11 o godzinie 22:00

Temat: Hinduskie kwiatki :-)

Marek K.:
Nie żebym kogoś bronił czy ganił, ale:

Ad zliczania: SQLową funkcję count wykorzystuje się w zapytaniach grupujących i o ile dobrze pamiętam MySQLa, to w zapytaniu SELECT * nie da się użyć count. O jakim liczeniu PHPem mówisz, jeśli o funkcji mysql_num_rows() to jest to jak najbardziej prawidłowe pobranie informacji o ilości wierszy zwróconych przez bazę.

Cóż. Jeśli ktoś robi:

SELECT * from tabela;

potem robi z tego mysql_num_rows();

to chyba logiczne jest zrobienie select count(*) from tabela;
prawda? A do tego dużo szybsze, bo nie przesyłało powiedzmy stu tysięcy wierszy do PHP by je tylko policzyć.

Ad ilość zapytań: o ile dobrze pamiętam, to w MySQLu jest podobnie jak w MSSQLu w kwestii puli połączeń, tzn można zdefiniować ilość połączeń jakie będą cały czas otwarte do bazy i przekazywanie ich do silnika PHP. Ponadto istnieje też funkcja mysql_connect() która otwiera stałe połączenie do bazy. Tak więc strat wydajnościowych nie ma na otwieranie/zamykanie połączeń.

Nie o tym pisałem.

Inna kwestia to umiejscowienie logiki przetwarzania, ich wykonanie wydaje mi się nizbyt głupie, bo o ile dobrze zrozumiałem to dla każdego wiersza z tabeli packages jest wybierany jeden wiersz z tabeli repositories. Można oczywiście napisać pojedyńcze zapytanie, stworzyć logikę obrabiania danych w PHP, ale jest jedno ale, zapytanie będzie mało czytelne, kod obrabiający dane też. Tak jest zrobione w możliwie najprostszy sposób i wcale nie mniej wydajny.

Masz zapytanie, które pobiera 70 tysięcy wierszy, po czym dla każdego z tych wierzy robi kolejne zapytanie. Uważasz, że ponad 70 tysięcy zapytań, działa tak samo sprawnie niż jedno, ale z JOINem? No ja nie wiedziałem, że 6 sek. to nie mniej wydajnie niż 0.01 sek.

Ad konwersji: po czym wnioskujesz, że baza była tworzona w MSAccess i potem konwertowana, bo tu nic takiego nie pokazałeś. Ponadto jeżeli była zrobiona struktura bazy (tabele, kolumny, klucze) i następnie wygenerowanie kodu SQL który to tworzy w MySQL, no cóż, powtórzę się, zrobiono to w możliwie najprostszy sposób. MS Access ma całkiem fajny i przyjazny IDE to takich prac, do MySQL nie ma podobnych narzędzi (nie licząc phpmyadmin, ale może nie ma ichniejszej wersji językowej).

MS Access jest fajny do biura. Nie nadaje się do tworzenia wydajnego kodu MySQL. Tyle. Sprawdzone wielokrotnie.

Ad limitowania: nie za bardzo rozumiem o czym tu piszesz, ale jeśli mówimy o jakimś nietypowym pagingu, to cóż, powtórzę się, tak było najprościej.

Nieprawda. Najprościej jest SELECT * FROM tabela LIMIT 30, a nie SELECT * FROM tabela, a potem limitować to PHPem.

Podsumowując - hindusi wzorują się w technologiach IT na Amerykanach, a Amerykanie natomiast nie mają wcale ochoty wymyślać skomplikowanych rzeczy, wręcz przeciwnie, robią wszystko w prosty sposób, bo taki jest najlepszy - najłatwiej przeanalizować działanie, wyszukać błędy i je poprawić.

Nieprawda. Błędy wspomniane powyżej, to typowe, szkolne błędy. Błędy bardzo negatywnie wpływające na wydajność aplikacji. Które potem trzeba poprawić. To nie prostota, to głupota.

My Polaczki natomiast mamy tendencję do maksymalne zwięzłości, ale tym samym skomplikowaniem roboty. Tylko że jak coś po roku lub więcej okazuje się, że trzeba poprawić, to nawet sam autor nie wie, o czym pisał i o co chodziło. Wiem to sam po sobie - kilkukrotnie tworzyłem podobny kod kilka razy, bo przy potrzebie zmian po dłuższym okresie czasu, nie wiedziałem co ja napisałem i gdzie mam wprowadzić zmiany, do czasu aż nauczyłem się tworzyć kod jak naprostszy do napisania, analizowania, poprawiania, modyfikowania.

Jeśli taki, jak w Twoich kontrprzykładach, to współczuję.

PS: Ad procedury składowane: nie rozumiem o co wam chodziło, przecież procedura składowana wykonuje się najwydajniej, bo w procesie serwera bazy, bez konieczności przesyłania danych, pakowania/rozpakowania itd. One są po prostu najwydajniejsze, a programista ma tworzyć wydajny kod.

Twoje kontrprzykłady nie były wydajne.

Temat: Hinduskie kwiatki :-)

Z Polaczkami to kolega przesadza, ja się czuję Polakiem, i nie chcę być obrażany w żaden sposób.

Co do Amerykanów - tak, oni zawsze piszą najlepiej, najprościej i najszybciej, i dlatego powstał taki serwis jak TheDailyWTF, który stawia pomnik tej niebywałej programistycznej sprawności;)

BTW, bez sensu się ta rozmowa robi, może zmienimy temat na np obśmiewanie http://thedailywtf.com/Articles/Directive-595.aspx

albo jeszcze lepiej, wbijmy się masowo na jakieś forum programistyczne i trollujmy o tym że ORMów używają tylko ludzie zbyt leniwi do nauki sqla;)

Temat: Hinduskie kwiatki :-)

Adam O.:
Z Polaczkami to kolega przesadza, ja się czuję Polakiem, i nie chcę być obrażany w żaden sposób.

Co do Amerykanów - tak, oni zawsze piszą najlepiej, najprościej i najszybciej, i dlatego powstał taki serwis jak TheDailyWTF, który stawia pomnik tej niebywałej programistycznej sprawności;)

Wiesz, bo oni są tacy fajni, tacy amełykańscy. BPNMSP :D

Temat: Hinduskie kwiatki :-)

Krzysztof Eugeniusz Kotkowicz:

Nie są. Ja nie programuję, nie koduję, nie robię nic wspólnego z PHPem i nie biorę zleceń, na przygotowanie jakiegokolwiek skryptu, bo się po prostu na tym nie znam. I co lepsze, są to tak podstawowe błędy, że mimo, iż nie programuję w PHP, to wyłapuję je od razu i jestem w stanie poprawić, najczęściej w ramach zleceń na optymalizację pracy serwera. Konkurencja, która przysparza mi zleceń na ok. 100-200$/godz. raczej nie jest moją konkurencją.

Czy na starcie "kariery" też kolega był nieomylny?
Zawsze robił wszystko najlepiej, najbezpieczniej i zoptymalizowane?

Ważne jest aby wyciągać wnioski z błędów i starać się pisać coraz lepiej.

Temat: Hinduskie kwiatki :-)

Sebastian S.:

Krzysztof Eugeniusz Kotkowicz:
Nie są. Ja nie programuję, nie koduję, nie robię nic wspólnego z PHPem i nie biorę zleceń, na przygotowanie jakiegokolwiek skryptu, bo się po prostu na tym nie znam. I co lepsze, są to tak podstawowe błędy, że mimo, iż nie programuję w PHP, to wyłapuję je od razu i jestem w stanie poprawić, najczęściej w ramach zleceń na optymalizację pracy serwera. Konkurencja, która przysparza mi zleceń na ok. 100-200$/godz. raczej nie jest moją konkurencją.

Czy na starcie "kariery" też kolega był nieomylny?
Zawsze robił wszystko najlepiej, najbezpieczniej i zoptymalizowane?

Oczywiście, że nie. Jednakże pierwszy włamywacz na serwerze administrowanym przeze mnie był jak na razie ostatnim. Było to 11 lat temu, gdy klient uparł się przy dziurawym, starym Mandrake'u. Natomiast błędy wymienione przeze mnie są popełniane przez ludzi, którzy mają za sobą nie mniej niż 50 zrealizowanych zleceń i naprawdę dobre oceny na serwisie zleceniowym.

Ważne jest aby wyciągać wnioski z błędów i starać się pisać coraz lepiej.

Dokładnie. Niestety - gdy skontaktowałem się z "autorami" dwóch najpoważniejszych tutaj błędów, to jeden stwierdził, że o co mi chodzi, skoro działa, po prostu serwer trzeba szybszy, a drugi nie miał czasu. Tyle.

Poza tym masz przykład sprzed godziny - kolega z grupy upierał się, że błędne rozwiązania są dobre, bo są przecież proste. Zamiast wyciągnąć z tego wnioski, że ktoś bardziej doświadczony pisze, że jednak były złe.Krzysztof Eugeniusz Kotkowicz edytował(a) ten post dnia 01.12.11 o godzinie 23:08

Temat: Hinduskie kwiatki :-)

Krzysztof Eugeniusz Kotkowicz:

Marek K.:
Nie żebym kogoś bronił czy ganił, ale:

Ad zliczania: SQLową funkcję count wykorzystuje się w zapytaniach grupujących i o ile dobrze pamiętam MySQLa, to w zapytaniu SELECT * nie da się użyć count. O jakim liczeniu PHPem mówisz, jeśli o funkcji mysql_num_rows() to jest to jak najbardziej prawidłowe pobranie informacji o ilości wierszy zwróconych przez bazę.

Cóż. Jeśli ktoś robi:

SELECT * from tabela;

potem robi z tego mysql_num_rows();

to chyba logiczne jest zrobienie select count(*) from tabela;
prawda? A do tego dużo szybsze, bo nie przesyłało powiedzmy stu tysięcy wierszy do PHP by je tylko policzyć.

Z dokumentacji MySQL:
mysql> SELECT COUNT(*) FROM student;

This optimization applies only to MyISAM tables only, because an exact row count is stored for this storage engine and can be accessed very quickly. For transactional storage engines such as InnoDB, storing an exact row count is more problematic because multiple transactions may be occurring, each of which may affect the count.

Ad ilość zapytań: o ile dobrze pamiętam, to w MySQLu jest...

Nie o tym pisałem.

Inna kwestia to umiejscowienie logiki przetwarzania, ich...

Masz zapytanie, które pobiera 70 tysięcy wierszy, po czym dla każdego z tych wierzy robi kolejne zapytanie. Uważasz, że ponad 70 tysięcy zapytań, działa tak samo sprawnie niż jedno, ale z JOINem? No ja nie wiedziałem, że 6 sek. to nie mniej wydajnie niż 0.01 sek.

Czy zrobiłeś pomiary? Faktycznie zapytanie z JOINem będzie może szybsze (w końcu baza będzie musiała zrobić złączenie tabel i przefiltrowanie), ale czy nie będzie przypadkiem skomplikowane. To nie takie hop siup zrobić zapytanie ze złączeniem plus wybieranie pojedyńczych wartości dla tego złączenia.

Ad konwersji: po czym wnioskujesz, że baza była tworzona w...

MS Access jest fajny do biura. Nie nadaje się do tworzenia wydajnego kodu MySQL. Tyle. Sprawdzone wielokrotnie.

O jakim kodzie MySQL mówimy? Ja napisałem tylko o strukturze bazy danych, a do tego MS Access się świetnie nadaje, w przeciwieństwie do innych baz danych.

Ad limitowania: nie za bardzo rozumiem o czym tu piszesz, ale...

Nieprawda. Najprościej jest SELECT * FROM tabela LIMIT 30, a nie SELECT * FROM tabela, a potem limitować to PHPem.

Nie zawsze, zajrzyj do dokumentacji MySQL, tam jest sporo na ten temat napisane oraz o przypadkach joinów, transakcji itp. Powtórzę się, w pewnych przypadkach lepiej zrobić własny paging.

Podsumowując - hindusi wzorują się w technologiach IT na ...

Nieprawda. Błędy wspomniane powyżej, to typowe, szkolne błędy. Błędy bardzo negatywnie wpływające na wydajność aplikacji. Które potem trzeba poprawić. To nie prostota, to głupota.

To by była pusta polemika więc przemilczę.

My Polaczki natomiast mamy tendencję do maksymalne ...

Jeśli taki, jak w Twoich kontrprzykładach, to współczuję.

JW

PS: Ad procedury składowane: nie rozumiem o co wam chodziło, ...

Twoje kontrprzykłady nie były wydajne.

JW

I jeszcze jedno pytanie: Czy wiesz jak działa współpraca PHP z MySQL, a dokładniej kiedy jest wysyłanie zapytań, przesyłanie danych itp? Jeśli nie, to zachęcam do pogłębienia wiedzy w tym zakresie.Marek K. edytował(a) ten post dnia 01.12.11 o godzinie 23:33

Temat: Hinduskie kwiatki :-)

Krzysztof Eugeniusz Kotkowicz:
Dokładnie. Niestety - gdy skontaktowałem się z "autorami" dwóch najpoważniejszych tutaj błędów, to jeden stwierdził, że o co mi chodzi, skoro działa, po prostu serwer trzeba szybszy, a drugi nie miał czasu. Tyle.

Czy jest sens to roztrząsać? Nigdy nie będzie idealnie, zawsze trafi się jakiś "kwiatek". Taka nasza praca - mamy rozwiązywać problemy.Sebastian S. edytował(a) ten post dnia 01.12.11 o godzinie 23:35

Temat: Hinduskie kwiatki :-)

Marek K.:
Z dokumentacji MySQL:
mysql> SELECT COUNT(*) FROM student;

This optimization applies only to MyISAM tables only, because an exact row count is stored for this storage engine and can be accessed very quickly. For transactional storage engines such as InnoDB, storing an exact row count is more problematic because multiple transactions may be occurring, each of which may affect the count.

A czy ktoś mówił o tym, że tabela nie była tabelą MyISAM? Jakkolwiek liczenie ilości wierszy PHPem dla samego tylko ich policzenia, by potem ponownie wykonać podobne zapytanie nie jest dobre. A w tym konkretnym przykładzie, nawet gdyby tabela była tabelą InnoDB, błąd o kilka wierszy byłby dopuszczalny. I to programista ma taką sytuację ocenić.

Czy zrobiłeś pomiary? Faktycznie zapytanie z JOINem będzie może szybsze (w końcu baza będzie musiała zrobić złączenie tabel i przefiltrowanie), ale czy nie będzie przypadkiem skomplikowane. To nie takie hop siup zrobić zapytanie ze złączeniem plus wybieranie pojedyńczych wartości dla tego złączenia.

Zostałem zatrudniony, by tą sytuację naprawić. Bo index.php zadawał 141 tysięcy zapytań do bazy. Czy potrafisz mi podać przykład, gdy 141 tysięcy zapytań do bazy będzie szybsze, niż dobrze napisane trzy zapytania? Ponownie - to programista ma wiedzieć, jak napisać dobrze zapytanie. Hop, siup, to jest jego działka, a nie administratora serwera.

MS Access jest fajny do biura. Nie nadaje się do tworzenia wydajnego kodu MySQL. Tyle. Sprawdzone wielokrotnie.

O jakim kodzie MySQL mówimy? Ja napisałem tylko o strukturze bazy danych, a do tego MS Access się świetnie nadaje, w przeciwieństwie do innych baz danych.

O tym, że MS Access defaultowo proponuje używanie "select * from VIEW 'x'", o czym wspomniałem wcześniej, a widoki w MySQL są obsługiwane tragicznie wolno.

Nieprawda. Najprościej jest SELECT * FROM tabela LIMIT 30, a nie SELECT * FROM tabela, a potem limitować to PHPem.

Nie zawsze, zajrzyj do dokumentacji MySQL, tam jest sporo na ten temat napisane oraz o przypadkach joinów, transakcji itp. Powtórzę się, w pewnych przypadkach lepiej zrobić własny paging.

Chcesz mi powiedzieć, że transakcje w toku będą miały wpływ na "SELECT * FROM tabela LIMIT 30", natomiast na "SELECT * FROM tabela" już nie?

Podsumowując - hindusi wzorują się w technologiach IT na ...

Nieprawda. Błędy wspomniane powyżej, to typowe, szkolne błędy. Błędy bardzo negatywnie wpływające na wydajność aplikacji. Które potem trzeba poprawić. To nie prostota, to głupota.

To by była pusta polemika więc przemilczę.

A Twoje stwierdzenie już pustą polemiką nie było?

I jeszcze jedno pytanie: Czy wiesz jak działa współpraca PHP z MySQL, a dokładniej kiedy jest wysyłanie zapytań, przesyłanie danych itp? Jeśli nie, to zachęcam do pogłębienia wiedzy w tym zakresie.

Tak wiem - jak na razie, to Ty wykazujesz się brakiem wiedzy w tym zakresie.