Witaj Gościu! ( Zaloguj | Rejestruj )

Forum PHP.pl

 
Reply to this topicStart new topic
> [MySQL] Klucze KEY
eerie
post 7.09.2018, 06:23:52
Post #1





Grupa: Zarejestrowani
Postów: 81
Pomógł: 0
Dołączył: 3.08.2017

Ostrzeżenie: (0%)
-----


Witam

Zainstalowałem w Symfony 4.1 FOSUserBundle i mam pytanie. Stworzona w nim baza danych nie zawiera wartości unsigned (bez minusa) dla liczb i DEFAULT oraz KEY. Jeśli chodzi o unsigned, to ma to sens. I tak "int(11)" czy "int(10) unsigned" to integer i zajmuje [chyba] tyle samo pamięci z minusem czy bez. Ustalanie wartości default'owych też nie ma sensu, bo i tak na dzień dobry mamy w obiektach wartości NULL, które trzeba zmienić przed zapisem do bazy. Inaczej wywali błąd. Jak natomiast jest z kluczami? Klucze PRIMARY KEY, FOREIGN KEY i UNIQUE KEY są stosowane. Co ze zwykłymi kluczami KEY? Czy login i hasło nie powinny mieć zadeklarowanych kluczy KEY? Zapytania logowania bez KEY'a nie wykonuję się wolniej? Jak to jest?

Pozdrawiam
Robert
Go to the top of the page
+Quote Post
mmmmmmm
post 7.09.2018, 07:35:41
Post #2





Grupa: Zarejestrowani
Postów: 1 421
Pomógł: 310
Dołączył: 18.04.2012

Ostrzeżenie: (0%)
-----


Cytat(eerie @ 7.09.2018, 07:23:52 ) *
I tak "int(11)" czy "int(10) unsigned" to integer i zajmuje [chyba] tyle samo pamięci z minusem czy bez.

Liczby przy INT mają sens tylko w przypadku użycia ZEROFILL.
INT signed i unsigned zajmują tyle samo miejsca w pamięci, ale mają różny zakres wartości. Cytując dokumentację;
INT[(M)] [UNSIGNED] [ZEROFILL]

A normal-size integer. The signed range is -2147483648 to 2147483647. The unsigned range is 0 to 4294967295.

Cytat(eerie @ 7.09.2018, 07:23:52 ) *
Ustalanie wartości default'owych też nie ma sensu, bo i tak na dzień dobry mamy w obiektach wartości NULL, które trzeba zmienić przed zapisem do bazy. Inaczej wywali błąd.

Ma sens. Jeśli na 99% rekordów jakieś pole ma wartość 0, to po prostu nie ustawiasz tej wartości przy zapisie. DLa tego 1% zmieniasz (przed lub po zapisie) na inną wartoiść

Cytat(eerie @ 7.09.2018, 07:23:52 ) *
Jak natomiast jest z kluczami? Klucze PRIMARY KEY, FOREIGN KEY i UNIQUE KEY są stosowane. Co ze zwykłymi kluczami KEY?

Jakie "zwykłe klucze KEY"? Chodzi ci o indeksy?

Cytat(eerie @ 7.09.2018, 07:23:52 ) *
Czy login i hasło nie powinny mieć zadeklarowanych kluczy KEY?

Nie. Bo wtedy dopuszczałbyś sytuację z dwoma takimi samymi loginami, ale różnymi hasłami.

Cytat(eerie @ 7.09.2018, 07:23:52 ) *
Zapytania logowania bez KEY'a nie wykonuję się wolniej? Jak to jest?

Zależy od wielu czynników. Generalnie SELECT odbywa się szybciej. INSERT i UPDATE jest wolniejszy, bo wymaga przebudowania indeksów.
Go to the top of the page
+Quote Post
eerie
post 7.09.2018, 12:37:49
Post #3





Grupa: Zarejestrowani
Postów: 81
Pomógł: 0
Dołączył: 3.08.2017

Ostrzeżenie: (0%)
-----


Cytat(mmmmmmm @ 7.09.2018, 08:35:41 ) *
INT signed i unsigned zajmują tyle samo miejsca w pamięci, ale mają różny zakres wartości.

Czyli na indeks główny (PRIMARY KEY) lepiej stosować unsigned, bo wartości ujemne i tak się nie wykorzysta. Z drugiej strony... Z moich testów wynika, że i tak przy ponad 100-300 tys. wpisów do bazy aplikacja PHP + MySQL strasznie zwalnia...

Cytat(mmmmmmm @ 7.09.2018, 08:35:41 ) *
Ma sens. Jeśli na 99% rekordów jakieś pole ma wartość 0, to po prostu nie ustawiasz tej wartości przy zapisie. DLa tego 1% zmieniasz (przed lub po zapisie) na inną wartoiść

W zwykłej aplikacji PHP też tak mam, ale we framework'u Symfony świeżo utworzony obiekt przed zapisem ma same wartości NULL. Ustawienia default'owe w bazie MySQL nic nie dają i wywala mi błąd, że chcę zapisać NULL. Jedynym rozwiązaniem jest ustawić wartości default'owe w konstruktorze, aby nie ustawiać wszystkiego set'ami przed każdym osobnym zapisem...

Moje pytanie jest kierowane głównie do znawców Symfony. Bo widzę, że w FOSUserBundle (popularna biblioteka do obsługi uwierzytelniania) default'owo jest NULL. Czy ustawianie wartości DEFAUL we framework'u Symfony ma sens?

Cytat(mmmmmmm @ 7.09.2018, 08:35:41 ) *
Nie. Bo wtedy dopuszczałbyś sytuację z dwoma takimi samymi loginami, ale różnymi hasłami.

Czyli indeks (KEY) dla loginu ma sens, ale hasła już nie... wink.gif

Ten post edytował eerie 7.09.2018, 12:51:57
Go to the top of the page
+Quote Post
Crozin
post 7.09.2018, 13:08:43
Post #4





Grupa: Zarejestrowani
Postów: 6 476
Pomógł: 1306
Dołączył: 6.08.2006
Skąd: Kraków

Ostrzeżenie: (0%)
-----


Cytat
Czyli na indeks główny (PRIMARY KEY) lepiej stosować unsigned, bo wartości ujemne i tak się nie wykorzysta.
Nie lepiej, bo obsługa wartości bez znaku jest w wielu platformach mocno utrudniona - z PHP na czele - a niczego Ci nie daje w tym kontekście. Nie mówiąc już o dużych problemach w mieszaniu arytmetyki typów z i bez znaków.
Cytat
Z drugiej strony... Z moich testów wynika, że i tak przy ponad 100-300 tys. wpisów do bazy aplikacja PHP + MySQL strasznie zwalnia...
To będzie wina złego projektu aplikacji czy bazy danych, nie samej platformy/technologi. Nie przy takich wartościach.
Cytat
Cytat
Ustalanie wartości default'owych też nie ma sensu, bo i tak na dzień dobry mamy w obiektach wartości NULL, które trzeba zmienić przed zapisem do bazy. Inaczej wywali błąd.

Ma sens. Jeśli na 99% rekordów jakieś pole ma wartość 0, to po prostu nie ustawiasz tej wartości przy zapisie. DLa tego 1% zmieniasz (przed lub po zapisie) na inną wartoiść
To że jakaś wartość jest dominująca nie powinno być samo w sobie przesłanką do korzystania z wartości domyślnych. Przy czym jest to raczej mało istotna kwestia.
Cytat
W zwykłej aplikacji PHP też tak mam, ale we framework'u Symfony świeżo utworzony obiekt przed zapisem ma same wartości NULL. Ustawienia default'owe w bazie MySQL nic nie dają i wywala mi błąd, że chcę zapisać NULL. Jedynym rozwiązaniem jest ustawić wartości default'owe w konstruktorze, aby nie ustawiać wszystkiego set'ami przed każdym osobnym zapisem...
1. Symfony nie ma tutaj nic do rzeczy - to specyfika języka.
2. Jeżeli nulle nie mają sensu dla Twojego modelu danych - bardzo częsta sytuacja i w sumie jeszcze częściej mocno pożądana - nie umożliwiaj w ogóle ich podania. Od tego są konstruktory by wymusić podanie odpowiednich danych. Jeżeli zaś danych jest za dużo na konstruktor masz do dyspozycji całą paletę sprawdzonych wzorców budowniczych pozwalających konstruować złożone obiekty.
3. Jeżeli jakieś wartości trzeba ustawić to... to je ustaw.
Go to the top of the page
+Quote Post
eerie
post 7.09.2018, 13:38:36
Post #5





Grupa: Zarejestrowani
Postów: 81
Pomógł: 0
Dołączył: 3.08.2017

Ostrzeżenie: (0%)
-----


Cytat(Crozin @ 7.09.2018, 14:08:43 ) *
To będzie wina złego projektu aplikacji czy bazy danych, nie samej platformy/technologi. Nie przy takich wartościach.

Ile wpisów (dla jednej tabeli) do bazy MySQL powinna obsłużyć bezproblemowo prawidłowa aplikacja? Moja była banalnie prosta. Aż dziwi to spowolnienie (dobre kilka sekund) przy 100 tys. wpisów.

A co z indeksami (KEY)? Stosować czy nie stosować?

Pozdrawiam
Robert

Ten post edytował eerie 7.09.2018, 13:34:07
Go to the top of the page
+Quote Post
nospor
post 7.09.2018, 13:54:29
Post #6





Grupa: Moderatorzy
Postów: 36 429
Pomógł: 6289
Dołączył: 27.12.2004




Cytat
Ile wpisów (dla jednej tabeli) do bazy MySQL powinna obsłużyć bezproblemowo prawidłowa aplikacja?
Miliony na dzien dobry.

INdeksy zakladasz jak potrzebujesz. Np. gdy masz jakies wyszukiwnania to zakladasz indeksy by zapytania nie trwaly 30 sekund tylko by trwaly ulamek sekundy.
Nie ma sensu zakladac indeksow na wszystko tylko dlatego ze sie da. Nie potrzebujesz- nie zakladasz


--------------------

"Myśl, myśl, myśl..." - Kubuś Puchatek || "Manual, manual, manual..." - Kubuś Programista
"Szukaj, szukaj, szukaj..." - Kubuś Odkrywca || "Debuguj, debuguj, debuguj..." - Kubuś Developer

Go to the top of the page
+Quote Post
eerie
post 7.09.2018, 14:42:22
Post #7





Grupa: Zarejestrowani
Postów: 81
Pomógł: 0
Dołączył: 3.08.2017

Ostrzeżenie: (0%)
-----


Jeżeli mam PRIMARY KEY, to dodatkowego KEY'a już nie deklaruję. A co z FOREIGN KEY i UNIQUE KEY? Dodatkowy KEY (indeks) jest potrzebny?

Pozdrawiam
Robert
Go to the top of the page
+Quote Post
nospor
post 7.09.2018, 14:49:49
Post #8





Grupa: Moderatorzy
Postów: 36 429
Pomógł: 6289
Dołączył: 27.12.2004




No jak zacieta plyta...
No przeciez ci napisalem w poprzednim poscie


--------------------

"Myśl, myśl, myśl..." - Kubuś Puchatek || "Manual, manual, manual..." - Kubuś Programista
"Szukaj, szukaj, szukaj..." - Kubuś Odkrywca || "Debuguj, debuguj, debuguj..." - Kubuś Developer

Go to the top of the page
+Quote Post
eerie
post 7.09.2018, 14:57:51
Post #9





Grupa: Zarejestrowani
Postów: 81
Pomógł: 0
Dołączył: 3.08.2017

Ostrzeżenie: (0%)
-----


Np. UNIQUE KEY daje unikalne wartości. Ale czy też przyspiesza wyszukiwanie? Bo tego nie wiem...

Pozdrawiam
Robert
Go to the top of the page
+Quote Post
nospor
post 7.09.2018, 14:59:47
Post #10





Grupa: Moderatorzy
Postów: 36 429
Pomógł: 6289
Dołączył: 27.12.2004




Gdy zalozysz UNIQUE key to tak jakbys zalozyl index na dane pola - wiec tak, przyspiesza wyszukiwanie po tym polu ORAZ dodatkowo wymusza unikalnosc danych


--------------------

"Myśl, myśl, myśl..." - Kubuś Puchatek || "Manual, manual, manual..." - Kubuś Programista
"Szukaj, szukaj, szukaj..." - Kubuś Odkrywca || "Debuguj, debuguj, debuguj..." - Kubuś Developer

Go to the top of the page
+Quote Post
eerie
post 7.09.2018, 15:05:06
Post #11





Grupa: Zarejestrowani
Postów: 81
Pomógł: 0
Dołączył: 3.08.2017

Ostrzeżenie: (0%)
-----


To już poznałem odpowiedzi na moje wątpliwości. Dzięki serdeczne wszystkim za wskazówki...

Pozdrawiam
Robert
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 Użytkowników czyta ten temat (1 Gości i 0 Anonimowych użytkowników)
0 Zarejestrowanych:

 



RSS Wersja Lo-Fi Aktualny czas: 19.03.2024 - 02:58