Как в базе хранить массивы-переменные разных размеров для игры.

[olegon]

Как в базе хранить массивы-переменные разных размеров для игры.

Кто как делает?
Надо хранить массивы-переменные игры в базе.
Я делаю так (не буду пока приводить структуру таблиц - много). Скажу на словах.

Простые числовые и строковые переменные понятно, напр. в табл. Vars0.

Одномерные массивы: их названия и размеры в табл. Vars1_name, их значения в табл. Vars1_value со ссылкой на id из таблицы Vars1_name.

Двумерные массивы: их названия и размеры по i и по j в табл. Vars2_name, их значения в табл. Vars2_value со ссылкой на id в табл. Vars2_name и i-ую строку массива.

Специфика (и достоинство) именно такого хранения переменных в базе состоит в том, что одномерные и двумерные переменные хранятся централизовано в своих таблицах – т.е. не надо для каждой новой переменной выделять отдельную таблицу.
Но есть существенный недостаток: размер таблиц со значениями переменных определяется наибольшим размером массива (наибольшим массивом в таблице имен). Поэтому могут возникать большие пробелы в таблице – там, где значение <NULL>.

Внимание, вопросы:
1. На сколько пользуется популярностью именно такая модель организации переменных на сервере?;
2. И есть ли другие эффективные способы?
3. Может все-таки лучше для каждой двумерной переменной создавать отдельную таблицу и не возится с тем, что я написал вверху?

 

[_RVK_]

olegon
То есть для каждого значения в таблице отельное поле?

Ты бы всеже привел бы краткую схему. Это ты хорошо ориентируешься а другим словестное описание сложно для понимания.

 

[olegon]

To _RVK_
< Ты бы всеже привел бы краткую схему

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

< То есть для каждого значения в таблице отельное поле?
Да, совершенно верно.
Если я не понятно объяснил схему - то извиняюсь. Могу ответить на дополнительные вопросы.

*********************************
Vars0
Таблица переменных – обычных чисел или строк
x y z text1 text2 sum
55 20 30 NULL NULL 100

Vars1_name
Таблица одномерных массивов-переменных – здесь заносятся названия массивов и их размер
id name size
1 A 3
2 B 15
3 C 15
4 D 5

Vars1_value
Таблица одномерных массивов-переменных – здесь заносятся их значения со ссылкой на id из таблицы Vars1_name
id id_vars1_name v1 v2 v3 v4 v5 v6 v7 v8 v9 v10 v11 v12 v13...
1 1 5 4 8 NULL NULL NULL NULL....................
2 2 5 6 2 9 12 3 5 7 14 7 8 2 1
3 3 4 6 1 8 3 2 9 0 3 0 3 9 3
4 4 10 4 3 9 2 NULL NULL NULL NULL...........

Vars2_name
Таблица двумерных массивов-переменных – здесь заносятся названия массивов и их размер по i и по j
id name size_i size_j
1 X 5 5
2 Y 3 10

Vars2_value
Таблица двумерных массивов-переменных – здесь заносятся их значения со ссылкой на id из таблицы Vars2_name и со ссылкой на рядок i той же таблицы.
id id_vars2_name i j_v1 j_v2 j_v3 j_v4 j_v5 ... j_v9 j_v10
1 1 1 6 3 7 5 0 7 4
2 1 2 4 8 3 2 5 5 0
3 1 3 7 2 2 1 8 9 8
4 2 1 76 32 45 63 87 ... NULL NULL
5 2 2 44 29 35 78 21 ... NULL NULL

 

[_RVK_]

Ой, кошмар. Удали это...

Выложи файл куда нибудь, и дай ссылку.

По полю на значение это неверное решение. Одно значение = одна запись. Связь 1 ко многим.

 

[WebDev]

Или еще проще -
$data=var_export($your_crazy_multi_dimensional_array,TRUE);
и запихивай ее в поле типа text.

 

[_RVK_]

WebDev

Если есть необходимость куда-нибудь "запихнуть" массив, то делать это нужно функцией [m]serialize[/m]. Но это явно не тот случай. Думай, прежде чем писать. Ок?

 

[olegon]

To _RVK_
< Выложи файл куда нибудь, и дай ссылку.

Вот за 5 минут сайтик забацал
http://olegon.dev.juga.ru/ - там все в красивом виде показано!

< По полю на значение это неверное решение. Одно значение = одна запись. Связь 1 ко многим.

Спасибо. Я понял, что ты имеешь в виду - развернуть значения "не в ширину, а в длину". Т.е. не каждое поле - значение, а каждая запись (строка) - значение.
Так действительно будет красивее (без нуллов это точно).
Типа так (для одномерных переменных):
id_var1_name / value
1 / 4
1 / 7
2 / 9
2 / 3
2 / 1

Но зато при такой структуре будет тяжелее обратиться, скажем, ко второму элементу массива А (А[2]), без введения дополнительного считающего поля. Иначе придется делать хранимую процедуру, которая вернет не просто весь SELECT * FROM table WHERE id_var1_name=2, а только вторую запись этого набора. Или я не правильно мыслю? А?

 

[_RVK_]

>Или я не правильно мыслю?
Скорее да, чем нет. Что тебе мешает выбрать все одним запросом и хранить результат в памяти. Простейшая функция на пхп тебе будет возвращать требуемый элемент....

 

[olegon]

To _RVK_
<Что тебе мешает выбрать все одним запросом и хранить результат в памяти. Простейшая функция на пхп тебе будет возвращать требуемый элемент.... >

Ну, это понятно, что так можно. А если мне не надо вытягивать все 50 элементов массива, а только 10-й и 40-й.
То зачем хранить в памяти остальные 48.
Не подумайте, что я извращаюсь тут, но просто хочется узнать - как обычно поступают с хранением переменных в таких играх, к примеру, как Бойцовский Клуб.

 

[_RVK_]

olegon
Не знаю как хранят данные в бойцовском клубе, но оптимизировать нужно тогда, когда это нужно. Преждевременная оптимизация - зло. Когда тебе не будет хватать памяти, купишь еще. Думаю к тому времен это будут для тебя сущие пустяки