Witaj Gościu! ( Zaloguj | Rejestruj )

Forum PHP.pl

> Optymalizacja zapisu danych do bazy
Mephis
post
Post #1





Grupa: Zarejestrowani
Postów: 94
Pomógł: 1
Dołączył: 16.12.2012

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


Witam.

1. Załóżmy, że mamy tabelę dot. profilu użytkownika. Znajdują się w niej takie kolumny, jak 'imię', 'nazwisko', 'miasto'.
Wiadomo, że zarówno imiona jak i nazwiska, a tym bardziej miasta będą się powtarzać. Z nazwiskami co prawda mniej co imiona, ale też jednak powtórzą się nieraz. W szczególności, gdy profili będzie np. ok. 300 tyś.
Czy warto zrobić coś takiego, aby utworzyć osobne tabele zawierające właśnie dane dot. tych kolumn, czyli zawierające imiona, nazwiska i miasta?
Oczywiście takie dane jak imię czy nazwisko, czy miasto zostanie wprowadzone tylko za pierwszym razem. Następnie, jeżeli już będzie istnieć odpowiednie 'imię' w bazie, w tabeli profilu zostanie zapisane tylko odwołanie pod postacią identyfikatora.

2. Wiadomo, że domeny adresów poczty elektronicznej będą się powtarzać. To jest jeszcze bardziej pewne niż to wyżej. Czy warto w takim przypadku rozdzielić użytkownika poczty od domeny? Zasada działania jak ta wyżej, czyli raz wprowadzona domena zostanie zapisana, a następnie w danych o użytkowniku zostanie zapisane tylko odwołanie do domeny.
Do tego, jeżeli to wyżej ma sens, to czy warto rozdzielić domeny na subdomeny (i już na nic więcej)? Subdomena łączyła by się wtedy z rodzicem (domeną) i tworzyła pełną domeną.
Ta sama tabela domen będzie mogła posłużyć do blokowania dostępu z odpowiednich hostów, czy do pozbawienia możliwości rejestracji w serwisie z odpowiedniej domeny (lub subdomeny domeny) adresu mail.

Pozdrawiam, Xerphis.
Go to the top of the page
+Quote Post
 
Start new topic
Odpowiedzi (1 - 6)
mmmmmmm
post
Post #2





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

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


Nie warto. Tylko sobie krzywdę zrobisz.
Dla 300 tys szkoda zachodu. Przy 300 milionach, gdyby mi się miejsce w bazie kończyło (w hostingu znaczy się) bym się zastanowił.
Go to the top of the page
+Quote Post
Pyton_000
post
Post #3





Grupa: Zarejestrowani
Postów: 8 068
Pomógł: 1414
Dołączył: 26.10.2005

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


Taniej by Ci było dokupić miejsce niż zmieniać wtedy strukturę bazy (IMG:style_emoticons/default/biggrin.gif)
Go to the top of the page
+Quote Post
Mephis
post
Post #4





Grupa: Zarejestrowani
Postów: 94
Pomógł: 1
Dołączył: 16.12.2012

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


Zapomniałem wspomnieć, że to wszystko tyczy się projektowania bazy a nie modyfikację aktualnej.

Czyli, że nie opłaca się ani jedno ani drugie? Chodzi tutaj o niewielki wpływ na wagę bazy, czy o wydłużenie czasu wykonywania zapytań?

Ten post edytował Mephis 21.04.2016, 10:15:44
Go to the top of the page
+Quote Post
Pyton_000
post
Post #5





Grupa: Zarejestrowani
Postów: 8 068
Pomógł: 1414
Dołączył: 26.10.2005

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


Rozbijając komplikujesz sobie życie, a zysku z tego nie ma tak wielkiego żeby to było must have.

Czasami warto zostawić takie pierdoły. Rozdzielenie miałoby sens gdybyś ręcznie dodawał/usuwał opcje tak jak np. w statusach zamówień itp.
Go to the top of the page
+Quote Post
Mephis
post
Post #6





Grupa: Zarejestrowani
Postów: 94
Pomógł: 1
Dołączył: 16.12.2012

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


Sobie nie komplikuję w żadnym wypadku.

Chodzi mi właśnie o to, czy w ten sposób skomplikuję życie tylko i wyłącznie serwerowi bazy danych, gdyż zależy mi na jej wydajności.
Go to the top of the page
+Quote Post
Pyton_000
post
Post #7





Grupa: Zarejestrowani
Postów: 8 068
Pomógł: 1414
Dołączył: 26.10.2005

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


A w czym problem utworzyć sobie 2 struktury, wypchać danymi i przetestować obie formy? Wrzuć sobie nawet 2 mln danych. Wg. mnie rozbijanie tych danych jest bez sensu. Dla Ciebie może ma sens.

Ten post edytował Pyton_000 21.04.2016, 12:01:02
Go to the top of the page
+Quote Post

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

 



RSS Aktualny czas: 22.08.2025 - 23:14