Остался буквально один шажок 😉 Т.е. мы решили, что можно использовать внешние ключи. Осталось все собрать воедино.

идей про внешние ключи на любые таблицы нет

С точки зрения логики игры нам в произвольный момент всего лишь нужно убедиться, что некий (любой) объект свободен для манипуляций (не находится в состоянии «таймаута»). Типов манипуляций у одного объекта, конечно, может быть произвольное число.  Но все множество таких манипуляций всех объектов можно свести к плоскому списку.  Для этого достаточно только id манипуляции и продолжительности времени жизни. Именно это и помещать в k/v хранилище. Кому какая манипуляция принадлежит «знает» реляционная часть. При появлении любого игрового объекта нужно генерить для него набор таких пар на базе имеющейся бизнес логики.

при возникновении соотв. события выбираем готовые манипуляции и помещаем в k/v, делее чекаем их прокисание. Никаких прямых модификаций

То есть ты предлагаешь сконкатенировать тип манипуляции и id объекта. Да, теоретически так можно сделать, но какой-то особой выгоды от этого я не вижу - с точки зрения реляционных БД это просто уникальный индекс на два поля.

То, что у нас ограниченное число типов манипуляций - это важно. Т.е. их не тысячи и десятки тысяч - как может быть объектов, а максимум штук 10-20.

я хотел свести набор данных на уровне k/v (которая быстрая и может автоматом прокисать) до двух значений id-манипуляции/таймаут. И то и другое мы руками не задаем, а выбираем из реляционной по любым нужным параметрам (пользователь, объект, событие, что угодно). Причем и набор манипуляций нигде руками не создаем а он генерится на базе бизнес-логики

есть мнение, что делать группу вместо канала - ошибка.
Это совсем разные форматы: участвовать в трёпе кучи народа, у которых есть вопросы, и читать мысли отдельного человека.

Есть группа - вот эта. Есть отдельно канал: http://t.me/ctorecords

ок, спасибо

А не видно запиненное сообщение?

запиненные сообщение созданы, чтобы их не читали же

Ладно. Убрал, чтобы не занимало место

Его можно случайно убрать

В-общем, disclosure по моей задаче: все очень просто. Раз выбрана реляционная модель, то надо смотреть на отношения между сущностями. Объект <-> таймаут определенного типа - это отношение 1 <-> 1|0. То есть мы для каждого типа таймаута либо делаем NULLable колонку вида ship_refuel_expiry_date в таблице объекта, либо отдельную таблицу с полями например (ship_id, expiry_date) , где ПК - это ID объекта (на самом деле у нас используются суррогатные ПК, так что ID объекта добавляем просто как внешний ключ и делаем его уникальным и NOT NULL, но это частности).

По следам сегодняшнего поста про то, где не найти разработчиков, задаёт вопрос Алексей С. (fb.com/asudachen)

У меня вот вопрос прямо противоположный - как найти перспективный проект, о котором можно рассказывать другим людям с интересом и гордостью, и команду с толковым лидом, говорящую на одном с тобой языке (и я не про исп/англ/рус). Чтобы можно было не париться "трудностями перевода" и душу в проект вкладывать, а не только часы. Ну и чтобы платили ещё адекватно, да.

Это очень хороший вопрос. Ответ довольно сложный для понимания, но попробуйте прочувствовать: нужно стать достойным такого проекта. Если не стать, даже если попадёшь, быстро вылетишь.

Это однако игра для двоих... ;-) Логично что из такой идеи следует что проблемы поиска хорошего бакенд-разработчика могут быть как-то связаны с проектом, что его ищет. Потому как даже если и найдёт, может очень быстро потерять по понятной причине

Конечно! Всё именно так.

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

ТТТ, чтоб не сглазить!


Это, кстати, другой интересный вопрос, а хорошо ли что люди не движутся дальше? Имхо, у любой работы, проекта, даже навыка есть время жизни. В этом мире конечно всё, а многое ещё и скоротечно. Жизнь - это ведь постоянное изменение. Я так думаю, всё должно обновляться, и люди тоже. То что не меняется - то мертво.

Я даю много интересных задач на вырост за очень редким исключением. Есть куда расти на многие годы вперёд. Мои команды у меня инвестора не раз старались украсть и присвоить себе всё, чего я добился.

В моих командах человек сегодня и человек завтра - это разные люди.

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

Да, на удивление это очень много решает

Соответственно, из тех, кто знает, формируется костяк команды, достаточно быстро. Далее делегируются полномочия по найму, и костяк обрастает мясом. Следует понимать, что опорные люди в команде, помимо экспертизы, приносят свою репутацию и свои связи. Поэтому 500+ для них - норма.

Норм подход! Осталось только найти таких людей :)