Форум → Разработка → Базы данных → Структура таблиц. Одна или много?
Структура таблиц. Одна или много?
Страницы: ← Предыдущая страница • Следующая страница →
-
Авг. 30, 2007, 4:31 п.п., спустя 17 минут 30 секунд
да ладно тебе…ты как сэкономишь место при добавление отдельных табличек???это же просто маразм,действительно детская ошибка новичков,наивно полагающих,что для каждого элемента должна существовать своя структура…Том Кайт в гробу перевернулся бы.. -
Авг. 30, 2007, 4:47 п.п., спустя 15 минут 24 секунды
Не, я не считаю, что для каждого элемента должна быть своя табличкая. именно в данном случае казалось что так оптимальнее… но вроде как отговорили :) в принципе… табличка не будет сильно динамичная, меняется редко, так что… согласен, что с одной гораздо удобнее…
Но тогда в продолжение темы… вопрос про бой… что посоветуете?
В момент начала боя формируется массив предположим 10на10 клеток, для простоты они либо пустые, либо ссылка (хм, тогда точно нужна одна большая табличка с индивидуальными айди) на юниты игроков, которые в процессе боя перемещаются, погибают… т.е. нужно хранить этот массив объектов. После окончания боя массив в принципе не нужен, удаляется. разве только ходы запсиатьв отдельны файл. но это уже из другой оперы… (из другого эксплорера=))
как построить таблицы в этмо случае? предположим одновременно может происходить до 100 боев… опять же (пусть я новичок) логично напрашивается структура вида:
таблица1
айди_боя, оппонент1, оппонент2, оппонет3 (т.е. кто в этом бою)
таблица boj+айди_боя
клетка11 айди_юнита, здоровье в текущем бою, модификаторы в текущем бою…
клетка12
клетка13
но опять же получаются динамически генерящиеся таблицы, которые меня смущают…
а еще ведь ходы надо запоминать, чтоб была возможность потом запомнить в файл…
делать опять же через одну табличку дял всех боев?
айди_боя, клетка11….
айди_боя, клетка12…
и т.д.
ага, вспомнил, чем мне не нравится одна таблица… блокировками… в случае множества мелких, каждый "боец" работает со своей, а тут сотня (хм, а ведь не много)…. -
Авг. 30, 2007, 5:05 п.п., спустя 18 минут 21 секунду
нет…логи можно хранить в лог-файлах,по-моему это очень оптимально,потом парсировать и вставлять в готовый шаблон
Но если с базой ,то создаем таблицу логов,1й столбец айди боя,второй - айди игроков 1й команды,3й айди игроков 2й команды,4й ряд лог боя
в виде строки id- where striked - where blocked - if striked - if blocked(все это цифры) нормированность вследствии непредсказуемости кол-ва игроков и ходов не получится…налицо парсинг
При каждом ходе происходит последовательная запись в базу -
Авг. 30, 2007, 5:13 п.п., спустя 7 минут 52 секунды
Ну тут согласен. Логи все таки сразу в файлы… тут уж точно каждый бой в один файл. А начальное расположение и текущее состояние массива юнитов, точнее массив территории, где ходят юниты. Т.е. в клетке 11 стоит юнит такой-то, в клетке 12 никого нету… Т.е. тот массив, который отображается у игроков и соответственно меняется при команде одного из игроков типа сходить таким-то юнитом туда-то… -
-
Авг. 30, 2007, 5:41 п.п., спустя 27 минут 5 секунд
1)Бой происходит в виде передвижения юнитов по клеточкам. типа шахмат.
2)Т.е. когда два игрока "входят" в бой формируется массив клеточек, в каждой из которых может находится юнит или пусто.
3)массив этот динамический - изменяется после каждого "хода".
4)доступ к этому массиву должен быть у нескольких игроков, чтобы отображать им текущую ситуацию
5)как хранить это массив? -
Авг. 30, 2007, 5:45 п.п., спустя 3 минуты 48 секунд
можно сериализовать массив
http://ru2.php.net/manual/ru/function.serialize.php
http://ru2.php.net/manual/ru/function.unserialize.phpвсе умрут, а я изумруд -
Авг. 30, 2007, 5:53 п.п., спустя 8 минут
Сериализация не катит… думал уже… массив же динамический… существует только в данный момент.. он мне через час не нужен :) да и через минуту после окончания боя…
Выходит а то, что получен ход игрока1. разворачиваем массив, изменяем, сворачиваем, запоминаем.
У игроков 2, 3, 4, 5,6 происходит периодический запрос, который разворачивает массив, смотрит, нет ли изменений, отсылает новое положение для отображения… как то кривовато… по идее, для нормальных, а не онлайн игрушек такой массив хранится в памяти, а потом просто зануляется и все :)… -
Авг. 30, 2007, 6:07 п.п., спустя 14 минут 10 секунд
делай временную таблицу
которую потом просто чистьвсе умрут, а я изумруд -
Авг. 30, 2007, 6:08 п.п., спустя 39 секунд
У игроков 2, 3, 4, 5,6 происходит периодический запрос, который разворачивает массив, смотрит, нет ли изменений, отсылает новое положение для отображения…
Да, именно так и делается. И какие проблемы? -
Авг. 30, 2007, 9:04 п.п., спустя 2 часа 56 минут 21 секунду
У игроков 2, 3, 4, 5,6 происходит периодический запрос, который разворачивает массив, смотрит, нет ли изменений, отсылает новое положение для отображения…
Да, именно так и делается. И какие проблемы?
по времени проигрыш… ведь сериализация и ансериализация будет производится после каждого хода и не одна… а всем игрокам… оченн не удобно ИМХО… причем в "клеточке" хранится не просто число или строка, а… объект практически… здоровье типа, наложенное заклинание и иные модификаторы юнита… помимо его айди… -
Авг. 30, 2007, 9:09 п.п., спустя 4 минуты 59 секунд
делай временную таблицу
которую потом просто чисть
Гыыы… в этом и вопрос… была б одна таблица… а тут под каждый бой свою выходит… 100 "табличек " одновременно… а выше меня в хвост и в гриву "отругали" за множество мелких таблиц… хотя некоторые "учебники" рекомендуют все таки большео количество таблиц вместо одной глобальной… буду читать…
спасибо всем за идеи/мысли/возражения… а кто нибудь приличный чат на аяксе делал? если не секрет то хотелось бы тоже по поводу структуры таблиц поспрашать… некоторые вопросики… а то переделывать в будущем не хочется… велосипед изобретать нет желания, только я так понял - это "секретная" информация… :) -
Авг. 30, 2007, 9:32 п.п., спустя 22 минуты 17 секунд
по времени проигрыш…
Да хватит выдумывать в голове всякие проигрыши. Видно, что вы в оптимизации еще не слишком хорошо разбираетесь, так зачем строить умозаключения основываясь ни на чем? Попробуйте сделать. Будет тормозить, значит тогда и переделаете.причем в "клеточке" хранится не просто число или строка, а… объект практически… здоровье типа,
Ну вообще-то это не в клеточке должно храниться, а отдельно храниться юнит со своими параметрами и быть указано, где он находится.хотя некоторые "учебники" рекомендуют все таки большео количество таблиц вместо одной глобальной…
Уверен, что они под этим подразумевают как можно большее разбиение данных по их типам. Таблица же на каждого пользователя, это растаскивание однородных данных по разным углам. -
Авг. 31, 2007, 10:10 д.п., спустя 12 часов 38 минут 32 секунды
Сэм,хватит обсасывать кость,если есть другие конструктивные вопросы по БД,задавай,на одном месте топтаться не стоит. -
Авг. 31, 2007, 12:19 п.п., спустя 2 часа 9 минут 2 секунды
Конструктивный вопрос. новый, но связанный :).
Есть таблица сообщений чата. Кто, когда и что отпарвил.
Как оптимально организовать приват? С учетом того, что приват будет возможен сразу нескольким игрокам? Группе игроков…
1)Делать отдельное поле "текст", куда запихивать через разделитель логины игроков?
2)делать отдельнуь таблицу… хм, тут опять же варианты вроед есть…
3)делать в том же поле, где сам текст, со спецразделителями, но тогда проблемочка с редактированием этих полей…
Доступных примеров нормальных чатов нету :(
Страницы: ← Предыдущая страница • Следующая страница →
Пожалуйста, авторизуйтесь, чтобы написать комментарий!