Witaj Gościu! ( Zaloguj | Rejestruj )

Forum PHP.pl

272 Stron V   1 2 3 > » 

phpion
Napisane: 18.04.2022, 22:26:09





Grupa: Moderatorzy
Postów: 6 070
Dołączył: 10.12.2003
Skąd: Dąbrowa Górnicza



Skoro EA jest taki prosty i milusi i oszczędza czas i pieniądze to dlaczego przez ponad 2 tygodnie nie zrobiłeś tej wyszukiwarki? Większość ogarniętych programistów już dawno by to zrobiła pracując na narzędziu, które zna. W pełni zgadzam się z @aras785:
Cytat
Teraz walczysz z narzędziem zamiast skupiać się na rozwiązywaniu problemów biznesowych.

Problem w tym, że nie kombinujesz JAK zrobić taką wyszukiwarkę tylko kombinujesz JAK ją zrobić W EA. Pytasz czy są jakieś bundle/dodatki, które to zrobią. Nie ma? No to zaczynają się schody. Pamiętam jak w Symfony 1 też podniecałem się generatorem admina. Do momentu, gdy trzeba było zrobić coś niekonwencjonalnego...

PS: Klient/szef zapewne zareaguje euforią gdy mu pokażesz jak szybciutko stawiasz prostego CRUDa. Ciekawe jednak jak zareaguje gdy przyjdzie do Ciebie i powie "potrzebuję to zrobić tak i tak", a Ty mu na to "ale w EA tak się nie da, musi to działać tak".
  Forum: Frameworki · Podgląd postu: #1258774 · Odpowiedzi: 7 · Wyświetleń: 2 321

phpion
Napisane: 23.03.2022, 22:46:55





Grupa: Moderatorzy
Postów: 6 070
Dołączył: 10.12.2003
Skąd: Dąbrowa Górnicza



Mamy zrzucone wszystkie zapytania bezpośrednio z bazy. To co się dzieje w tej akcji wywołuje łącznie 54 zapytań (mało, nie mało - to aplikacja wewnętrzna nie narażona na duży ruch):
Kod
        39628 Query    START TRANSACTION
        39628 Query    SELECT t0.id AS id_1, t0.name AS name_2, t0.description AS description_3, t0.redirect AS redirect_4 FROM cms_role t0 INNER JOIN prpo_message_receiver ON t0.id = prpo_message_receiver.cms_role_id WHERE prpo_message_receiver.prpo_message_type_id = 6
        39628 Query    SELECT c0_.id AS id_0, c0_.lang AS lang_1, c0_.username AS username_2, c0_.email AS email_3, c0_.password AS password_4, c0_.active AS active_5, c0_.logged AS logged_6, c0_.passwordChangeRequired AS passwordChangeRequired_7, c0_.lastPasswordChange AS lastPasswordChange_8, c0_.dev AS dev_9, c0_.send_mail_on_dev AS send_mail_on_dev_10, c0_.id AS id_11 FROM cms_auth c0_ INNER JOIN user_point u1_ ON (u1_.user_id = c0_.id) INNER JOIN cms_auth_role c2_ ON (c2_.cms_auth_id = c0_.id) WHERE c0_.active = '1' AND u1_.point_id IN (436) AND c2_.cms_role_id IN (7, 19, 84, 133, 222, 223, 236)
        39628 Query    SELECT c0_.id AS id_0, c0_.lang AS lang_1, c0_.username AS username_2, c0_.email AS email_3, c0_.password AS password_4, c0_.active AS active_5, c0_.logged AS logged_6, c0_.passwordChangeRequired AS passwordChangeRequired_7, c0_.lastPasswordChange AS lastPasswordChange_8, c0_.dev AS dev_9, c0_.send_mail_on_dev AS send_mail_on_dev_10, c0_.id AS id_11 FROM cms_auth c0_ INNER JOIN cms_auth_role c1_ ON (c1_.cms_auth_id = c0_.id) WHERE c0_.active = '1' AND c1_.cms_role_id = 236
        39628 Query    SELECT t0.id AS id_1, t0.is_open AS is_open_2, t0.created_at AS created_at_3, t0.updated_at AS updated_at_4, t0.blocked_at AS blocked_at_5, t0.last_block_activity_at AS last_block_activity_at_6, t0.sender_id AS sender_id_7, t0.updated_by_id AS updated_by_id_8, t0.blocked_by_id AS blocked_by_id_9, t0.prpo_message_type_id AS prpo_message_type_id_10 FROM prpo_message t0 INNER JOIN prpo_receiver ON t0.id = prpo_receiver.prpo_message_id WHERE prpo_receiver.cms_auth_id = 253
        39628 Query    SELECT t0.id AS id_1, t0.is_open AS is_open_2, t0.created_at AS created_at_3, t0.updated_at AS updated_at_4, t0.blocked_at AS blocked_at_5, t0.last_block_activity_at AS last_block_activity_at_6, t0.sender_id AS sender_id_7, t0.updated_by_id AS updated_by_id_8, t0.blocked_by_id AS blocked_by_id_9, t0.prpo_message_type_id AS prpo_message_type_id_10 FROM prpo_message t0 INNER JOIN prpo_receiver ON t0.id = prpo_receiver.prpo_message_id WHERE prpo_receiver.cms_auth_id = 726
220322  9:36:32    39628 Query    SELECT t0.id AS id_1, t0.is_open AS is_open_2, t0.created_at AS created_at_3, t0.updated_at AS updated_at_4, t0.blocked_at AS blocked_at_5, t0.last_block_activity_at AS last_block_activity_at_6, t0.sender_id AS sender_id_7, t0.updated_by_id AS updated_by_id_8, t0.blocked_by_id AS blocked_by_id_9, t0.prpo_message_type_id AS prpo_message_type_id_10 FROM prpo_message t0 INNER JOIN prpo_receiver ON t0.id = prpo_receiver.prpo_message_id WHERE prpo_receiver.cms_auth_id = 818
        39628 Query    SELECT t0.id AS id_1, t0.is_open AS is_open_2, t0.created_at AS created_at_3, t0.updated_at AS updated_at_4, t0.blocked_at AS blocked_at_5, t0.last_block_activity_at AS last_block_activity_at_6, t0.sender_id AS sender_id_7, t0.updated_by_id AS updated_by_id_8, t0.blocked_by_id AS blocked_by_id_9, t0.prpo_message_type_id AS prpo_message_type_id_10 FROM prpo_message t0 INNER JOIN prpo_receiver ON t0.id = prpo_receiver.prpo_message_id WHERE prpo_receiver.cms_auth_id = 865
        39628 Query    SELECT t0.id AS id_1, t0.is_open AS is_open_2, t0.created_at AS created_at_3, t0.updated_at AS updated_at_4, t0.blocked_at AS blocked_at_5, t0.last_block_activity_at AS last_block_activity_at_6, t0.sender_id AS sender_id_7, t0.updated_by_id AS updated_by_id_8, t0.blocked_by_id AS blocked_by_id_9, t0.prpo_message_type_id AS prpo_message_type_id_10 FROM prpo_message t0 INNER JOIN prpo_receiver ON t0.id = prpo_receiver.prpo_message_id WHERE prpo_receiver.cms_auth_id = 2009
        39628 Query    SELECT t0.id AS id_1, t0.is_open AS is_open_2, t0.created_at AS created_at_3, t0.updated_at AS updated_at_4, t0.blocked_at AS blocked_at_5, t0.last_block_activity_at AS last_block_activity_at_6, t0.sender_id AS sender_id_7, t0.updated_by_id AS updated_by_id_8, t0.blocked_by_id AS blocked_by_id_9, t0.prpo_message_type_id AS prpo_message_type_id_10 FROM prpo_message t0 INNER JOIN prpo_receiver ON t0.id = prpo_receiver.prpo_message_id WHERE prpo_receiver.cms_auth_id = 2740
        39628 Query    SELECT t0.id AS id_1, t0.is_open AS is_open_2, t0.created_at AS created_at_3, t0.updated_at AS updated_at_4, t0.blocked_at AS blocked_at_5, t0.last_block_activity_at AS last_block_activity_at_6, t0.sender_id AS sender_id_7, t0.updated_by_id AS updated_by_id_8, t0.blocked_by_id AS blocked_by_id_9, t0.prpo_message_type_id AS prpo_message_type_id_10 FROM prpo_message t0 INNER JOIN prpo_receiver ON t0.id = prpo_receiver.prpo_message_id WHERE prpo_receiver.cms_auth_id = 3324
        39628 Query    SELECT t0.id AS id_1, t0.is_open AS is_open_2, t0.created_at AS created_at_3, t0.updated_at AS updated_at_4, t0.blocked_at AS blocked_at_5, t0.last_block_activity_at AS last_block_activity_at_6, t0.sender_id AS sender_id_7, t0.updated_by_id AS updated_by_id_8, t0.blocked_by_id AS blocked_by_id_9, t0.prpo_message_type_id AS prpo_message_type_id_10 FROM prpo_message t0 INNER JOIN prpo_receiver ON t0.id = prpo_receiver.prpo_message_id WHERE prpo_receiver.cms_auth_id = 3421
220322  9:36:33    39628 Query    SELECT t0.id AS id_1, t0.is_open AS is_open_2, t0.created_at AS created_at_3, t0.updated_at AS updated_at_4, t0.blocked_at AS blocked_at_5, t0.last_block_activity_at AS last_block_activity_at_6, t0.sender_id AS sender_id_7, t0.updated_by_id AS updated_by_id_8, t0.blocked_by_id AS blocked_by_id_9, t0.prpo_message_type_id AS prpo_message_type_id_10 FROM prpo_message t0 INNER JOIN prpo_receiver ON t0.id = prpo_receiver.prpo_message_id WHERE prpo_receiver.cms_auth_id = 3923
        39628 Query    SELECT t0.id AS id_1, t0.is_open AS is_open_2, t0.created_at AS created_at_3, t0.updated_at AS updated_at_4, t0.blocked_at AS blocked_at_5, t0.last_block_activity_at AS last_block_activity_at_6, t0.sender_id AS sender_id_7, t0.updated_by_id AS updated_by_id_8, t0.blocked_by_id AS blocked_by_id_9, t0.prpo_message_type_id AS prpo_message_type_id_10 FROM prpo_message t0 INNER JOIN prpo_receiver ON t0.id = prpo_receiver.prpo_message_id WHERE prpo_receiver.cms_auth_id = 4021
        39628 Query    SELECT t0.id AS id_1, t0.is_open AS is_open_2, t0.created_at AS created_at_3, t0.updated_at AS updated_at_4, t0.blocked_at AS blocked_at_5, t0.last_block_activity_at AS last_block_activity_at_6, t0.sender_id AS sender_id_7, t0.updated_by_id AS updated_by_id_8, t0.blocked_by_id AS blocked_by_id_9, t0.prpo_message_type_id AS prpo_message_type_id_10 FROM prpo_message t0 INNER JOIN prpo_receiver ON t0.id = prpo_receiver.prpo_message_id WHERE prpo_receiver.cms_auth_id = 4434
        39628 Query    SELECT t0.id AS id_1, t0.is_open AS is_open_2, t0.created_at AS created_at_3, t0.updated_at AS updated_at_4, t0.blocked_at AS blocked_at_5, t0.last_block_activity_at AS last_block_activity_at_6, t0.sender_id AS sender_id_7, t0.updated_by_id AS updated_by_id_8, t0.blocked_by_id AS blocked_by_id_9, t0.prpo_message_type_id AS prpo_message_type_id_10 FROM prpo_message t0 INNER JOIN prpo_receiver ON t0.id = prpo_receiver.prpo_message_id WHERE prpo_receiver.cms_auth_id = 4850
        39628 Query    SELECT t0.id AS id_1, t0.is_open AS is_open_2, t0.created_at AS created_at_3, t0.updated_at AS updated_at_4, t0.blocked_at AS blocked_at_5, t0.last_block_activity_at AS last_block_activity_at_6, t0.sender_id AS sender_id_7, t0.updated_by_id AS updated_by_id_8, t0.blocked_by_id AS blocked_by_id_9, t0.prpo_message_type_id AS prpo_message_type_id_10 FROM prpo_message t0 INNER JOIN prpo_receiver ON t0.id = prpo_receiver.prpo_message_id WHERE prpo_receiver.cms_auth_id = 5707
        39628 Query    SELECT t0.id AS id_1, t0.is_open AS is_open_2, t0.created_at AS created_at_3, t0.updated_at AS updated_at_4, t0.blocked_at AS blocked_at_5, t0.last_block_activity_at AS last_block_activity_at_6, t0.sender_id AS sender_id_7, t0.updated_by_id AS updated_by_id_8, t0.blocked_by_id AS blocked_by_id_9, t0.prpo_message_type_id AS prpo_message_type_id_10 FROM prpo_message t0 INNER JOIN prpo_receiver ON t0.id = prpo_receiver.prpo_message_id WHERE prpo_receiver.cms_auth_id = 6162
        39628 Query    SELECT t0.id AS id_1, t0.is_open AS is_open_2, t0.created_at AS created_at_3, t0.updated_at AS updated_at_4, t0.blocked_at AS blocked_at_5, t0.last_block_activity_at AS last_block_activity_at_6, t0.sender_id AS sender_id_7, t0.updated_by_id AS updated_by_id_8, t0.blocked_by_id AS blocked_by_id_9, t0.prpo_message_type_id AS prpo_message_type_id_10 FROM prpo_message t0 INNER JOIN prpo_receiver ON t0.id = prpo_receiver.prpo_message_id WHERE prpo_receiver.cms_auth_id = 6204


Podzielone na 2 wpisy bo się burzyło, że wpis jest za długi.

I dalsza część logu zapytań:
Kod
220322  9:36:34    39628 Query    SELECT t0.id AS id_1, t0.is_open AS is_open_2, t0.created_at AS created_at_3, t0.updated_at AS updated_at_4, t0.blocked_at AS blocked_at_5, t0.last_block_activity_at AS last_block_activity_at_6, t0.sender_id AS sender_id_7, t0.updated_by_id AS updated_by_id_8, t0.blocked_by_id AS blocked_by_id_9, t0.prpo_message_type_id AS prpo_message_type_id_10 FROM prpo_message t0 INNER JOIN prpo_receiver ON t0.id = prpo_receiver.prpo_message_id WHERE prpo_receiver.cms_auth_id = 6265
        39628 Query    SELECT t0.id AS id_1, t0.is_open AS is_open_2, t0.created_at AS created_at_3, t0.updated_at AS updated_at_4, t0.blocked_at AS blocked_at_5, t0.last_block_activity_at AS last_block_activity_at_6, t0.sender_id AS sender_id_7, t0.updated_by_id AS updated_by_id_8, t0.blocked_by_id AS blocked_by_id_9, t0.prpo_message_type_id AS prpo_message_type_id_10 FROM prpo_message t0 INNER JOIN prpo_receiver ON t0.id = prpo_receiver.prpo_message_id WHERE prpo_receiver.cms_auth_id = 6353
        39628 Query    SELECT t0.id AS id_1, t0.is_open AS is_open_2, t0.created_at AS created_at_3, t0.updated_at AS updated_at_4, t0.blocked_at AS blocked_at_5, t0.last_block_activity_at AS last_block_activity_at_6, t0.sender_id AS sender_id_7, t0.updated_by_id AS updated_by_id_8, t0.blocked_by_id AS blocked_by_id_9, t0.prpo_message_type_id AS prpo_message_type_id_10 FROM prpo_message t0 INNER JOIN prpo_receiver ON t0.id = prpo_receiver.prpo_message_id WHERE prpo_receiver.cms_auth_id = 7521
        39628 Query    SELECT t0.id AS id_1, t0.is_open AS is_open_2, t0.created_at AS created_at_3, t0.updated_at AS updated_at_4, t0.blocked_at AS blocked_at_5, t0.last_block_activity_at AS last_block_activity_at_6, t0.sender_id AS sender_id_7, t0.updated_by_id AS updated_by_id_8, t0.blocked_by_id AS blocked_by_id_9, t0.prpo_message_type_id AS prpo_message_type_id_10 FROM prpo_message t0 INNER JOIN prpo_receiver ON t0.id = prpo_receiver.prpo_message_id WHERE prpo_receiver.cms_auth_id = 7928
        39628 Query    SELECT t0.id AS id_1, t0.is_open AS is_open_2, t0.created_at AS created_at_3, t0.updated_at AS updated_at_4, t0.blocked_at AS blocked_at_5, t0.last_block_activity_at AS last_block_activity_at_6, t0.sender_id AS sender_id_7, t0.updated_by_id AS updated_by_id_8, t0.blocked_by_id AS blocked_by_id_9, t0.prpo_message_type_id AS prpo_message_type_id_10 FROM prpo_message t0 INNER JOIN prpo_receiver ON t0.id = prpo_receiver.prpo_message_id WHERE prpo_receiver.cms_auth_id = 10516
        39628 Query    SELECT t0.id AS id_1, t0.is_open AS is_open_2, t0.created_at AS created_at_3, t0.updated_at AS updated_at_4, t0.blocked_at AS blocked_at_5, t0.last_block_activity_at AS last_block_activity_at_6, t0.sender_id AS sender_id_7, t0.updated_by_id AS updated_by_id_8, t0.blocked_by_id AS blocked_by_id_9, t0.prpo_message_type_id AS prpo_message_type_id_10 FROM prpo_message t0 INNER JOIN prpo_receiver ON t0.id = prpo_receiver.prpo_message_id WHERE prpo_receiver.cms_auth_id = 10520
        39628 Query    SELECT t0.id AS id_1, t0.is_open AS is_open_2, t0.created_at AS created_at_3, t0.updated_at AS updated_at_4, t0.blocked_at AS blocked_at_5, t0.last_block_activity_at AS last_block_activity_at_6, t0.sender_id AS sender_id_7, t0.updated_by_id AS updated_by_id_8, t0.blocked_by_id AS blocked_by_id_9, t0.prpo_message_type_id AS prpo_message_type_id_10 FROM prpo_message t0 INNER JOIN prpo_receiver ON t0.id = prpo_receiver.prpo_message_id WHERE prpo_receiver.cms_auth_id = 10528
        39628 Query    SELECT t0.id AS id_1, t0.is_open AS is_open_2, t0.created_at AS created_at_3, t0.updated_at AS updated_at_4, t0.blocked_at AS blocked_at_5, t0.last_block_activity_at AS last_block_activity_at_6, t0.sender_id AS sender_id_7, t0.updated_by_id AS updated_by_id_8, t0.blocked_by_id AS blocked_by_id_9, t0.prpo_message_type_id AS prpo_message_type_id_10 FROM prpo_message t0 INNER JOIN prpo_receiver ON t0.id = prpo_receiver.prpo_message_id WHERE prpo_receiver.cms_auth_id = 10881
220322  9:36:35    39628 Query    INSERT INTO prpo_message (is_open, created_at, updated_at, blocked_at, last_block_activity_at, sender_id, updated_by_id, blocked_by_id, prpo_message_type_id) VALUES (1, '2022-03-22 08:36:31', NULL, NULL, NULL, 253, 253, NULL, 6)
        39628 Query    INSERT INTO prpo_message_point (prpo_message_id, point_id) VALUES (16814, 436)
        39628 Query    INSERT INTO prpo_receiver (cms_auth_id, prpo_message_id) VALUES (253, 16814)
        39628 Query    INSERT INTO prpo_receiver (cms_auth_id, prpo_message_id) VALUES (726, 16814)
        39628 Query    INSERT INTO prpo_receiver (cms_auth_id, prpo_message_id) VALUES (818, 16814)
        39628 Query    INSERT INTO prpo_receiver (cms_auth_id, prpo_message_id) VALUES (865, 16814)
        39628 Query    INSERT INTO prpo_receiver (cms_auth_id, prpo_message_id) VALUES (2009, 16814)
        39628 Query    INSERT INTO prpo_receiver (cms_auth_id, prpo_message_id) VALUES (2740, 16814)
        39628 Query    INSERT INTO prpo_receiver (cms_auth_id, prpo_message_id) VALUES (3324, 16814)
        39628 Query    INSERT INTO prpo_receiver (cms_auth_id, prpo_message_id) VALUES (3421, 16814)
        39628 Query    INSERT INTO prpo_receiver (cms_auth_id, prpo_message_id) VALUES (3923, 16814)
        39628 Query    INSERT INTO prpo_receiver (cms_auth_id, prpo_message_id) VALUES (4021, 16814)
        39628 Query    INSERT INTO prpo_receiver (cms_auth_id, prpo_message_id) VALUES (4434, 16814)
        39628 Query    INSERT INTO prpo_receiver (cms_auth_id, prpo_message_id) VALUES (4850, 16814)
        39628 Query    INSERT INTO prpo_receiver (cms_auth_id, prpo_message_id) VALUES (5707, 16814)
        39628 Query    INSERT INTO prpo_receiver (cms_auth_id, prpo_message_id) VALUES (6162, 16814)
        39628 Query    INSERT INTO prpo_receiver (cms_auth_id, prpo_message_id) VALUES (6204, 16814)
        39628 Query    INSERT INTO prpo_receiver (cms_auth_id, prpo_message_id) VALUES (6265, 16814)
        39628 Query    INSERT INTO prpo_receiver (cms_auth_id, prpo_message_id) VALUES (6353, 16814)
        39628 Query    INSERT INTO prpo_receiver (cms_auth_id, prpo_message_id) VALUES (7521, 16814)
        39628 Query    INSERT INTO prpo_receiver (cms_auth_id, prpo_message_id) VALUES (7928, 16814)
        39628 Query    INSERT INTO prpo_receiver (cms_auth_id, prpo_message_id) VALUES (10516, 16814)
        39628 Query    INSERT INTO prpo_receiver (cms_auth_id, prpo_message_id) VALUES (10520, 16814)
        39628 Query    INSERT INTO prpo_receiver (cms_auth_id, prpo_message_id) VALUES (10528, 16814)
        39628 Query    INSERT INTO prpo_receiver (cms_auth_id, prpo_message_id) VALUES (10881, 16814)
        39628 Query    INSERT INTO prpo_message_limit_shift_f12 (sender_communicate, iska_limit, sender_limit, sender_duration, receiver_limit, receiver_duration, receiver_communicate, receiver_editor_id, receiver_decision_id, prpo_message_id) VALUES ('Bardzo proszę o zwiększenie limitu Shift F12. Powodem zmiany limitu jest […]', NULL, 350, 'month_end', NULL, NULL, NULL, NULL, NULL, 16814)
        39628 Query    COMMIT
  Forum: Frameworki · Podgląd postu: #1258459 · Odpowiedzi: 2 · Wyświetleń: 1 771

phpion
Napisane: 23.03.2022, 12:34:39





Grupa: Moderatorzy
Postów: 6 070
Dołączył: 10.12.2003
Skąd: Dąbrowa Górnicza



Witam,
mam problem z Symfony 4.4 + PHP 7.4 i zużyciem pamięci. Jest formularz z kilkoma polami i w momencie jego wysłania serwer wyrzuca błąd 502 lub symfoniową stronę błędu (różnie). Błąd tyczy przekroczenia pamięci w klasie ContextListener.

W kodzie kontrolera obslugującego formularz jest:
  1. $this->addFlash('success', 'Wysłano komunikat');
  2. return $this->redirectToRoute('prpo_msg_list');

i z tego co zdiagnozowałem to wiadomość flash prawidłowo się zapisuje (więc wcześniejszy kod wykonuje się prawidłowo), dopiero potem rzucany jest błąd. Jeśli w tym momencie wywołam adres spod trasy 'prpo_msg_list' to wczytuje się on prawidłowo + widzę dodany wcześniej komunikat flash.

Zrobiłem też inny test. Lokalnie podniosłem limit pamięci dla tej akcji do 1024M i zakomentowałem linijkę z przekierowaniem. W efekcie akcja post się wykonuje ale nie następuje przekierowanie więc mogę zobaczyć profiler. W momencie wczytania pustego formularza zużycie pamięci pokazywane przez profiler waha się w granicach 20-40MB (co odświeżenie różna wartość), natomiast po wysłaniu formularza postem wynosi... 400MB.

Wyświetlając informacje z profilera Symfony widzę, że największy wzrost pamięci odnotowywany jest w debug.security.authorization.vote (skok o kilkaset mega).

Idąc dalej: przekroczenie pamięci następuje w klasie ContextListener w linii:
  1. $session->set($this->sessionKey, serialize($token));

Zrzuciłem sobie zawartość $token na ekran i zauważyłem, że obiekt użytkownika zawiera m.in. wszystkie wiadomości (krótkie tekstowo, ilość ok. 20 więc bez szału) i poszedłem w tym kierunku. W encji widzę:

  1. /**
  2.   * @var \Doctrine\Common\Collections\Collection
  3.   *
  4.   * @ORM\ManyToMany(targetEntity="App\Module\PricesPolicy\Entity\PrpoMessage", inversedBy="receivers")
  5.   * @ORM\JoinTable(name="prpo_receiver",
  6.   * joinColumns={
  7.   * @ORM\JoinColumn(name="cms_auth_id", referencedColumnName="id")
  8.   * },
  9.   * inverseJoinColumns={
  10.   * @ORM\JoinColumn(name="prpo_message_id", referencedColumnName="id")
  11.   * }
  12.   * )
  13.   */
  14. private $prpoMessage;

Samo dojście do wyświetlenia dumpu $tokena zajmuje ok. 40 sekund. W momencie gdy zakomentuję fragment związany z @ORM\JoinTable są to 3 sekundy. No ale usunięcie tego fragmentu powoduje kolejne błędy w aplikacji.

Czy ktoś z Was spotkał się z takim zjawiskiem? Gdzie szukać przyczyny tak ogromnego zużycia pamięci?
  Forum: Frameworki · Podgląd postu: #1258436 · Odpowiedzi: 2 · Wyświetleń: 1 771

phpion
Napisane: 13.07.2021, 23:37:34





Grupa: Moderatorzy
Postów: 6 070
Dołączył: 10.12.2003
Skąd: Dąbrowa Górnicza



Witam po dłuższej przerwie.

Mam pewien problem, może ktoś będzie w stanie coś doradzić. Mam triggera na tabeli X postawionego AFTER UPDATE. Czasami (bo nie zawsze, nie ma reguły) wykonanie polecenia UPDATE na tabeli X i kolumnach ujętych w triggerze (m.in. warunek IF) powoduje zerwanie połączenia z bazą (MySQL server has gone away). Metodą "zakomentuj frament -> uruchom" doszedłem do tego, że winny jest SELECT wewnątrz triggera, który odpytuje tą samą tabelę. Po jego usunięciu ok. 30 prób wykonania UPDATE przebiega bez problemu, gdy SELECT jest w triggerze to połączenie jest zrywane czasem za 3, czasem za 5, czasem za 9 wywołaniem pod rząd - nie ma zasady, jest w zasadzie losowość. Samo polecenie UPDATE wykonuje się szybko zarówno w momencie gdy wykonuje się prawidłowo, jak i gdy zrywa połączenie (komunikat jest od razu).

Testy przeprowadzałem w phpMyAdmin klikając w kółko: SQL -> wklej zapytanie -> wykonaj, SQL -> wklej... więc nie było to testowane na zasadzie pętli tylko ręcznie. Testowe zapytanie było na zasadzie UPDATE X SET pole = 1 WHERE id = 123; gdzie trigger odpala w sobie SELECTa jeśli NEW.pole = 1.

Podsumowując:
- trigger na tabeli X,
- wewnątrz triggera SELECT na tabeli X,
- czasem zrywanie połączenia z bazą, czasem nie.

Czy ktoś spotkał się z podobnym przypadkiem?
  Forum: MySQL · Podgląd postu: #1256218 · Odpowiedzi: 1 · Wyświetleń: 2 587

phpion
Napisane: 13.09.2020, 08:51:46





Grupa: Moderatorzy
Postów: 6 070
Dołączył: 10.12.2003
Skąd: Dąbrowa Górnicza



Nie ma co na siłę trzymać się normalizacji, czasem denormalizacja nie jest zła, a wręcz wskazana (np. przez względy wydajnościowe). Dodaj do tabeli z fakturami kolumnę z sumą i aktualizuj jej wartość triggerem (w zasadzie na każde zdarzenie :/). Od strony aplikacji nie dotykaj tej kolumny, nie ingeruj w jej wartość.
  Forum: Bazy danych · Podgląd postu: #1252822 · Odpowiedzi: 11 · Wyświetleń: 4 234

phpion
Napisane: 3.11.2019, 19:51:09





Grupa: Moderatorzy
Postów: 6 070
Dołączył: 10.12.2003
Skąd: Dąbrowa Górnicza



To, że systemy narzucają ograniczenia nie oznacza, że trzeba się na nie ot tak godzić. Ta kolumna jest po prostu zbędna, a przy metodyce zapisu "wywal powiązania -> wstaw nowe powiązania" wartości id będą rosły w astronomicznym tempie. Poza tym kolega pytał o schemat bazy, a nie schemat pod konkretne narzędzie (ORM) więc przy takim rozpatrywaniu kolumna tym bardziej nadaje się do wywalenia.
  Forum: MySQL · Podgląd postu: #1247392 · Odpowiedzi: 4 · Wyświetleń: 2 044

phpion
Napisane: 3.11.2019, 19:07:47





Grupa: Moderatorzy
Postów: 6 070
Dołączył: 10.12.2003
Skąd: Dąbrowa Górnicza



1. W tabeli ingredient_meal kolumn id jest zbędna - klucz główny powinien być na 2 pozostałych kolumnach (będących równocześnie kluczami obcymi).
2. Czy w tabeli ingredient_meal nie potrzebujesz również kolumn określających ilości danego składnika?
3. W odniesieniu do
Cytat
chciałbym generować diety na 30 dni dla jednego usera

tabela diets wydaje się być niepoprawna. Jak zobaczysz ile diet miał użytkownik? Co jeśli (hipotetycznie) 1 użytkownik w jednym czasie ma N diet? Bardziej prawidłowe byłoby chyba:
diets:
id
name
user_id

diet_meals:
diet_id
day
meal_id

Legenda: klucz główny, klucz obcy, klucz główny będący kluczem obcym
  Forum: MySQL · Podgląd postu: #1247389 · Odpowiedzi: 4 · Wyświetleń: 2 044

phpion
Napisane: 3.11.2019, 18:59:27





Grupa: Moderatorzy
Postów: 6 070
Dołączył: 10.12.2003
Skąd: Dąbrowa Górnicza



Wiele już zostało powiedziane ale ja dodam od siebie jedno, na co nikt wcześniej nie zwrócił uwagi. Chodzi o:
https://github.com/filipdak/libraryoop/blob...onForm.php#L103
  1. $this->connection->query("INSERT INTO uzytkownicy VALUES(NULL,:nick,:email,:password)");

Unikaj zapisów poleceń SQL bazujących na kolejności kolumn w bazie danych. Zmienisz strukturę tabeli, dodasz pomiędzy istniejącymi kolumnami nową i zaczną się problemy z dziwnym zachowaniem skryptu. Dużo lepiej i bezpieczniej jest zapisać (w tym pomijając NULL dla kolumny id):
  1. $this->connection->query("INSERT INTO uzytkownicy (nick, email, password) VALUES(:nick,:email,:password)");

czyli jawnie podać jakie dane mają trafić w jakie kolumny.
  Forum: Oceny · Podgląd postu: #1247388 · Odpowiedzi: 31 · Wyświetleń: 24 670

phpion
Napisane: 30.06.2019, 22:45:10





Grupa: Moderatorzy
Postów: 6 070
Dołączył: 10.12.2003
Skąd: Dąbrowa Górnicza



Generalnie dobrze odczytałeś moje intencje. Może nie chodziło mi stricte o Kohanę, ale akurat to był framework na którym pracowałem w tych "lepszych czasach" więc siłą rzeczy skojarzenie jest dość silne. Chodzi mi o to, że wówczas czułem że panuję nad całym projektem. Dołączałem biblioteki PHP jakie chciałem, a nie pierdyliard dodatkowych zależności - i jakoś to działało. Dołączałem jQuery + pluginy, starałem się wszystko trzymać "w jednej kupie". Tak samo style - też jakiś porządek panował. Teraz korzystając z zewnętrznych rozwiązań jest w zasadzie wolna amerykanka. Wspomniałem, że jestem purystą - tak. I duperele mnie drażnią. Pamiętam jak korzystając z PostgreSQL i chcąc dodać nową kolumnę nie było opcji ustalenia jej położenia, a zawsze była dodawana na końcu. Już takie coś mnie drażniło. Kończyło się na tym, że tabelę usuwałem i tworzyłem na nowo w kolejności kolumn jaka mi odpowiadała. Dlatego drażni mnie, że aktualnie wykonuje się 1 polecenie, które zaciąga X pakietów - dla mnie to powoduje burdel. Rzadko również korzystałem z gotowych modułów bo zawsze coś mi nie pasowało. Mam tu na myśli całe moduły (strzelam: do obsługi ankiet), a nie biblioteki (typu generowanie PDF).

Uparłem się na krytykowanie Symfony bo ten framework wiedzie prym i wyznacza aktualne trendy, które mi osobiście nie do końca odpowiadają. Pracowałem na Symfony 1 i przyznam, że całkiem dobrze to wspominam. No może poza generatorem admina, który na pierwszy rzut oka robił wrażenie "wow", ale gdy przyszło do bardziej skomplikowanych spraw to się zaczynały schody. Potem to już zaczęło się dla mnie udziwnianie i przerost formy nad treścią.

Jeśli natomiast chodzi o Kohanę to zawsze będę jej bronił. Ok, może w porównaniu chociażby do ZF1 kod był wręcz laciki, ale kurde działał smile.gif I nie spotkałem frameworka, który miałby lepiej rozwiązany mechanizm walidacji danych, internacjonalizacji, kaskadowości plików (chyba żaden nie ma takiego jak Kohana - idealny pod SaaS) czy... (czekam na lincz) ORM. Tak, pod kątem ORM moim zdaniem/w moim odczuciu/dla mnie Kohana była wygodniejsza w użyciu niż Doctrine czy inny Propel.

Więc podsumowując: chciałbym by wróciły czasy gdzie więcej spada na barki programisty, a mniej jest magii. Więcej od niego zależy, a nie od tego jakie polecenia wykona.
  Forum: Hydepark · Podgląd postu: #1243144 · Odpowiedzi: 61 · Wyświetleń: 12 206

phpion
Napisane: 26.06.2019, 22:53:51





Grupa: Moderatorzy
Postów: 6 070
Dołączył: 10.12.2003
Skąd: Dąbrowa Górnicza



Po paru latach milczenia na forum postanowiłem się wypowiedzieć, bo okazuje się, że nie jestem sam w swoim rozumowaniu.

Zauważyłem, że od paru lat (w zasadzie od ZF2 czy SF2) webdeveloperka idzie na siłę w kierunku bycia pro. Coś co parę lat temu można było zrobić dużo prościej aktualnie jest niepotrzebnie komplikowane, a wszystko to w imię pro. Jestem programistą, który (według mnie) swoje najlepsze zawodowe lata miał w okolicach 2010/2011. Wówczas faktycznie byłem zadowolony ze swoich projektów. Jestem typem purysty, który lubi mieć wszystko pod kontrolą, dlatego wszelkiej maści udogodnienia (typu chociażby Composer) na dzień dobry mnie odrzucają. Najlepiej programowało mi się w Kohanie. Prosty framework ale dający duże możliwości. Dlaczego duże? Bo to tylko narzędzie. Miałem swoje ulubione dodatkowe biblioteki, które dołączałem do projektów, miałem pod nie napisane proste moduły w Kohanie. Wiedziałem wszystko co i jak, nie było w tym żadnej magii. Obecnie króluje Symfony i Composer. Gdzie nie spojrzeć - Symfony i Composer. Żeby wrzucić projekt na serwer konieczny/bardzo zalecany jest dostęp do konsoli. Ja wolałem po prostu wgrać pliki na FTP, poustawiać dostępy i po temacie. Proste jak budowa cepa.

Czy projekt napisany w Kohanie jest mniej pro od projektu w Symfony? Według mnie nie można tak tego określać. Framework z założenia to tylko narzędzie, więc od samego programisty zależy jak go wykorzysta i co na nim zbuduje. Chcąc odnowić lakier w aucie jeden może zaopatrzyć się w najdroższą maszynę polerską i odstawić fuszerkę, a drugi za pomocą ręki i szmatki wyprowadzi lakier na błysk.

Mam wrażenie, że obecnie panuje trend, że im bardziej skomplikujemy sobie życie tym będzie bardziej pro. Nawalimy 5 klas, dowalimy 17 interfejsów - nooo, teraz jest pro. Sro a nie pro. W pracy pracujemy nad wewnętrznym projektem, który ma już ok. 10 lat. Częściowo bazuje na własnym frameworku pierwotnego twórcy, a w większości na ZF1. Około 2 lat temu do pracy przyszła "świeża krew", która przeforsowała wprowadzenie Symfony (tak, projekt działa na 3 frameworkach!). Jest pro? Według mnie nie. Jest bajzel. Pomijając już kwestię 3 frameworków to moim zdaniem, żeby móc powiedzieć że projekt jest pro trzeba pisać go w narzędziu, które się zna. Wtedy można prawidłowo i efektywnie z niego skorzystać. Widzę natomiast po sobie i po kolegach, że rzeczy w Symfony powstają na zasadzie "o, działa, nie dotykać". To co w przypadku chociażby ZF1 przerabialiśmy po parę razy żeby w końcu być zadowolonym z kodu (efekt działania taki sam) zostawiamy w Symfony na etapie "o, działa". Tu dodaj to, tam dopisz to, jeszcze tu, wygeneruj to, zrób tamto - jak dla mnie chore.

Męczy mnie całe to przekombinowanie, utrudnianie, na siłę udowadnianie, że PHP też może być pro. Chciałbym znowu wziąć framework i z niego korzystać. Czego nie znajdę w dokumentacji to znajdę w kodzie źródłowym nie musząc przebijać się przez 38 plików. Wszystko jednak idzie do przodu. Symfony ma bardzo dobry marketing i według mnie tym się przebija. Pozostałe frameworki próbują dorównać bo przecież liczy się bycie pro. Świeżak wchodząc w świat frameworków nie ma zbyt dużego wyboru - skupi się na tym, co jest popularne (czyli na Symfony, no ewentualnie Laravel bo w tym momencie cała reszta się już nie liczy). I będzie się bawił w tworzenie encji i repozytoriów, a w efekcie i tak będzie operował na tablicach, a jeśli już na obiektach to tylko dla zapisywania zmian w polach. Ale będzie pro bo pisze w Symfony.

Kosmiczna abstrakcja bazy danych? Mamy zapomnieć, że korzystamy z bazy? Ma to być transparentne? Nie zgodzę się. Korzystamy z danego typu bazy danych to wykorzystajmy maksymalnie jego możliwości. Dlaczego narzędzie ma nas ograniczać jedynie do tego, co jest "wspólne" dla różnych silników bazodanowych? Moja baza ma typ pola idealny pod moje potrzeby - chcę z niego skorzystać. Mogę przerzucić część logiki na samą bazę tworząc X triggerów na jedno zdarzenie - też chcę. Niby mogę ale lepiej nie - bo przenośność...

Nie twierdzę, że Symfony to jedno wielkie zło. Nie przepadam za tym frameworkiem ale wiem, że są magicy, którzy potrafią w tym czynić cuda. Bo się na tym znają. Tak jak ja (moim skromnym zdaniem) swego czasu w Kohanie. Zdaje się jednak, że cała brać PHP-owa idzie w kierunku tego co na topie, a to dalej nakręca koniunkturę.

Naprawdę liczę, że w końcu nastąpi powrót do korzeni i pojawi się prosty framework all-in-one. Taka nowsza Kohana czy ZF1. I w końcu projekt wraz z frameworkiem zajmie 3-5 MB, a nie kilkadziesiąt MB. Że znowu zaczniemy myśleć jak rozwiązać dany problem, a nie jak rozwiązać go w danym narzędziu. Że przestaniemy dostosowywać schemat bazy danych do ograniczeń biblioteki. Jeśli nie - trudno, żyć za coś trzeba. Ale sentyment pozostanie :)
  Forum: Hydepark · Podgląd postu: #1243013 · Odpowiedzi: 61 · Wyświetleń: 12 206

phpion
Napisane: 12.04.2018, 06:13:05





Grupa: Moderatorzy
Postów: 6 070
Dołączył: 10.12.2003
Skąd: Dąbrowa Górnicza



Może źle rozumiem problem ale czy nie możesz napisać apki w PHP i wrzucić na jakiś hosting? Skoro masz tablet/komórkę z internetem to odpalisz ją sobie przez przeglądarkę.
  Forum: Hydepark · Podgląd postu: #1231905 · Odpowiedzi: 14 · Wyświetleń: 1 353

phpion
Napisane: 3.04.2018, 01:01:54





Grupa: Moderatorzy
Postów: 6 070
Dołączył: 10.12.2003
Skąd: Dąbrowa Górnicza



Skąd Ty tyle wiesz na temat tego projektu? Może każdy użytkownik będzie tworzył własnych wyimaginowanych piłkarzy?
  Forum: Przedszkole · Podgląd postu: #1231499 · Odpowiedzi: 12 · Wyświetleń: 362

phpion
Napisane: 2.04.2018, 15:16:51





Grupa: Moderatorzy
Postów: 6 070
Dołączył: 10.12.2003
Skąd: Dąbrowa Górnicza



@trzczy: chyba, ze piłkarze bedą tworzeni przez samych użytkowników, a nie brani „z puli”. Wówczas 1:n.
  Forum: Przedszkole · Podgląd postu: #1231478 · Odpowiedzi: 12 · Wyświetleń: 362

phpion
Napisane: 2.04.2018, 09:43:44





Grupa: Moderatorzy
Postów: 6 070
Dołączył: 10.12.2003
Skąd: Dąbrowa Górnicza



@trzczy: kolumna id jest naprawdę potrzebna?
  Forum: Przedszkole · Podgląd postu: #1231465 · Odpowiedzi: 12 · Wyświetleń: 362

phpion
Napisane: 2.04.2018, 08:42:04





Grupa: Moderatorzy
Postów: 6 070
Dołączył: 10.12.2003
Skąd: Dąbrowa Górnicza



Ja w wielu kwestiach zgodzę się z przedstawionym materiałem. Ten owczy pęd za coraz bardziej skomplikowanymi frameworkami (mimo, ze maja w sobie mniej funkcjonalności!) wydaje mi sie być dyktowany pewną modą. Żeby być pro trzeba natrzaskac 15 klas, 8 interfejsów i dopiero wtedy wyświetlić jakiś tekst. Dalej: zależności pakietów composera. Ja wole wiedzieć co mam w projekcie, a nie dociągnąć różniste pakiety, ktore zależą od kolejnych itd. Swego czasu pisałem w Symfony, akurat wersji pierwszej, i faktycznie bardzo często spotykałem sie z „jak to zrobić w Symfony?”. Nie jak to zrobić, ale jak to ugryźć w konkretnym frameworku. Ileż to razy spotkałem sie z sytuacja „dodajmy do tabeli klucz główny id bo XXX nie wspiera kluczy złożonych” - wtf? mam dostosowywać schemat bazy do frameworka na którym pracuje?

Padło pytanie o Kohane: jeśli miałbym możliwość to wciąż bym jej używał. Aktualnie projekt przy którym pracuje stoi na ZF1. Da się? No pewnie ze sie da. Może w tych frameworkach nie ma DI czy innych wow wynalazków ale całość po prostu działa. I teraz każdy dostaje orgazmu na myśl o Symfony 3/4 ale za jakiś czas wyjdzie Symfony 7 i znowu będzie to „Best Symfony ever”. I tak w kółko.
  Forum: Hydepark · Podgląd postu: #1231462 · Odpowiedzi: 26 · Wyświetleń: 3 085

phpion
Napisane: 27.03.2018, 18:22:19





Grupa: Moderatorzy
Postów: 6 070
Dołączył: 10.12.2003
Skąd: Dąbrowa Górnicza



Użyj crona do kasowania przeterminowanych plików.
  Forum: PHP · Podgląd postu: #1231236 · Odpowiedzi: 3 · Wyświetleń: 345

phpion
Napisane: 27.03.2018, 18:28:29





Grupa: Moderatorzy
Postów: 6 070
Dołączył: 10.12.2003
Skąd: Dąbrowa Górnicza



O ile pamietam to systemy płatności przesyłają do Ciebie dane POSTem. Możliwe, ze kierujesz ich na adres http albo z/bez www w wyniku czego .htaccess dokonuje przekierowania gubiąc przy tym dane z POSTa. Pod adresem którym odbierasz dane z DP daj sobie zrzut danych do pliku np. file_put_contents($plik, print_r($_POST, true)) i zobacz czy jakiekolwiek otrzymujesz.
  Forum: PHP · Podgląd postu: #1231238 · Odpowiedzi: 12 · Wyświetleń: 772

phpion
Napisane: 22.03.2018, 07:00:27





Grupa: Moderatorzy
Postów: 6 070
Dołączył: 10.12.2003
Skąd: Dąbrowa Górnicza



W PHP tego nie zrobisz bo działa po stronie serwera. Musisz użyć czegoś działającego po stronie klienta - JS.
  Forum: PHP · Podgląd postu: #1230981 · Odpowiedzi: 4 · Wyświetleń: 531

phpion
Napisane: 21.03.2018, 19:36:29





Grupa: Moderatorzy
Postów: 6 070
Dołączył: 10.12.2003
Skąd: Dąbrowa Górnicza



Cytat(SmokAnalog @ 21.03.2018, 19:24:05 ) *
Pomiarów jest więcej i dałeś po jednej kolumnie per jednostka pomiaru? Dziwne rozwiązanie.

To pytanie do mnie?
  Forum: Bazy danych · Podgląd postu: #1230966 · Odpowiedzi: 19 · Wyświetleń: 2 396

phpion
Napisane: 21.03.2018, 19:20:12





Grupa: Moderatorzy
Postów: 6 070
Dołączył: 10.12.2003
Skąd: Dąbrowa Górnicza



Może jednak iść w stronę normalizacji? Zrób sobie słownik parametrów:
id, nazwa (m_c, m_ub itd)
i tabelę dla parametrów pomiarów:
id_pomiaru, id_parametru, wartość
Minus taki, że kolumna wartość musiałaby posiadać „wspólny” typ danych czyli u Ciebie pewnie decimal(6,1). Nie wiem jak zapisujesz dane do bazy ale kluczem głównym słownika pomiarów wcale nie musi być sztuczna wartość 1, 2, 3... a właśnie m_c, m_ub (wówczas w polu nazwa masz słowną nazwę parametru). Może właśnie to będzie najlepszym rozwiązaniem?
  Forum: Bazy danych · Podgląd postu: #1230964 · Odpowiedzi: 19 · Wyświetleń: 2 396

phpion
Napisane: 21.03.2018, 07:03:20





Grupa: Moderatorzy
Postów: 6 070
Dołączył: 10.12.2003
Skąd: Dąbrowa Górnicza



Ja bym zostawił jak jest. Zaczniesz normalizować i Ci wydajnościowo klęknie. Użyjesz JSONa i sie wyłożysz gdy będzie trzeba coś w nim znaleźć lub zmodyfikować.
  Forum: Bazy danych · Podgląd postu: #1230905 · Odpowiedzi: 19 · Wyświetleń: 2 396

phpion
Napisane: 16.03.2018, 17:13:59





Grupa: Moderatorzy
Postów: 6 070
Dołączył: 10.12.2003
Skąd: Dąbrowa Górnicza



Zapisuj w drugiej tabeli userId, a nie userName. W obecnej sytuacji tez sobie poradzisz ale rozsądniej zrobić jak napisałem. W obecnej postaci w linku przekazuj nazwę użytkownika, a nie id, albo w zapytaniu pobierającym dane użyj podzapytania, które na podstawie id zwróci userName.
  Forum: Bazy danych · Podgląd postu: #1230666 · Odpowiedzi: 2 · Wyświetleń: 1 498

phpion
Napisane: 5.03.2018, 18:14:56





Grupa: Moderatorzy
Postów: 6 070
Dołączył: 10.12.2003
Skąd: Dąbrowa Górnicza



Pamiętaj, że przed header() nie możesz wysłać nic na wyjście: żadnego kodu HTML, żadnej spacji, niczego. Obstawiam, że to właśnie stanowi u Ciebie problem, może przekierowanie robisz „w środku” kodu HTML? Bez kodu można zgadywać.
  Forum: PHP · Podgląd postu: #1230159 · Odpowiedzi: 8 · Wyświetleń: 1 021

phpion
Napisane: 2.03.2018, 07:10:02





Grupa: Moderatorzy
Postów: 6 070
Dołączył: 10.12.2003
Skąd: Dąbrowa Górnicza



Problem chyba leży u Ciebie troszkę gdzie indziej. Wiadomości flash służą do jednokrotnego wyświetlania treści po przekierowaniu. Ty dodajesz wiadomość flash i wyświetlasz szablon. Jeśli tak to nie rób flasha tylko przekaz komunikat do widoku albo zostaw flash ale zrób przekierowanie.
  Forum: Przedszkole · Podgląd postu: #1229932 · Odpowiedzi: 4 · Wyświetleń: 478

phpion
Napisane: 28.02.2018, 17:29:31





Grupa: Moderatorzy
Postów: 6 070
Dołączył: 10.12.2003
Skąd: Dąbrowa Górnicza



1. Zaznaczasz tylko w celu poglądowym, w bazie zapisujesz tylko powiat. Jak to zrobić w JS - zależy jaką będziesz miał strukturę HTMLa. W jQuery powinieneś to ogarnąć bez większego problemu.
2. Ktoś wybiera województwo, masz w bazie powiązania wojewodztwo-powiat wiec jesteś w stanie wyciągnąć powiaty. Analogicznie dla kraju. Wiesz jakie ma województwa i jakie są w nich powiaty. Teraz pytanie czy wyszukiwarkę oprzesz na złączeniach tabel i warunkach czy od razu na where firmy_powiaty.id_powiatu in (lista, powiatów, według, kryteriów, wyszukiwania) ale na to pytanie musisz odpwiedziec sobie sam jak będzie Ci wygodniej i co będzie wydajniejsze.
  Forum: Frameworki · Podgląd postu: #1229826 · Odpowiedzi: 6 · Wyświetleń: 993

272 Stron V   1 2 3 > » 

New Posts  Nowe odpowiedzi
No New Posts  Brak nowych odpowiedzi
Hot topic  Popularny temat (Nowe)
No new  Popularny temat (Brak nowych)
Poll  Sonda (Nowe)
No new votes  Sonda (Brak nowych)
Closed  Zamknięty temat
Moved  Przeniesiony temat
 

RSS Wersja Lo-Fi Aktualny czas: 28.03.2024 - 11:56