Mam pytanie odnośnie zapytania SELECT. Załóżmy że w pierwszym przypadku mamy taką podstawową tabelę z użytkownikami i kolumny z nazwą użytkownika, hashem hasła, typem użytkownika, danymi typu adres itd... W drugim przypadku chcemy zapisać w bazie takie same informacje o użytkowniku ale używamy relacji w bazie czyli np. dane adresowe umieszczamy w osobnej tabeli itp. I teraz pojawia się moje pytanie - Czy zastosowanie zapytania SELECT kolumny_ktore_nas_interesuja FROM users WHERE cos_tam w przypadku pierwszej tabeli będzie znacznie mniej wydajne niż odniesienie się za pomocą SELECT to tych samych danych ale w drugim przypadku, gdzie będą występowały zależności i trzeba by użyć JOIN ? Jak duże mogą to być różnice w wydajności ? Bo słyszałem że powinno się postępować według drugiej reguły.

Zgodnie ze zdrowym rozsądkiem w tabeli użytkownicy umieszczasz dane niezmienne, lub takie krórych historia zmian nie musi być pamiętana. W osobnej tabeli przechowujesz dane wraz z historią zmian. Jest to jedyne mądre rozwiązanie i tak powinieneś robić.
Kwestie wydajności są bardzo szerokim pojęciem i nie opiszemy ci ich na forum. Może jakaś książka....

JOIN spowalnia i to jest fakt. Ale żeby w MySQL było to problemem muszą być spełnione dwa warunki:
- duża tabela np. users
- bardzo duża redundancja

A żeby opłacało się przenosić np. "adres" do innej tabeli musi być spełniony jeszcze jeden warunek:
- mała tabela joinowana - bo join dużej tabeli do małej to kompletne nieporozumienie

Np. opłacałoby się to gdybyśmy mieli dużą tabelę users i w niej nazwę województwa, typu "dolnogórnośrodkowonowosądeckie", województw mało a nazwa długa więc aż się prosi oddzielna tabela...

I argumenty typu "zwiększanie rozmiaru tabeli" nie mają dziś racji bytu, bo przestrzeń dyskowa nie jest dziś problemem, lecz wydajność. Dlatego redundancja często jest celowa, np. dodawanie pseudonimu użytkownika (oprócz id) żeby nie joinować dużej tabeli users do jakiejś niewielkiej typu bohomazy

I sztuka sztuką ale wydajność ma priorytet.