Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > pl.comp.lang.php > #15646 > unrolled thread

Dobre praktyki

Started byRoman Tyczka <noemail@because.no>
First post2018-01-18 13:37 +0100
Last post2018-01-25 20:36 +0100
Articles 20 on this page of 51 — 8 participants

Back to article view | Back to pl.comp.lang.php


Contents

  Dobre praktyki Roman Tyczka <noemail@because.no> - 2018-01-18 13:37 +0100
    Re: Dobre praktyki Lemat <#@lemat.priv.pl> - 2018-01-18 18:30 +0100
      Re: Dobre praktyki Marek S <precz@spamowi.com> - 2018-01-25 20:31 +0100
        Re: Dobre praktyki Lemat <#@lemat.priv.pl> - 2018-01-25 20:44 +0100
          Re: Dobre praktyki Marek S <precz@spamowi.com> - 2018-01-25 20:48 +0100
            Re: Dobre praktyki Roman Tyczka <noemail@because.no> - 2018-01-25 21:22 +0100
              Re: Dobre praktyki Marek S <precz@spamowi.com> - 2018-01-25 23:55 +0100
                Re: Dobre praktyki Lemat <#@lemat.priv.pl> - 2018-01-26 05:48 +0100
                  Re: Dobre praktyki Marek S <precz@spamowi.com> - 2018-01-26 13:48 +0100
              Re: Dobre praktyki Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-01-26 00:02 +0100
                Re: Dobre praktyki Roman Tyczka <noemail@because.no> - 2018-01-26 23:16 +0100
                  Re: Dobre praktyki Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-01-27 13:09 +0100
                    Re: Dobre praktyki Borys Pogoreło <borys@pl.edu.leszno> - 2018-01-27 23:04 +0100
                      Re: Dobre praktyki Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-01-27 23:07 +0100
                        Re: Dobre praktyki Borys Pogoreło <borys@pl.edu.leszno> - 2018-01-27 23:22 +0100
                        Re: Dobre praktyki Borys Pogoreło <borys@pl.edu.leszno> - 2018-01-27 23:31 +0100
            Re: Dobre praktyki artiun <artiun@spam.wp.pl> - 2018-01-26 00:06 +0100
    Re: Dobre praktyki denat 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2018-01-18 20:03 +0100
    Re: Dobre praktyki Rafal Podsiadly <spinacz24@gmail.com> - 2018-01-21 05:03 -0800
      Re: Dobre praktyki Roman Tyczka <noemail@because.no> - 2018-01-21 22:38 +0100
      Re: Dobre praktyki Borys Pogoreło <borys@pl.edu.leszno> - 2018-01-22 21:56 +0100
        Re: Dobre praktyki Rafal Podsiadly <spinacz24@gmail.com> - 2018-01-24 08:16 -0800
          Re: Dobre praktyki Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-01-24 17:20 +0100
            Re: Dobre praktyki Rafal Podsiadly <spinacz24@gmail.com> - 2018-01-24 21:30 -0800
              Re: Dobre praktyki Marek S <precz@spamowi.com> - 2018-01-25 20:46 +0100
              Re: Dobre praktyki Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-01-25 21:10 +0100
                Re: Dobre praktyki Marek S <precz@spamowi.com> - 2018-01-26 00:03 +0100
                  Re: Dobre praktyki Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-01-26 00:26 +0100
                    Re: Dobre praktyki Marek S <precz@spamowi.com> - 2018-01-26 14:00 +0100
                      Re: Dobre praktyki Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-01-27 13:05 +0100
                        Re: Dobre praktyki Marek S <precz@spamowi.com> - 2018-01-27 13:40 +0100
                          Re: Dobre praktyki Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-01-27 14:49 +0100
                            Re: Dobre praktyki Marek S <precz@spamowi.com> - 2018-01-27 19:04 +0100
                              Re: Dobre praktyki Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-01-27 20:35 +0100
                                Re: Dobre praktyki Marek S <precz@spamowi.com> - 2018-01-27 21:59 +0100
                                  Re: Dobre praktyki Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-01-27 23:02 +0100
                                    Re: Dobre praktyki Marek S <precz@spamowi.com> - 2018-01-27 23:35 +0100
                                      Re: Dobre praktyki Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-01-28 00:24 +0100
                          Re: Dobre praktyki Borys Pogoreło <borys@pl.edu.leszno> - 2018-01-27 22:49 +0100
                            Re: Dobre praktyki Marek S <precz@spamowi.com> - 2018-01-27 23:08 +0100
                              Re: Dobre praktyki Borys Pogoreło <borys@pl.edu.leszno> - 2018-01-27 23:26 +0100
                                Re: Dobre praktyki Marek S <precz@spamowi.com> - 2018-01-27 23:56 +0100
                                  Re: Dobre praktyki Borys Pogoreło <borys@pl.edu.leszno> - 2018-01-28 00:34 +0100
          Re: Dobre praktyki Roman Tyczka <noemail@because.no> - 2018-01-24 20:29 +0100
            Re: Dobre praktyki Rafal Podsiadly <spinacz24@gmail.com> - 2018-01-24 21:51 -0800
            Re: Dobre praktyki Borys Pogoreło <borys@pl.edu.leszno> - 2018-01-27 22:43 +0100
              Re: Dobre praktyki Roman Tyczka <noemail@because.no> - 2018-01-29 08:48 +0100
                Re: Dobre praktyki Borys Pogoreło <borys@pl.edu.leszno> - 2018-01-30 20:37 +0100
          Re: Dobre praktyki Borys Pogoreło <borys@pl.edu.leszno> - 2018-01-27 22:45 +0100
            Re: Dobre praktyki Rafal Podsiadly <spinacz24@gmail.com> - 2018-01-28 07:08 -0800
      Re: Dobre praktyki Marek S <precz@spamowi.com> - 2018-01-25 20:36 +0100

Page 1 of 3  [1] 2 3  Next page →


#15646 — Dobre praktyki

FromRoman Tyczka <noemail@because.no>
Date2018-01-18 13:37 +0100
SubjectDobre praktyki
Message-ID<2lhebv1xabri$.dlg@tyczka.com>
Może rozruszam tę grupę ;-)

Mam pytanie o dobre praktyki w PHP. Chodzi mi szczególnie o kardynalne
błędy, które wpływają na spadek wydajności działania skryptu. Na codzień
programuję w Delphi i takich rzeczy jest sporo, które nawet nie całkiem
początkujący ignorują, a które potrafią dramatycznie rzutować na wydajność.
Przykładem jest przekazywanie stringów czy tablic przez wartość a nie
referencję, co skutkuje alokacją i kopiowaniem pamięci a to proces
czasochłonny.

Czy moglibyście wypunktować kilka takich bad practicies dla PHP?

-- 
pozdrawiam
Roman Tyczka

[toc] | [next] | [standalone]


#15648

FromLemat <#@lemat.priv.pl>
Date2018-01-18 18:30 +0100
Message-ID<5a60d9c0$0$587$65785112@news.neostrada.pl>
In reply to#15646
W dniu 18.01.2018 o 13:37, Roman Tyczka pisze:
> 
> Może rozruszam tę grupę ;-)
> 
> Mam pytanie o dobre praktyki w PHP. Chodzi mi szczególnie o kardynalne
> błędy, które wpływają na spadek wydajności działania skryptu. Na codzień
> programuję w Delphi i takich rzeczy jest sporo, które nawet nie całkiem
> początkujący ignorują, a które potrafią dramatycznie rzutować na wydajność.
> Przykładem jest przekazywanie stringów czy tablic przez wartość a nie
> referencję, co skutkuje alokacją i kopiowaniem pamięci a to proces
> czasochłonny.
> 
> Czy moglibyście wypunktować kilka takich bad practicies dla PHP?
> 

- includowanie kodu, który nigdy (podczas tego wywołania) się nie wykona
- przechowywanie kodu poza plikami php i wykonywanie przez eval()
- brak zwalniania pamięci po pracy z dużymi danymi
- przenoszenie do PHP logiki bazy danych np. JOIN tabel, klauzula WHERE
- brak keszowania fragmentów strony wynikowej mp.
menu - zmieni się wtedy gdy administrator je zmieni raz na ruski rok. 
Ale strona (a zatem menu) zostanie pobrana wielokrotnie. Gdyby HTML 
odpowiedzialny za menu został wygenerowany tuż po zmianie w CMSie to 
każde wywołanie strony oszczędzi czas procka pobierając dane z kesza a 
nie wywołując procedury generowania menu.

- stosowanie nieodpowiednich systemów przechowywania danych - obrazki w 
bazie danych, dane w CSV w pliku.

-- 
Pozdrawiam
Lemat

[toc] | [prev] | [next] | [standalone]


#15669

FromMarek S <precz@spamowi.com>
Date2018-01-25 20:31 +0100
Message-ID<p4dbb2$aqf$1@node2.news.atman.pl>
In reply to#15648
W dniu 18-01-2018 o 18:30, Lemat pisze:

> - przenoszenie do PHP logiki bazy danych np. JOIN tabel, klauzula WHERE

Zainteresował mnie ten punkt. Możesz go rozwinąć? Czy chodzi oto aby nie 
robić czegoś takiego jak:

$sql="SELECT ... JOIN / WHERE";
$bazaDanych->execute($sql);

Jeśli tak, to w jaki sposób budujesz zapytania do bazy typu PostgreSQL 
(moja ulubiona) lub podobna, wykonujesz je i zwracasz do PHP wyniki? 
Zakładam w pytaniu, że projekt jest dużo bardziej złożony niż zadanie 5 
na krzyż niemodyfikowalnych zapytań SQL do bazy.

-- 
Pozdrawiam,
Marek

[toc] | [prev] | [next] | [standalone]


#15671

FromLemat <#@lemat.priv.pl>
Date2018-01-25 20:44 +0100
Message-ID<5a6a338d$0$591$65785112@news.neostrada.pl>
In reply to#15669
W dniu 25.01.2018 o 20:31, Marek S pisze:
> W dniu 18-01-2018 o 18:30, Lemat pisze:
> 
>> - przenoszenie do PHP logiki bazy danych np. JOIN tabel, klauzula WHERE
> 
> Zainteresował mnie ten punkt. Możesz go rozwinąć? Czy chodzi oto 

nie.
Wręcz przeciwnie.

-- 
Pozdrawiam
Lemat

[toc] | [prev] | [next] | [standalone]


#15673

FromMarek S <precz@spamowi.com>
Date2018-01-25 20:48 +0100
Message-ID<p4dca5$bid$2@node2.news.atman.pl>
In reply to#15671
W dniu 25-01-2018 o 20:44, Lemat pisze:
> W dniu 25.01.2018 o 20:31, Marek S pisze:
>> W dniu 18-01-2018 o 18:30, Lemat pisze:
>>
>>> - przenoszenie do PHP logiki bazy danych np. JOIN tabel, klauzula WHERE
>>
>> Zainteresował mnie ten punkt. Możesz go rozwinąć? Czy chodzi oto 
> 
> nie.
> Wręcz przeciwnie.

Ok, to na czym ten błąd przenoszenia logiki bazy do PHP miałby polegać? 
Jakiś przykład?

-- 
Pozdrawiam,
Marek

[toc] | [prev] | [next] | [standalone]


#15675

FromRoman Tyczka <noemail@because.no>
Date2018-01-25 21:22 +0100
Message-ID<14g5fh47ji3uk.dlg@tyczka.com>
In reply to#15673
On Thu, 25 Jan 2018 20:48:16 +0100, Marek S wrote:

>>>> - przenoszenie do PHP logiki bazy danych np. JOIN tabel, klauzula WHERE
>>>
>>> Zainteresował mnie ten punkt. Możesz go rozwinąć? Czy chodzi oto 
>> 
>> nie.
>> Wręcz przeciwnie.
> 
> Ok, to na czym ten błąd przenoszenia logiki bazy do PHP miałby polegać? 
> Jakiś przykład?


Chodzi chyba o to, żeby nie targać całej tabeli do pamięci i dopiero po
stronie klienta (tu skryptu php) filtrować dane. To co prawda szalony
pomysł, ale pewnie są i tacy patenciarze ;-)


-- 
pozdrawiam
Roman Tyczka

[toc] | [prev] | [next] | [standalone]


#15677

FromMarek S <precz@spamowi.com>
Date2018-01-25 23:55 +0100
Message-ID<p4dn8r$d4m$1@node1.news.atman.pl>
In reply to#15675
W dniu 25-01-2018 o 21:22, Roman Tyczka pisze:

> 
> Chodzi chyba o to, żeby nie targać całej tabeli do pamięci i dopiero po
> stronie klienta (tu skryptu php) filtrować dane. To co prawda szalony
> pomysł, ale pewnie są i tacy patenciarze ;-)

eeee... jakoś nie dowierzam, że o to mogłoby chodzić Lematowi. Brzmi to 
trochę za bardzo przekombinowanie :-D

-- 
Pozdrawiam,
Marek

[toc] | [prev] | [next] | [standalone]


#15684

FromLemat <#@lemat.priv.pl>
Date2018-01-26 05:48 +0100
Message-ID<5a6ab314$0$668$65785112@news.neostrada.pl>
In reply to#15677
W dniu 25.01.2018 o 23:55, Marek S pisze:
> W dniu 25-01-2018 o 21:22, Roman Tyczka pisze:
> 
>>
>> Chodzi chyba o to, żeby nie targać całej tabeli do pamięci i dopiero po
>> stronie klienta (tu skryptu php) filtrować dane. To co prawda szalony
>> pomysł, ale pewnie są i tacy patenciarze ;-)
> 
> eeee... jakoś nie dowierzam, że o to mogłoby chodzić Lematowi. Brzmi to 
> trochę za bardzo przekombinowanie :-D
> 

niedowiarek...
A ja znam osobiście takich programistów, którzy się na tym sparzyli.

-- 
Pozdrawiam
Lemat

[toc] | [prev] | [next] | [standalone]


#15685

FromMarek S <precz@spamowi.com>
Date2018-01-26 13:48 +0100
Message-ID<p4f82l$sic$2@node1.news.atman.pl>
In reply to#15684
W dniu 26-01-2018 o 05:48, Lemat pisze:
> 
> niedowiarek...
> A ja znam osobiście takich programistów, którzy się na tym sparzyli.

To jestem pod wrażeniem :-)

-- 
Pozdrawiam,
Marek

[toc] | [prev] | [next] | [standalone]


#15678

FromWojciech Bancer <wojciech.bancer@gmail.com>
Date2018-01-26 00:02 +0100
Message-ID<slrnp6kof8.30gj.wojciech.bancer@pl-test.org>
In reply to#15675
On 2018-01-25, Roman Tyczka <noemail@because.no> wrote:

[...]

> Chodzi chyba o to, żeby nie targać całej tabeli do pamięci i dopiero po
> stronie klienta (tu skryptu php) filtrować dane. To co prawda szalony
> pomysł, ale pewnie są i tacy patenciarze ;-)

Czyli każdy ORM z lazy-loadingiem?

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

[toc] | [prev] | [next] | [standalone]


#15687

FromRoman Tyczka <noemail@because.no>
Date2018-01-26 23:16 +0100
Message-ID<1pk1ib81txiyp$.dlg@tyczka.com>
In reply to#15678
On Fri, 26 Jan 2018 00:02:00 +0100, Wojciech Bancer wrote:

>> Chodzi chyba o to, żeby nie targać całej tabeli do pamięci i dopiero po
>> stronie klienta (tu skryptu php) filtrować dane. To co prawda szalony
>> pomysł, ale pewnie są i tacy patenciarze ;-)
> 
> Czyli każdy ORM z lazy-loadingiem?

Jeśli znasz ORMa, który ściąga całą tabelę, żeby wyjąć z niej jeden wiersz
to zastrzel jego autora ;-)
A lazy loading... domyślam się o co Ci może chodzić, że ORM żeby zrobić
powiązanie między obiektami musi wczytać kilka tabel, ...ale dobry
framework ORM potrafi generować JOINy na poziomie zapytań i nie musi
ściągać do tego całych tabel na klienta. Nie wiem jakie ORMy są w świecie
php, bo zasadniczo nie przepadam za ORMami, ale w Javie, .NET czy w Delphi
ORMy potrafią inteligentnie tworzyć zapytania i wykorzystywać możliwości
SQLa.

-- 
pozdrawiam
Roman Tyczka

[toc] | [prev] | [next] | [standalone]


#15690

FromWojciech Bancer <wojciech.bancer@gmail.com>
Date2018-01-27 13:09 +0100
Message-ID<slrnp6oqvj.g5g.wojciech.bancer@pl-test.org>
In reply to#15687
On 2018-01-26, Roman Tyczka <noemail@because.no> wrote:
> On Fri, 26 Jan 2018 00:02:00 +0100, Wojciech Bancer wrote:
>
>>> Chodzi chyba o to, żeby nie targać całej tabeli do pamięci i dopiero po
>>> stronie klienta (tu skryptu php) filtrować dane. To co prawda szalony
>>> pomysł, ale pewnie są i tacy patenciarze ;-)
>> 
>> Czyli każdy ORM z lazy-loadingiem?
>
> Jeśli znasz ORMa, który ściąga całą tabelę, żeby wyjąć z niej jeden wiersz
> to zastrzel jego autora ;-)

Znam ORMa który ściągnie to co chcesz z głównego obiektu, a następnie jak 
sobie już sobie iterujesz po obiektach będących odwołaniami do innych 
tabel, to radośnie ściąga je pojedynczo, czyli defacto robi ręcznego 
joina.

Na pewno Propel i Doctrine postępują wg metody jak wyżej.
Widziałeś ORMa działającego inaczej?

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

[toc] | [prev] | [next] | [standalone]


#15702

FromBorys Pogoreło <borys@pl.edu.leszno>
Date2018-01-27 23:04 +0100
Message-ID<1wblk1av0e74a$.wb9w9nkyczvr.dlg@40tude.net>
In reply to#15690
Dnia Sat, 27 Jan 2018 13:09:23 +0100, Wojciech Bancer napisał(a):

> Znam ORMa który ściągnie to co chcesz z głównego obiektu, a następnie jak 
> sobie już sobie iterujesz po obiektach będących odwołaniami do innych 
> tabel, to radośnie ściąga je pojedynczo, czyli defacto robi ręcznego 
> joina.
> 
> Na pewno Propel i Doctrine postępują wg metody jak wyżej.
> Widziałeś ORMa działającego inaczej?

Eloquent z Laravela może na wejściu dostać "hinta" with(...) z czym dane
będą w przyszłości wiązane. Wówczas potrafi zbudować takie zapytanie, które
wrzuci w cache od razu więcej danych i przyszłe zapytania nawet nie dotkną
bazy.

Potrafi też przy iteracji grupować identyfikatory i wysłać do bazy jedno
"IN (...)".

Całkiem nieźle to działa.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

[toc] | [prev] | [next] | [standalone]


#15703

FromWojciech Bancer <wojciech.bancer@gmail.com>
Date2018-01-27 23:07 +0100
Message-ID<slrnp6pu11.q0u.wojciech.bancer@pl-test.org>
In reply to#15702
On 2018-01-27, Borys Pogoreło <borys@pl.edu.leszno> wrote:
> Dnia Sat, 27 Jan 2018 13:09:23 +0100, Wojciech Bancer napisał(a):
>
>> Znam ORMa który ściągnie to co chcesz z głównego obiektu, a następnie jak 
>> sobie już sobie iterujesz po obiektach będących odwołaniami do innych 
>> tabel, to radośnie ściąga je pojedynczo, czyli defacto robi ręcznego 
>> joina.
>> 
>> Na pewno Propel i Doctrine postępują wg metody jak wyżej.
>> Widziałeś ORMa działającego inaczej?
>
> Eloquent z Laravela może na wejściu dostać "hinta" with(...) z czym dane
> będą w przyszłości wiązane. Wówczas potrafi zbudować takie zapytanie, które
> wrzuci w cache od razu więcej danych i przyszłe zapytania nawet nie dotkną
> bazy.

To mi przypomina rozwiązania z Propela 1.x :)
Faktycznie było to fajnie, chociaż propel miał swoje ogromne minusy
(metody statyczne do obsługi zapytań baz danych).

Laravel też chyba na statykach jedzie, z tego co pamiętam?

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

[toc] | [prev] | [next] | [standalone]


#15705

FromBorys Pogoreło <borys@pl.edu.leszno>
Date2018-01-27 23:22 +0100
Message-ID<18tjyb48yyc1n.16jpg8j169v57.dlg@40tude.net>
In reply to#15703
Dnia Sat, 27 Jan 2018 23:07:29 +0100, Wojciech Bancer napisał(a):

> To mi przypomina rozwiązania z Propela 1.x :)
> Faktycznie było to fajnie, chociaż propel miał swoje ogromne minusy
> (metody statyczne do obsługi zapytań baz danych).

Propela za bardzo nie znam. Wieki temu go macałem.

> Laravel też chyba na statykach jedzie, z tego co pamiętam?

Nie, jedynie w przypadku ręcznego pisania zapytań w stylu DB::select(...).
Query builder jest obiektowy, eloquent tak samo. Ale jest bardzo ściśle
powiązany z resztą frameworka, także może być trudno skorzystać poza nim.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

[toc] | [prev] | [next] | [standalone]


#15707

FromBorys Pogoreło <borys@pl.edu.leszno>
Date2018-01-27 23:31 +0100
Message-ID<cd2m5pf7kta7$.3bjriv197ldm.dlg@40tude.net>
In reply to#15703
Dnia Sat, 27 Jan 2018 23:07:29 +0100, Wojciech Bancer napisał(a):

> Laravel też chyba na statykach jedzie, z tego co pamiętam?

Ach, pytasz generalnie o Laravela. Nie do końca. Twórca wymyślił sobie coś,
co nazwał fasadą i działa to tak, że wywołanie statyczne jest
przekształcane w wywołanie kontenera IoC. Czyli pisząc DB::table() tak
naprawdę wołasz app('db')->table(). Społeczność jest mocno podzielona w
sprawie tego rozwiązania i nie dziwię się temu. Ale nie trzeba z tego
korzystać.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

[toc] | [prev] | [next] | [standalone]


#15681

Fromartiun <artiun@spam.wp.pl>
Date2018-01-26 00:06 +0100
Message-ID<5a6a64e3$0$1678$65785112@news.neostrada.pl>
In reply to#15673
W dniu 2018-01-25 o 20:48, Marek S pisze:
> W dniu 25-01-2018 o 20:44, Lemat pisze:
>> W dniu 25.01.2018 o 20:31, Marek S pisze:
>>> W dniu 18-01-2018 o 18:30, Lemat pisze:
>>>
>>>> - przenoszenie do PHP logiki bazy danych np. JOIN tabel, klauzula WHERE
>>>
>>> Zainteresował mnie ten punkt. Możesz go rozwinąć? Czy chodzi oto 
>>
>> nie.
>> Wręcz przeciwnie.
> 
> Ok, to na czym ten błąd przenoszenia logiki bazy do PHP miałby polegać? 
> Jakiś przykład?
> 
Wszystko zależy. Czasem nie dasz rady. To wygląda tak, dostałem zlecenie na 
zrobienie ornungu w bazie. Miałem założyć triggery (służące utrzymaniu 
porządku między tabelami). Zrobiłem na developerskiej bazie, przyszedł czas 
na wdrożenie, wszyscy dostali papiery z opisem zależności. Nie minęło 2h i 
gość przyłazi "Do bazy nic nie mogę dopisać" ???!!!!
Z innej mańki, baza ma swoją logikę, dane są rozrzucane i zapisywane w 
różnych tabelach. Nie próbuj tego łamać na siłę, powinieneś dostać 
procedury/funkcje, które realizują logikę bazy.
Żeby załapać co wymyślili w Insert (MS SQL) zeszło mi z miesiąc, choć w 
bazie na żywca nie odważyłem się grzebać :)

-- 
Artur

[toc] | [prev] | [next] | [standalone]


#15649

Fromdenat 'POPIS/EU <NOSPAMtestowanije@go2.pl>
Date2018-01-18 20:03 +0100
Message-ID<p3qr2f$1k3$1@node1.news.atman.pl>
In reply to#15646
fajne to pytanie
to pytanie z cyklu "jak lepiej zoptymalizować na etapie pisania programu 
  zamiast zwalić to na kompilator" - wiele łbów na politechnice na tym 
poległo...

[toc] | [prev] | [next] | [standalone]


#15656

FromRafal Podsiadly <spinacz24@gmail.com>
Date2018-01-21 05:03 -0800
Message-ID<6d0bd754-9b46-46ce-98ff-c5265a9a93af@googlegroups.com>
In reply to#15646
Dobre praktyki. (1 -5) załatwiają frameworki 

1. Projekt opieraj o klasy i obiekty.
2. Wykorzystuj metody magiczne __autoload (automatyczne ładowanie klas podczas ich wywołania)
3. Wykorzystuj zmienne statyczne w stałych plikach (ograniczysz kopiowanie zmiennych).
4. Poznaj różnicę między przekazaniem argumentu do funkcji a argumentu do metody (klasa w funkcji) 
5. Ograniczaj używanie zmiennych globalnych do minimum. 
6. W metodach buduj gettery i settery a zmienne dawaj do private.


Poznaj PSR-1/2/3 -> to standard (hardcorowcy idą do 7 :)

[toc] | [prev] | [next] | [standalone]


#15660

FromRoman Tyczka <noemail@because.no>
Date2018-01-21 22:38 +0100
Message-ID<1p8x8la6msc28.dlg@tyczka.com>
In reply to#15656
On Sun, 21 Jan 2018 05:03:14 -0800 (PST), Rafal Podsiadly wrote:

> 2. Wykorzystuj metody magiczne __autoload (automatyczne ładowanie klas podczas ich wywołania)

Właśnie trafiłem na notkę w opisie:


Warning

This feature has been DEPRECATED as of PHP 7.2.0. Relying on this feature
is highly discouraged.


-- 
pozdrawiam
Roman Tyczka

[toc] | [prev] | [next] | [standalone]


Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | pl.comp.lang.php


csiph-web