Форум MySQL

Есть таблица Пользователи. В ней есть некоторые поля, в том числе РегДата, ЛастЛогин, _Страна_, ....

РегДата будет использовано преимущественно для вывода даты регистрации, поле ЛастЛогин содержит дату последнего входа пользователя*** - ниже дописано.

Поле Страна было изменено на КодСтраны и создана таблица с именем СтраныПроживания (табл содержит код страны и название страны). Вот этот КодСтраны (из табл СтраныПроживания) и содержится в поле КодСтраны в табл Пользователи.

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

Вопрос (какбы так его правильно сформулировать...): Все данные нужно _максимально_ разбивать исходя из использования в коде и структуре?

Знаю что вопрос непонятен и возможно туповат. Попробую еще привести пример

Ситуация: Есть таблица ПостыПользователей. В ней есть некоторые поля, и в том числе поле ТематикаПоста. Если изменить поле ТематикаПоста на поле КодТематикиПоста и создать таблицу ТематикаПостов, содержащую КодТематикиПоста и НазваниеТематикиПоста, то такой подход будет правильным?

Ну и в табл ПостыПользователей будет поле КодТематикиПоста, а не само название тематики.

---
*** НО если потребуется сохранять более подробную информацию о последнем входе пользователя, (например дату адрес, клиент и др...) - то логично будет создать отдельную таблицу ЛастЛогиНЫ, где указать ИДПользователя с таблицы Пользователи и данные о последнем входе.
---
Это правильный подход к структуризации и хранению данных?

Подход правильный. Непонятно, какая еще может быть информация
о последнем входе, которую нельзя взять из таблицы пользователей.
Отдельную таблицу для логинов не надо делать. Как старые будете
удалять?

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

У меня была система учета посетителей клуба и оплаты.
Там писалось все, что делали посетители (логин, просмотр своих дан-
ных, оплата счета и т.д.) и младшие админы (редактирование данных,
распечатка, удаление и т.п.). Но это уже паранойя. И конечно, число
возможных действий посетителей и младших админов было ограничено.

>Непонятно, какая еще может быть информация
>о последнем входе, которую нельзя взять из таблицы пользователей.
>Отдельную таблицу для логинов не надо делать. Как старые будете
>удалять?

Дело в том что я не хочу перегружать табл Пользователи лишними данными.

А "старых" логинов (точнее не логинов, а информации о предыдущих входах) не будет.

При входе каждый раз будет обновляться инфа о входе пользователя. (если первый раз заходит то понячтно что запись будет ДОБАВЛЕНА).

А предыдущий вход пользователя можно записывать в текстовый файл чтобы показывать например так как ВКантакте показывает последние 5 сессий. Или вообще ничего не сохранять.



---

Пасиб. это кажись называется "нормализация бд" - мне так ответили где-то.

Возник еще слегка схожий вопрос. похож он тем что вроде бы там есть некие правильные (?) рассуждения.

http://www.softtime.ru/forum/read.php?id_forum=3&id_theme=91786#post546306 - нужно было в другом разделе спросить. но не хочу создавать копию в php-разделе.

Подход будет правильным в том случае, если вы эти данные будете использовать. В противном случае, зачем их хранить? Но также возникает проблема с производительностью. Представьте себе ситуацию, когда вам нужно отсортировать пользователей по дате последнего посещения. Какой будет запрос? Примерно такой:

SELECT * FROM `users` `u` LEFT JOIN `user_visits` `uv` ON (`u`.`id` = `uv`.`user_id`) ORDER BY `uv`.`date`

условие ON ресурсов съест бог знает сколько.

Короче говоря, данные нужно дублировать. А то получится опенкарт.

фигасе из-за угла танк
с каких пор поводом для денормализации выступает конструкция ON и её условие?

Совет ТС читайте про нормализацию БД

с каких пор поводом для денормализации выступает конструкция ON и её условие?

Вы видели код моделей каталога товаров в OpenCart? Из-за отсутствия дублирования данных он абсолютно не приспособлен для магазинов с более чем парой тысяч товаров - тормоза жуткие. Нет бы создателям продублировать названия, описания и еще некоторые данные о товарах - тормоза бы уменьшились хотя бы для языка и магазина по умолчанию. Вот к чему приводит бесконтрольная нормализация - на вирт. хостинге магазин с ~5000 товаров генерирует страницу за 5,5 секунд.

к этому приводит не бесконтрольная нормализация, а попытка "с хрена жира натопить"
ОпенКарт - это "конструктор", он не написан под конкретный магазин и я уж не буду вам рассказывать, что практически любое универсальное решение - это говно.
Я не против денормализации как таковой, но для неё должна быть веская причина, подкреплённая кучей тестов.

ОпенКарт - это "конструктор", он не написан под конкретный магазин и я уж не буду вам рассказывать, что практически любое универсальное решение - это говно.

Об этом можно поспорить - ведь в 80% случаев за глаза хватает универсального решения.

А то, что полная нормализация БД приносит проблемы, как раз и ясно на примере ОпенКарта.

вот как раз дублировать не нужно. Зачем по стопидисят раз одинаковые данные хранить.

В линуксе есть команда last которая выводит все входы всех пользователей. А команда laslogin выводи только посление входы пользователей. Ото задача состоит в том чтобы записывать только последний вход пользователя.

А что со "старыми" данными делать - я уде написал. "для показа последних сессий"

чтобы отсортировать... нужно создать табл и показать реальный пример. Думаю будет намного проще чем вы написали. сделаю отпишусь.
---

По поводу кто сколько съедает я вообще без пониматия.