MySQL - лучший способ сохранения и загрузки предметов - PullRequest
0 голосов
/ 12 января 2010

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

0=4151:54;1=995:5000;2=521:1;

Так что в основном: slot=item:amount;

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

Я думал сделать что-то еще, например, иметь таблицу со следующими столбцами:

id, owner_id, slot_id, item_id, amount

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

Ответы [ 2 ]

2 голосов
/ 12 января 2010

Да, используйте эту структуру. Использование текста для хранения реляционных данных наносит ущерб цели реляционной базы данных.

Я не понимаю, что вы имеете в виду, вставляя их все при регистрации. Разве вы не можете вставить их так, как вам нужно?

Редактировать

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

1 голос
/ 12 января 2010

Если я вас правильно понял и что элемент слота может измениться, то вы хотите дополнительно абстрагировать отображение между item_id и элементом:

entry_tbl.item_id->item_rel_realitems_tbl.real_id->items_tbl

Таким образом, все записи с itemid указывают на таблицу, которая сопоставляет эти идентификаторы с изменяемым элементом. Когда вы ОБНОВЛЯЕТЕ элемент в items_tbl, отображение автоматически обновляет entry_tbl.

Однако требуется еще одно СОЕДИНЕНИЕ. Я бы также использовал хранимые процедуры в любом случае, чтобы абстрагировать механизм от семантики.

Однако я не уверен, что понимаю формулировку вашего вопроса.

...