Базы данных
→ Структура таблиц. Одна или много? • 1 сентября 2007 г. 21:00
Ну, тут уже вопрос проекта и даже я б сказал, маркетинговый :). на что "ставить", чем привлекать. И все таки самое главное. Еще пару месяцев назад я вообще ничего не знал о пхп и MySQL :). А задачка чата, ИМХО, как раз хороша для обучения :) себя
Ну, тут уже вопрос проекта и даже я б сказал, маркетинговый :). на что "ставить", чем привлекать.
И все таки самое главное. Еще пару месяцев назад я вообще ничего не знал о пхп и MySQL :). А задачка чата, ИМХО, как раз хороша для обучения :) себя
Базы данных
→ Структура таблиц. Одна или много? • 31 августа 2007 г. 20:37
Базы данных
→ Структура таблиц. Одна или много? • 31 августа 2007 г. 17:44
Базы данных
→ Структура таблиц. Одна или много? • 31 августа 2007 г. 14:07
нет, хоть и игрался во всякие ХХ, но не люблю их за то, что любой хх-летний папенькин сынок(дочка) может вложить денежков и качайся как угодно, а его не победишь.Хочу сделать небольшой проектик для тех, кто любит думать, хотя бы иногда :). На уровне шашек хотя бы… ну и вкусности некоторые е...
нет, хоть и игрался во всякие ХХ, но не люблю их за то, что любой хх-летний папенькин сынок(дочка) может вложить денежков и качайся как угодно, а его не победишь.
Хочу сделать небольшой проектик для тех, кто любит думать, хотя бы иногда :). На уровне шашек хотя бы… ну и вкусности некоторые есть в задумках. Есс-но в будущем хотелось бы с этого проектика чуть-чуть и получить, а пока в одиночку делаю… практически дял души и для изучения… назовем это "веб-программингом".
Базы данных
→ Структура таблиц. Одна или много? • 31 августа 2007 г. 12:19
Конструктивный вопрос. новый, но связанный :).Есть таблица сообщений чата. Кто, когда и что отпарвил.Как оптимально организовать приват? С учетом того, что приват будет возможен сразу нескольким игрокам? Группе игроков… 1)Делать отдельное поле "текст", куда запихивать через раздел...
Конструктивный вопрос. новый, но связанный :).
Есть таблица сообщений чата. Кто, когда и что отпарвил.
Как оптимально организовать приват? С учетом того, что приват будет возможен сразу нескольким игрокам? Группе игроков…
1)Делать отдельное поле "текст", куда запихивать через разделитель логины игроков?
2)делать отдельнуь таблицу… хм, тут опять же варианты вроед есть…
3)делать в том же поле, где сам текст, со спецразделителями, но тогда проблемочка с редактированием этих полей…
Доступных примеров нормальных чатов нету :(
Базы данных
→ Структура таблиц. Одна или много? • 30 августа 2007 г. 21:09
Базы данных
→ Структура таблиц. Одна или много? • 30 августа 2007 г. 21:04
У игроков 2, 3, 4, 5,6 происходит периодический запрос, который разворачивает массив, смотрит, нет ли изменений, отсылает новое положение для отображения…Да, именно так и делается. И какие проблемы?по времени проигрыш… ведь сериализация и ансериализация будет производится после каждо...
У игроков 2, 3, 4, 5,6 происходит периодический запрос, который разворачивает массив, смотрит, нет ли изменений, отсылает новое положение для отображения…
Да, именно так и делается. И какие проблемы?
по времени проигрыш… ведь сериализация и ансериализация будет производится после каждого хода и не одна… а всем игрокам… оченн не удобно ИМХО… причем в "клеточке" хранится не просто число или строка, а… объект практически… здоровье типа, наложенное заклинание и иные модификаторы юнита… помимо его айди…
Базы данных
→ Структура таблиц. Одна или много? • 30 августа 2007 г. 17:53
Сериализация не катит… думал уже… массив же динамический… существует только в данный момент.. он мне через час не нужен :) да и через минуту после окончания боя…Выходит а то, что получен ход игрока1. разворачиваем массив, изменяем, сворачиваем, запоминаем.У игроков 2, 3, 4...
Сериализация не катит… думал уже… массив же динамический… существует только в данный момент.. он мне через час не нужен :) да и через минуту после окончания боя…
Выходит а то, что получен ход игрока1. разворачиваем массив, изменяем, сворачиваем, запоминаем.
У игроков 2, 3, 4, 5,6 происходит периодический запрос, который разворачивает массив, смотрит, нет ли изменений, отсылает новое положение для отображения… как то кривовато… по идее, для нормальных, а не онлайн игрушек такой массив хранится в памяти, а потом просто зануляется и все :)…
Базы данных
→ Структура таблиц. Одна или много? • 30 августа 2007 г. 17:41
Базы данных
→ Структура таблиц. Одна или много? • 30 августа 2007 г. 17:13
Базы данных
→ Структура таблиц. Одна или много? • 30 августа 2007 г. 16:47
Не, я не считаю, что для каждого элемента должна быть своя табличкая. именно в данном случае казалось что так оптимальнее… но вроде как отговорили :) в принципе… табличка не будет сильно динамичная, меняется редко, так что… согласен, что с одной гораздо удобнее…Но тогда в ...
Не, я не считаю, что для каждого элемента должна быть своя табличкая. именно в данном случае казалось что так оптимальнее… но вроде как отговорили :) в принципе… табличка не будет сильно динамичная, меняется редко, так что… согласен, что с одной гораздо удобнее…
Но тогда в продолжение темы… вопрос про бой… что посоветуете?
В момент начала боя формируется массив предположим 10на10 клеток, для простоты они либо пустые, либо ссылка (хм, тогда точно нужна одна большая табличка с индивидуальными айди) на юниты игроков, которые в процессе боя перемещаются, погибают… т.е. нужно хранить этот массив объектов. После окончания боя массив в принципе не нужен, удаляется. разве только ходы запсиатьв отдельны файл. но это уже из другой оперы… (из другого эксплорера=))
как построить таблицы в этмо случае? предположим одновременно может происходить до 100 боев… опять же (пусть я новичок) логично напрашивается структура вида:
таблица1
айди_боя, оппонент1, оппонент2, оппонет3 (т.е. кто в этом бою)
таблица boj+айди_боя
клетка11 айди_юнита, здоровье в текущем бою, модификаторы в текущем бою…
клетка12
клетка13
но опять же получаются динамически генерящиеся таблицы, которые меня смущают…
а еще ведь ходы надо запоминать, чтоб была возможность потом запомнить в файл…
делать опять же через одну табличку дял всех боев?
айди_боя, клетка11….
айди_боя, клетка12…
и т.д.
ага, вспомнил, чем мне не нравится одна таблица… блокировками… в случае множества мелких, каждый "боец" работает со своей, а тут сотня (хм, а ведь не много)….
Базы данных
→ Структура таблиц. Одна или много? • 30 августа 2007 г. 16:03
сделай таблицу состояний,первая колонка айди юзера,вторая айди вещи,3я износ,четвертая цена по которой ее приобрел юзер и т.д. и т.п.Вот вопрос про это изначально и идет… ведь в этом случае: занимается "лишнее" место на повторение айди юзера, хранятся вещи по одному юзеру не подря...
сделай таблицу состояний,первая колонка айди юзера,вторая айди вещи,3я износ,четвертая цена по которой ее приобрел юзер и т.д. и т.п.
Вот вопрос про это изначально и идет… ведь в этом случае: занимается "лишнее" место на повторение айди юзера, хранятся вещи по одному юзеру не подряд(хотя… это проблемой быть не должно выборке пофигу :) )
но возникла идея сэкономить место на индексы и на саму табличку… сделать несколько маленьких, но что-то смущает в этом…
Базы данных
→ Структура таблиц. Одна или много? • 30 августа 2007 г. 15:26
1)Сорри за невольную рекламу. Хотел взять название в кавычки, как имя нарицательное… ну а так даже лучше :). (А ничего, что я как бы свой проект "рекламирую", хотя он еще и не сделан…)ничего=)2)Для тех, кто в танке (без обид). Я не собираюсь хранить ВСЕ в одной табличке. Есс...
1)Сорри за невольную рекламу. Хотел взять название в кавычки, как имя нарицательное… ну а так даже лучше :). (А ничего, что я как бы свой проект "рекламирую", хотя он еще и не сделан…)
ничего=)
2)Для тех, кто в танке (без обид). Я не собираюсь хранить ВСЕ в одной табличке. Есстественно одна таблица для пользователей. ЕЩЕ одна для базовых свойств вещи. Вопрос конкретный, как удобнее (оптимальнее) хранить наборы вещей конкретного пользователя, с учетом того, что эти вещи будут уметь индивидуальные характеристики, которые определяются по ДВУМ ключам: по ид игрока и по ид вещи. Т.е. броня у игрока1 может иметь износ 20, а у игрока 2 такая же броня, но уже износилась на 30 пунктов. Более конкретный вопрос, чем чревато на практике хранить данные в большой куче (10000) маленьких табличек.
ПС Как раз сейчас и занимаюсь тем, что пытаюсь сначала на листочке смоделировать структуру.
ПСС Нуп я… пхп изучаю меньше месяца… чат для проекта сделал, а вот дальше уперся в правильную структуру таблиц, чтоб потом не переделывать…
ПССС На самом деле проект задумывается для… думающих игроков, т.е. "бой" будет не тупым расставлением точек, но это уже могут и правда рекламой определить… просто маячит еще один "философский" вопрос: как оптимально хранить таблицу боя и ходов? Массив клеток, с юнитами и что они делали.. опять же… или под каждый бой делать отдельную табличку, а потом ее уничтожать (сохранив к прмиеру) или одну большую и чистить периодически…
Так все таки ОДНА таблицка (ну или две, три) большая или много-много маленьких…
Базы данных
→ Структура таблиц. Одна или много? • 30 августа 2007 г. 13:44
Типичный, ну к примеру рассмотрим ХХ, проект. Т.е. вещи конечно же делятся по "виду", но могут иметь отличия, в частности, износ ЭТОЙ конкретной вещи.Т.е. Игрок1, у него есть Броня Шикарная (есстественно тут имеется табличка с базовыми свойствами данной брони, вещей). Про параметры поль...
Типичный, ну к примеру рассмотрим ХХ, проект. Т.е. вещи конечно же делятся по "виду", но могут иметь отличия, в частности, износ ЭТОЙ конкретной вещи.
Т.е. Игрок1, у него есть Броня Шикарная (есстественно тут имеется табличка с базовыми свойствами данной брони, вещей). Про параметры пользователя речь НЕ ИДЕТ!!!! просьба не "захламлять" вопрос подвопросами :).
Есть таблица пользователей вида: ид_игрока, логин, пассворд.
Есть таблица вещей вида: ид_вещи, параметр1, параметр2…
Вопрос создать третью ОДНУ таблицу, где будут пересекаться ид_игрока, ид_вещи и индивидуальные параметры ВЕЩИ типа износа (т.е. износилась данная броня на 20 пунктов).
Решение 1:
ид_игрока, ид_вещи, износ, уведичение параметра1… и т.п. (возможно ид_вещи конкретной, этой)
Решение 2:
таблица с именем vesh+ид_игрока
ид_вещи, износ, увеличение параметра1 и тп
Давайте не будем рекламировать проекты,не будем упоминать названия,здесь не рекламное агентство
Базы данных
→ Структура таблиц. Одна или много? • 30 августа 2007 г. 12:51
Ну, предположим, игровой проект. Есть пользователь игрок, со своими параметрами типа ловкостей и удачи всяких. И у него есть… вещи, которые имеют свой износ к примеру и иные \"модификаторы\". И вещей будет от 30 до 100 ориентировочно. Так вот и думаю, как же оптимальнее… либ...
Ну, предположим, игровой проект. Есть пользователь игрок, со своими параметрами типа ловкостей и удачи всяких. И у него есть… вещи, которые имеют свой износ к примеру и иные \"модификаторы\". И вещей будет от 30 до 100 ориентировочно. Так вот и думаю, как же оптимальнее… либо каждому пользователю свою табличку, но тогда будет 10К табличек по 100 строк каждая или одну с 1000К строк, в каждой из которых \"лишнее\" поле ид_игрока. Вроде бы оптимальнее много табличек, но я на практике с таким не сталкивался, вот и озадачился заранее :) не будет ли с этим проблем. Опять же… вещи эти могут переходить от одного игрока к другому и вроде бы нужен уникальный ид_вещи… или необязателен…
Базы данных
→ Структура таблиц. Одна или много? • 30 августа 2007 г. 12:26
Проектирую структуру для маленького проектика. (Ньюб однозначно, но делать то надо :) ).Есть таблица с данными пользователей (логин, пароль и тп). Нужно создать структуру для хранения данных о НАБОРЕ неких объектов у каждого пользователя. И вот тут встает вопрос, что оптимальнее (в первую очередь...
Проектирую структуру для маленького проектика. (Ньюб однозначно, но делать то надо :) ).
Есть таблица с данными пользователей (логин, пароль и тп). Нужно создать структуру для хранения данных о НАБОРЕ неких объектов у каждого пользователя. И вот тут встает вопрос, что оптимальнее (в первую очередь быстрее, но важно учесть, что место на хосте тоже не безгранично :) ). Или создать одну большую таблицу: ид_пользователя, ид_объекта и куча параметров. Или каждому пользователю генерить небольшую табличку с названием зависящим от ид: ид_объекта, параметры.
Ориентировочно до 10000 пользователей.
Работа с данной табличкой будет частенько на чтение. Реже на измененние.
основной вопрос я бы сформулировал так: чем-то чревато создание 10000 маленьких табличек, особенно интересует парктическая сторона, как то: возможности наших хостеров и тп
Сумбурно чуть-чуть вышло, но вроде понятно :)!?
