Artemon, денормализация это не способ проектирования а костыль который иногда необходимо ставить.

Простой пример из жизни.
Две таблицы.


Задача:
На входе список id пользователей (в стеднем 50 значений). Получить rs имя пользователя, ID последнего локейшина.

Как будете решать без денормализации и на каком кол-ве данных вы почувствуете СУЩЕСТВЕННУЮ разницу по сравнению с денормализованым вариантом (всего-то добавить lat_location_id в user)

solenko,  вы немного путаетесь в терминах, мне кажется.
нормализация - приведение, к нормальной форме (их там штук 9, но обчыно ограничеваются 4ой.) Разбиение на таблицы, удаление дублирования
денормализация - обратный процесс, все в одну таблицу

по поводу вашей схемы БД. а пользователи и локейшены как связаны ? у вас не написано

этим ты добьешься связи между двумя таблицами, вид связи будет один ко многим: locations -> users

Правильно, отношение таблиц задал, и стало возможно выбирать записи из таблицы users по условию lat_location_id = locations.id
И что ты этим хотел сказать ?

sir_nuf_nuf, Artemon, упс. Не дописал немного естественно
стартовый вариант:


денормализованный вариант


Добавлено через 2 минуты и 3 секунды
Естесно user -> location связь один -> многим

Твой пример не показывает никаких приимуществ денормализованной БД, вернее он вообще ничего не показывает, привел 2 таблицы и поробуй догадайся в чем фишка.

Это сообщение отредактировал(а) Artemon - 30.8.2008, 10:35

Artemon, думал что поймете по структуре таблицы, на раз нет...
1. Есть пользователи. Данные о них хранятся в таблице users. В нашем примере это уникальный идентификатор (id int primary key) и имя пользователя (name varchar(255))
2. В таблице locations хранятся данные о местоположении пользователей. В нашем примере это уникальный идентификатор местоположения (id int primary key), id пользователя (user_id int references users(id)) и время, когда это местоположение было сохранено (set_date datetime). 
3. Таблица users связана с locations связью типа один ко мноким по полям users.id = locations.user_id

Необходимо, имея список id пользователей (в нашем примере это просто список, в реальности это список друзей), получить результат запроса, который бы содержал id пользователя, имя пользователя, id последнего местоположения (последнее опрделяестя по максимальной set_date. Можно использовать и максимальный locations.id, хоть это не логично). Т.е. в итоге нужно получить rs с полями:
users.id, users.name, locations.id

Если вам еще что-то непонятно в постановке задачи, с удовольствием отвечу на все вопросы.

solenko,  ваш запрос на последнюю локацию










Это сообщение отредактировал(а) sir_nuf_nuf - 2.9.2008, 00:48

sir_nuf_nuf, теперь дописываем ноликов к количеству данных в таблице... 
Торможение я заметил на ~5000 пользователей, порядка 10^6 locations. Вот тогда уже и денормализовал тблицу ) 
А до этого работал джойн на себя, что было немного быстрее вложенных запросов

solenko, аналогичная ситуация  на работе..
просто хотел отметить, что нормализация иногда несовместима с большими нагрузками,
но сложные запросы строить к нормализованной базе наоборот удобно