Дадите совет по построению БД?

Question

[Myshka]

Привет :3

Есть задача - следить за изменением состояния друзей в Вк(записывать кто выбыл, кого добавили).
У меня, на данный момент, вот такие четыре не хитрые таблицы
Как бы вы переделали их, чтоб было, так сказать пА-люЦки, со всякими ключами, связями и т.д.?

:3

Answer 1

[Петр]

У вас избыточность данных.
id, first_name, last_name,sex,city - почти не будут меняться. Их в одну таблицу friends.
А в других останется только id записи и ссылка personid на friends

Comments

[Myshka]

Т.е. будет одна таблица с 6-ю стобцами(friends). И 4 таблицы по две колонки(id и ссылка на таблицу friends)?

[Петр]

Myshka: Все зависит от ваших целей. Можно обойтись и 1 таблицей при желании. А del, new и т.п. будет дополнительным полем указывающим состояние.

[Петр]

Myshka: Возможно в единственную friends можно добавить поля с типом дата: fromdate - когда присоединился, deldate - когда выбыл, если null - то еще не выбыл. lastvisit - дата последнего посещения.

[Myshka]

Петр: это пока сложно для моего мозга :(
Вообще идея какая? Есть уже готовый, рабочий скрипт, который успешно работает с этими таблицами, заполняет fresh_friends полученными данными, сравнивает с current_friends(полученными пять минут назад) и в результате добавляет записи в оставшиеся две таблицы и шлёт отчёт на почту.
Я не могу понять как, в случает одной таблицы мы будем решать кто выбыл, а кто вбыл. И как вносить данные, если мы избавимся от избыточности данных путём добавления friends.

[Петр]

Myshka: Я написал про поля с датами. Нету пользователя добавили в таблицу и указали текущую дату в поле fromdate. Выборка по условию select * from friends where fromdate > now - 10 минут. Вернет всех новых за последние 10 минут. При проверке на наличие, пишете для примера в lastvisit дату начала проверки. Затем update set deldate = ... where lastvisit != дате проверки. Вот вам и выбывшие.

Answer 2

[d-stream]

Персона, если не заморачиваться со сменами фамилии, пола и т.п. - по сути одна, а эта персона во времени может приходить, уходить и т.п.

Вот и напрашивается одна табличка с первичным ключом person_id и горой данных типа ФИО и т.п., а вторая слегка упрощенная табличка - этакая история (хронология) событий:
датавремя, персона (person_id), действие (например int или enum)

соответственно если взять первую запись по хронологии для конкретной персоны - увидим когда персона впервые появилась, по действию последней записи персоны - понимаем ее статус

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

Comments

[Myshka]

Спасибо, но опять-таки это, пока, сложно для моего мозга.
Хотя, идея со статистикой хороша. В дальнейшем будущем нужно будет как-то реализовать :3

Answer 3

[3vi1_0n3]

Я бы сделал одну табличку такой структуры как ваши, но с одним дополнительным полем Status, в котором можно писать, куда, собственно, человек относится.
Person(PersonId, FirstName, LastName, Sex, Online, City, Status)
Ну, или если нужны исторические данные, то одна табличка, описывающая персону, а вторая - Дата, Статус, UserID. То есть, можно будеть описать сущности так:
Person(PersonId, FirstName, LastName, Sex, Online, City)
PersonId - первичный ключ (автоинкрементируемый)
StatusChange(Id, PersonId, ChangeDate, ChangeValue)
Id - первичный ключ, PersonId - foreign key
Ну и, собственно, всё.
Последний статус находится по максимальному значению Id, которое должно быть автоинкрементальным