![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 174 Pomógł: 0 Dołączył: 24.04.2009 Ostrzeżenie: (30%) ![]() ![]() |
Cześć. Mam mały dylemat jak stworzyć bazę danych aby była ona jak najbardziej optymalna. Chce zrobić takie pola:
ID (UNSIGNED int(11 czy bez wartości max?)) login (varchar (z wartością w nawiasie lepiej czy nie?)) pass (char(32)) level (tinyint(1)) Prędzej będzie jeszcze mail ale pomijam ponieważ chodzi o samą zasadę. Czy umieszczenie w nawiasie maksymalnej wielkości coś daje? (chodzi o wielkość i szybkość bazy) Czy raczej to bez różnicy? Jeżeli tak to jakie wartości wystarczą dla mail oraz login? |
|
|
![]() |
![]()
Post
#2
|
|
Grupa: Moderatorzy Postów: 4 362 Pomógł: 714 Dołączył: 12.02.2009 Skąd: Jak się położę tak leżę :D ![]() |
@Wookieb: nie chodzi mi o numer index. Doświadczalnie kiedyś sprawdzał kumpel jak się ma enum do szybkości operacji w bazie na danych i empirycznie doszliśmy do tego, że enum musi mieć jakiś indeks założony, bo inaczej nie mógłby być taki szybki. Wygląda na to, że same nazwy są jedynie "nakładką tekstową" na najbliższy pasujący ilości elementów wariant inta lub binary z założonym indeksem i to na tym tak naprawdę on operuje, a nie na tekstach widocznych dla usera. Inaczej nie mogę wytłumaczyć takiej szybkości operacji. A nie sprawdzałem nigdy kodu silnika MySQL więc są to moje przypuszczenia na temat możliwej implementacji enum w tej bazie.
@Crozin: jak to nie ma nic wspólnego? Zauważ, że to iż Ty znasz różnicę jest czymś innym niż wiedza autora tematu. On jej nie zna (co widać w postach) i wypowiedzi osób w tym temacie mają mu to przybliżyć. To że piszę dużo wynika z faktu, iż chcę zaprezentować w miarę zrozumiałe przykłady. Gdybym ich nie dał, to post byłby mniej więcej 1/3 tego co napisałem. A to dlaczego odpowiedziałem ma związek z punktem 2 Twojego postu gdzie stwierdziłeś, że liczba w varchar nie ma wpływu, co nie jest dokońca prawdą. Im mniejsza tym czas dostępu do kolejnej kolumny także jest mniejszy. Dlatego varchar powinien być możliwie jak najkrótszy. Ma to więc przełożenie na wydajność w pewien sposób. Dodatkowo jesli wierzyć komentarzom na stronie mysql, wystarczy że choć jedna kolumna rekordu jest typu varchar i cała wydajnośc z char jest nic nie warta, ponieważ prosty dostęp do danych poprzez szybkie wyliczanie pozycji wiersza i kolumny offsetem jest zakłócony. Innymi słowy char ma sens jedynie gdy długość każdego wiersza w tabeli jest zawsze stała. Gdy mowa o rangach to problem można rozwiązać na 2 sposoby. 1) Podajesz enum, który łatwo rozszerzać o kolejne rangi, ale może takie podejście nieco przy ACL (system uprawnień) pomieszać szyki, ponieważ wymaga ciut większego przemyślenia problemu tychże uprawnień. 2) zastosować tinyint (lub większy) i porobić kolejne rangi nie po kolei, ale co połowę zakresu by w owe luki mieć możliwość wepchnięcia nowych rang. Większa bowiem jest możliwość rozwarstwiania uprawnień nisko w hierarchii niż wysoko. Prędzej powstanie kilka różnych grup userów o innych uprawnieniach niż różne rodzaje moderatorów. Najlepiej jednak zrobisz czytając o ACL więcej i wyrabiając sobie pomysł pasujący do Twojego problemu/cms/serwisu. |
|
|
![]() ![]() |
![]() |
Aktualny czas: 1.10.2025 - 22:59 |