thing(thing_id, pers_id, slot_id, ...) таблица шмоток персонажа. Кому принадлежит, в какой слот одета NULL - шмотка не одета
slot_ref(slot_id, title) справочник шмоток
pers(pers_id, ...) персонажи

При одевании шмотки в слот персонажа, заполняется поле slot_id шмотки




Есть мысль (но она мне не нравится) вынести одевание шмотк в отдельную таблицу.
dressed_thing(thing_id, slot_id, pers_id) одетые шмотки это мизерная часть от общей массы. Может поле slot_id и лишнее в таблице шмоток. Выборка одетых шмоток - это очень популярный запрос. Напрягает ещё один join в запросах. (поэтому и pers_id сюда добавил, который дублирует ссылку thin.pers_id

Подскажите, пжлст, как сохранить целостность данных?

Ещё идея, но она мне кажется изратной :)
Сделать доп поле вычисляемое f(slot_id, pers_id) и на него повесить ограничение уникальности. pers_id * 100 + slot_id для снятых шмоток будет NULL, для одетых - уникальное для каждого перс/слот значение

Бредовость бредовой идея с вычисляемым полем подтвердилась - вычисляемое поле не может участвовать в ограничениях. Что вполне логично.

Это браузерка. Потому тут тут с БД выгребается все при каждом новом чихе.

Сейчас в игрушке слоты сделаны отдельными полями в табл. персов. И это просто ад кромешный. Чтобы узнать, что шмотка одета/куда одета/не одета, нужно проверить все поля-слоты в таблице юзера и т.д. И слоты геймдиз мечтет добавлять. Некоторые даже временно для ивентов.

Уникальные индексы получется нужны на поля persId-slotId чтобы не одеть две шмотки в один слот и второй на thingId, чтобы не одеть одну шмотку в два слота.

Поле слота в таблице шмоток (thing.slot_id) удобно для выборок. Отдельная таблица (thing_id, pers_id, slot_id) вместо этого поля добавляет гемора в селекты.

А если совместить поле в таблице инвентаря, а работу с отдельной таблицей одетых шмоток сделать на тригерах?
При прописывании thing.slot_id (одевание шмотки) добавлять запись в табличку, при обNULLении thing.slot_id - стирать запись.

Практикуется такой подход для контроля ссылочной целостности?

Спасибо всем за участие!

Справочник слотов перса



Шмотки и справочник шмоток



Изначально я хотел обойтись лишь указаной схемой. Поле thing.slot_id содержит либо указатель на слот, в который одета шмотка, либо NULL (шмотка снята). Такой вариант довольно удобен для выборки шмоток, что делается очень часто)
Для обеспечения ссылочной целостности нужен уникальный ключ (thing.pers_id, thing.slot_id) с игнорированием NULL в slot_id. Что сделать невозможно.

Второй вариант, как указали выше, - это отдельная таблица одетых шмоток (pers_id, slot_id, thing_id). Но с этой таблицей неудобными становятся запросы. Потому хочется сохранить поле thing.slot_id, а его модификацию делать через триггеры табл одетых шмоток.

Симонов Денис, почти этот вариант вы и описали.
авторА ещё есть таблица со всеми шмотками перса (PERS_ID,thing_id, busy_flag), где busy_flag - флаг надета ли шмотка.
Мое поле thing.slot_id и есть этот busy_flag. Только указывает дополнительно и слот.

Получилась такая штука.



Изначально таблица одетых шмоток пустая. При одевании шмотки в слот юзера добавляется новая запись либо апдейтится существующая. При снятии шмотки - thing_id устанавливается в null либо удаляется запись.

Запрос для добавления/апдейта записей


Одевание/раздевание работает. Теперь триггерами на thing_dressed изменять поле thing.slot_id
Ещё добавилось дублирование pers_id. Нужно затычку для их рассогласования предусмотреть - очищать thing_dressed.thing_id при изменении thing.pers_id Дабы на персе не оказалась одетой шмотка после её передачи другому персу.

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

Дегтярев Евгений, на нем самом.

Гаджимурадов Рустам, если не лень, можете подробней описать, что не так лошадьми?

И триггер для синхронизации thing_dressed и thing.slot_id


Пока работает. Спасибо всем за помощь )

Коннект действительно довольно прожорлив, но не столь ужасен. Много чего кешируется в memcached. Но от коннекта к БД все равно никуда не деться.

авторКоннект действительно довольно прожорлив, но не столь ужасен. Много чего кешируется в memcached. Но от коннекта к БД все равно никуда не деться.
Забыл дополнить, что это слова про текущий проект на mysql. На firebird я еще не пробовал "по боевому".

Гаджимурадов Рустам, это и есть версия 2,0. Первая стреляет уже несколько лет.

автор"Справочник слотов перса" - отсутствует. Если, конечно, разные
персонажи (по расе, уникальности, уровню и пр.) не могут иметь
разные типы/количества слотов. Если могут - может понадобиться
доп.таблица (а может и нет - зависит от).

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



В справочнике шмоток указывается допустимый тип слота, а в самой шмотке - номер занятого ею слота.

авторКак хранить/обрабатывать многослотовые вещи могу дополнительно
описать, если нужно, там не рокет-саенс. Уникальность вещь-перс я
бы не делал, это глупо. Уникальность вещь-слот для перса делается
очевидно (индексом), но даже это не нужно, ибо уникальность должна
быть перс-слот, т.е. PersThings.PERS_ID + PersThings.SLOT.
Поле thing.slot_id действительно трансформировалось в описываемую вами таблицу с именно таким PK. Само же поле thing.slot_id (синхронизируется триггером) оставил лишь для будущих селектов - сейчас мне видится, что оно будет полезным при выборках, избавит от доп. джойнов с thing_dressed. Может и уберу его.

авторПри надевании вещи триггером меняются "текущие" характеристики
персонажа, чтобы каждый раз не пересчитывать. До этой части ещё не дошел вплотную. Там мыслей куча, на отдельную ветку хватит)

авторне тот ты инструмент выбрал и коннект тут не самое болезненное
проблемы, которые ты тут описываешь, быстрее и дешевле решаются именно внутри процесса сервера твоей игры, а какая субд и как там разложены данные дело десятое
Лишь любопытства ради , как примерно это выглядит без привязки к языку?
Как мне видится.
Должен быть некий долгоиграющий процесс, в памяти которого развернут мир игры. Массивы различных оперативных данных вытянуты с БД, развернуты в "языковые" объекты/очереди/массивы, связанны между собой ссылками и т.п.
Каждый сеанс юзера - это отдельный поток в этом процессе. Куча потоков одновременно изменяют/рождают/убивают данных в этом огромном месиве данных. Так это происходит?
Код напичкан критическими секциями, семафорами и т.д. Утечки памяти становятся не пустым звуком, полный крах при малейшей ошибке. Теневое сохранение в БД.
Ужас, летящий на крыльях ночи - такие впечатления рождаются в мозгу, заточенном на "http - протокол без созранения состояния" :)

Гаджимурадов Рустам, мы действительно на разных языках говорим )

Справочник слотов нужен чтобы знать, какие именно слоты есть у персов.

Где мне хранить инфу, что слоты 7,8,9 - это пальцы? И одеть в эти слоты можно только кольца и никак не штаны.
Слот 11 - это обувь и шлем на ноги не натянуть.

В справочнике шмоток я должен как-то указать колпаку, что его можно одеть лишь на голову.

Под справочником я понимаю "статическую" таблицу с практически неизменяемыми данными.
FK на поле thing_dressed.slot_id сделан чтобы там не указали несуществующий слот.

Помогите, пжлст, найти взаимопонимание.

>Хотя это вопрос терминологии - статичный справочник,
>содержимое которого не меняется, тоже можно назвать
>справочником (наверное). Календарь, "справочник месяцев".

Ok. Что тут принято считать под "справочник"? А то я так со всеми буду непонятно общаться.

>Мы вроде как выше договорились (и в моём варианте, и
>во всех ваших), что шмотка "знает" куда её можно одеть -
>у шмотки есть поле slot, в котором указывается, надевается
>она на голову, руку или палец, и кот. исп. в соотв. фильтрах.
>Нюансы могут быть лишь для многослотовых шмоток.

Вот тут немного не так. По слотам есть два знания:
- в какой тип слота (голова, палец) можно одеть шмотку - это указано в справочнике шмоток (thing_ref.slot_type)
- в какой конкретно слот одета конкретная шмотка (третий палец, голова) - это указывается в таблице thing_dressed.slot_id

авторСм. выше, я как раз про это в начале отвечал - а) это не совсем
справочник; б) вероятно, это не лучший способ "защиты", если
он вообще нужен (он реально нужен? от самих себя?).
Я полностью согласен, что FK здесь вещь спорная. Сейчас я всю схему укутал FK, чтобы сразу вылазили косяки. После устаканивания структуры пересмотрю их надобность.

В общем одевалка заработала и она мне нравится.

По поводу мф шмоток и пересчетов триггерами. Перед этим нужно построить сырые данные. И тут я такое намудрил, что уже стесняюсь и спрашивать )