Po aktualizacji WordPressa do wersji 4.1.2 wiele osób zgłasza problemy z zapisem swoich wpisów. Ze względu na to, że ta wersja mocno uwzględnia kodowanie znaków wprowadzanych do bazy, tam zacząłem szukać rozwiązania.
Tag: baza danych
Tytuł mojej prelekcji to:
Sprzątaj po sobie!
Opis:
[blo-link-inner href="http://2012.gdansk.wordcamp.org/prelekcje/" nofollow="1" more="zobacz inne prelekcje"]Lista prelekcji na WordCamp 2012 Gdańsk[/blo-link-inner]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.
Josh Berkus w cyklu „Primary Keyvil” 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.
