Moja prelekcja na WordCamp 2012 Gdańsk

Tytuł mojej prelekcji to:

Sprzątaj po sobie!

Opis:

Prezentacja adresowana jest zarówno do twórców wtyczek, jak i do ich użytkowników. Dla tych pierwszych będzie to zestaw dobrych praktyk, jakie należy umieścić w tworzonej wtyczce. Użytkownicu znajdą kilka istotnych rzeczy na jakie warto zwrócić uwagę przy używaniu, instalowaniu oraz usuwaniu używanych wtyczek. Prezentacja obejmie kwestie związane z wydajnością serwisu, a pomijane zazwyczaj przy tego typu prezentacjach, czyli jak na wydajnośc serwisu wpływa to co przechowują w bazie wtyczki i dlaczego tak się dzieje. Pokazane zostanie jaki wpływ na wydajność miał fakt sprzątnięcia bazy danych po tym, co zostawiły po sobie, prawidłowo wyłączone, a nieprawidłowo napisane wtyczki.

zobacz inne prelekcje
Lista prelekcji na WordCamp 2012 Gdańsk

jakie klucze stosować, jakie wybrać

Josh Berkus w cyklu „Primary KeyvilI, IIIII rozważa kwestie związane z używaniem kluczy głównych w tabelach. Zastanawia się nad kluczami będącymi w jego odczuciu surogatami prawdziwych kluczy głównych. Za taki surogat uważa klucze oparte na automatycznie inkrementowanych polach w bazie (autoincrement dla mysql’a oraz serial dla postgres’a) i przyznam, że podane argumenty są bardzo mocno i ciężko mi z nimi polemizować.

Generalnie autor zachęca do stosowania kluczy głównych które są rzeczywistym wyróżnikiem. Rozważmy sytuację w której mamy trzy proste tabele: users, groups, user2group – dwie pierwsze zawierają dane dotyczące odpowiednio: użytkowników oraz grup, ostatnia zawiera informację do których grup należy użytkownik.

Jeżeli zastosujemy jako klucze główne pola „ID” to w efekcie tabela user2group przyjmie zawartość:

+---------+----------+
| user_id | group_id |
+---------+----------+
|       1 |        1 |
|       2 |        2 |
|       2 |        6 |
+---------+----------+

Co jak widać niewiele mówi.

W przypadku w którym za klucze przyjmiemy odpowiednio email użytkownika oraz nazwę grupy to taka tabela będzie miała następującą zawartość:

+----------+----------+
| email    | group    |
+----------+----------+
| illi@x   | root     |
| gurthg@x | adm      |
| gurthg@x | www-data |
+----------+----------+

Trudno się nie zgodzić, że pomyłka w insercie typu: INSERT INTO tabela VALUES ( 1, 2 );
jest trudniejsza do wychwycenia niż w: INSERT INTO tabela VALUES ( 'illi@x', 'adm' );

Czytanie danych, szczególnie po latach albo obcych jest o niebo łatwiejsze wtedy kiedy naszymi kluczami są dane które coś znaczą.

Następnym drobnym zyskiem jest fakt zmniejszenia ilości zapytań lub joinów w zapytaniach.

Zauważymy, że w ostatnim przypadku żeby wylistować adresy email użytkowników należących do danej grupy, wtedy kiedy znamy tylko jej nazwę, wymusza w pierwszym przypadku użycie dwóch joinów. W drugim przypadku jest to prosty select. Oczywiście sytuacje tak proste raczej nie występują w życiu, ale są dobrym przykładem na zobrazowanie korzyści.

Oczywiście są sytuacje w których będę nadal używał kluczy opartych o inkrementowaną liczbę naturalną, ale tylko tam gdzie uznam to za naprawdę konieczne.

Natomiast w kwestiach prostych zostałem całkowicie przekonany do używania jako klucze główne takich danych, które niosą ze sobą rzeczywistą różnicę między rekordami.