Метод хранения данных без "раздувания" таблиц.

[peterpro]

Метод хранения данных без "раздувания" таблиц.

Создается онлайн-игрушка.

В ней имеются объекты типа "хранилище" (инвентарь, склады и т.д.).

Существует большая база предметов (>1000), причем любое сочетание этих предметов может лежать в "хранилище".

Вопрос: как рациональней всего реализовать хранение записей об этих объектах в хранилищах?

Лично я это реализовал в виде массива (item_1,quant_1,item_2,quant_2.....item_n,quant_n), где item - это id объекта в БД, а quant - соответствуещее количество этих объектов в хранилище. Этот массив сериализуется и загоняется в поле типа blob для каждого из "хранилищ".

Рационально ли это?

 

[SelenIT]

Поле типа blob для такой задачи наверняка не рационально. А сериализованный массив предметов - имхо, допустимо, если набор предметов задан жестко раз и навсегда (изменяться и удаляться предметы не будут) и никогда не возникнет задача выбирать хранилища по содержанию определенного предмета.

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

 

[peterpro]

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

будут-будут

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

это уже вряд ли

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

Т.е. выборка из 1 000 000 предметов - это быстрее, чем выборка из 10 000 хранилищ и одной операции рассериализации?

 

[SelenIT]

во-первых, выборка чисел заведомо быстрее выборки строк

во-вторых, одна операция "рассериализации" - это только в том случае, когда заранее известно, в каком хранилище какие предметы искать

в-третьих, при изменении одного из 1000 предметов придется нетривиально апдейтить все 10000 хранилищ...

думайте сами, решайте сами... в конце концов опыт - критерий истины

 

[Steamroller]

Т.е. выборка из 1 000 000 предметов - это быстрее, чем выборка из 10 000 хранилищ и одной операции рассериализации?

И так и так выборка очень быстрая.
Но если реально миллион предметов - могут быть тормоза при вставках при нормализованной форме, и, как уже заметил SelenIT, при сквозных заменах по блобам.

 

[peterpro]

Товарищи, простите за назойливость, просто я действительно желаю разобраться в проблеме

во-вторых, одна операция "рассериализации" - это только в том случае, когда заранее известно, в каком хранилище какие предметы искать

Можно я покажу предполагаемый traceroute данных?

Вход в игру -> выборка player по id. -> захотели просмотреть список его недвижимости ->делаем выборку в таблице строений по id владельца -> захотели посмотреть, что лежит на складе -> по id склада сделали выборку поля с сериализованной информацией, что есть на складе.

в-третьих, при изменении одного из 1000 предметов придется нетривиально апдейтить все 10000 хранилищ...

Простите, я торможу ночью : зачем? ведь в хранилище у нас лежит только id и количество предметов! Изменяем предмет в таблице предметов -> при следуещем запросе по его id будут выданы новые данные!

То есть, хоть и объектов и будет (допустим) 1 000 000, но видов обьектов - всего 1000. И уникальных параметров для каждого из обьектов - нету.
Огромное спасибо всем тем, кто отвечает!

 

[SelenIT]

peterpro
А при удалении предмета - так и оставлять мусор в сериализованных полях? Да и при добавлении нового предмета в хранилище придется переписывать все blob-поле, вместо обычного инсерта одной записи из 3-х чисел...

 

[Steamroller]

ИМХО заранее не понять, как хуже. Так что имеет смысл сначала сделать в нормализованном виде, а потом, если именно эти операции будут создавать тормоза - переписывать на блобы, или еще как-то решать.

 

[peterpro]

Спасибо большое, я попробую обе схемы, и проверю на быстродействие)

 

[chira]

peterpro

Спасибо большое, я попробую обе схемы, и проверю на быстродействие

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

 

[Фанат]

Вход в игру -> выборка player по id. -> захотели просмотреть список его недвижимости ->делаем выборку в таблице строений по id владельца -> захотели посмотреть, что лежит на складе -> по id склада сделали выборку поля с сериализованной информацией, что есть на складе.

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

С примитивной точки зрения - этот форум тоже может хранить все ветки в блобах. а чё? пришёл - открыл - посмотрел.
Только вот элементарная операция показать список тем с количеством сообщений в них потребует титанических усилий.

думать надо над своими играми заранее.

 

[peterpro]

Автор оригинала: Фанат
какая простая игра. прямо не игра, а куличики.
автор, наверное, долго думал над ней.
из куличиков построить домик построить не догадался.
и устроить аукцион из имеющигося на складах хлама.
и вот при попытке прсомотреа содержимого всех складов эта гениальная система и встанет в очень пикантную позу.

С примитивной точки зрения - этот форум тоже может хранить все ветки в блобах. а чё? пришёл - открыл - посмотрел.
Только вот элементарная операция показать список тем с количеством сообщений в них потребует титанических усилий.

думать надо над своими играми заранее.

Товарищ, лично Вам
Я больше занимался чистым программированием, чем связями с БД, поэтому я и решил спросить мнения у авторитетных людей Прошу прощения, что мой пост вызвал в Вас столь неудержимый гнев и флеймовую реакцию

А всем, кто помог - спасибо огромное - действительно, уже при грубых аппроксимациях нормализация показывает лучшие результаты

 

[Фанат]

Я больше занимался чистым программированием

не стоило оправдываться.
тем более, что речь шла не о программировании или свзях, а о том, что свою систему надо продумать хотя бы минимально, хотя бы на 1 ход вперёд, а не на уровне запросил-получил - опля всё готово.