[MySQL] Klucze KEY |
[MySQL] Klucze KEY |
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 |
|
|
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%) |
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. 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ść 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? 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. 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. |
|
|
7.09.2018, 12:37:49
Post
#3
|
|
Grupa: Zarejestrowani Postów: 81 Pomógł: 0 Dołączył: 3.08.2017 Ostrzeżenie: (0%) |
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... 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? 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... Ten post edytował eerie 7.09.2018, 12:51:57 |
|
|
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ść 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. |
|
|
7.09.2018, 13:38:36
Post
#5
|
|
Grupa: Zarejestrowani Postów: 81 Pomógł: 0 Dołączył: 3.08.2017 Ostrzeżenie: (0%) |
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 |
|
|
7.09.2018, 13:54:29
Post
#6
|
|
Grupa: Moderatorzy Postów: 36 457 Pomógł: 6296 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 |
|
|
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 |
|
|
7.09.2018, 14:49:49
Post
#8
|
|
Grupa: Moderatorzy Postów: 36 457 Pomógł: 6296 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 |
|
|
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 |
|
|
7.09.2018, 14:59:47
Post
#10
|
|
Grupa: Moderatorzy Postów: 36 457 Pomógł: 6296 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 |
|
|
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 |
|
|
Wersja Lo-Fi | Aktualny czas: 26.04.2024 - 15:13 |