данные по игровым мирам: отдельные таблицы или поле в общей таблице

Есть задача организовать хранение данных о нескольких игровых мирах
Не могу определиться - хранить все данные в одной таблице идентифицируя мир по полю в таблице или для каждого мира создавать отдельную таблицу по типу ru1_table, ru2_table.
Второй вариант хорош тем, что таблицы не получатся бесконечно большими, потому что раунд заканчивается и поступление данных прекращается.

PS это не игра, а сайт-дополнение к сторонней игре.

(Отредактировано автором: 24 Ноября, 2013 - 17:58:00)

-----
Чем больше узнаю, тем больше я не знаю.

в одной
а если таблица будет большой используй партицирование

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

Ежедневно по 10-15 тысяч записей на каждый мир (4-7 миров одновременно) в течение года. Все ячейки - числовые (INT).
получается по ~38млн записей в год.
Это большая таблица?

-----
Чем больше узнаю, тем больше я не знаю.

таблица как таблица

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

Хоть я и не самый "навидавшийся" в этом топике, но думаю есть смысл хранить в отдельных таблицах, если объем информации такой большой.

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

а с чего бы им отсутствовать?
(Добавление)

а если надо по всем городам? Будем UNION делать из всех таблиц?

перестань писать чушь. Сервера БД и придуманы для работы с большими объемами данных.

(Отредактировано автором: 24 Ноября, 2013 - 19:03:40)

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

Я на такие вопросы с ходу затрудняюсь ответить хотя бы потому, что проектирование это не дело пяти минут. Первое что приходит на ум, искать по отдельным таблицам(тут могу ошибиться в скорости); Но думаю такой вариант будет все же быстрее. Объясню почему я так думаю:
Дано:
- table1 - 5 записей
- table2 - 10 записей
- table3 - 10000000000000000 записей

Как ты думаешь, что будет быстрее, достать одну запись по условию из table1 и table2(возможно с использованием внешних ключей) или найти эти две записи в table3?


Это не чушь. Есть ещё такое понятие как "оптимизация" и будет тебе известно, что на белом свете живут дяди, которые занимаются именно такими вопросами. Если говорить так как ты, то можно создавать приложения по принципу "работает ну и ладно, где сломается там сломается" - но это не есть хорошо.

П:С я ничего не утверждаю, но я бы скорее всего сделал несколько таблиц. Мое мнение по данной теме...

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

-----
Чем больше узнаю, тем больше я не знаю.

Да я игровой мир имел ввиду, когда писал город... ) что то меня понесло в браузерки типа БК

Выбор конечно же за тобой, но как вариант если времени достаточно, можно имитировать нагрузку и количество записей в БД, написать несколько реализаций, решить чем и ради чего можно пожертвовать и в итоге выбрать оптимальный вариант

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

П:С прошу не воспринимать этот пост как критику

не будет проблем
индекс на поле где номер мира и считай что данные разделены
(Добавление)

эти дяди тебе точно так же бы и сказали - не пори чушь.


я потому и написал про партицирование таблицы. Никто в здравом уме не лепит отдельную таблицу на отдельный екземпляр сущности.


Он воспринимается как глупость потому критикой быть не может.

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

teddy Дело еще в том, что "одна таблица" - это весьма условно. на каждый мир будут таблы по игрокам, городам, странам, несколько с динамической статистикой. Если их дублировать на каждый мир - голова опухнет
В общем, посидел, прикинул, решил остановиться на общих таблицах с ключем по мирам.
В конце концов можно устроить "профилактику" раз в год, и ручками удалить неактуальные, устаревшие данные )

-----
Чем больше узнаю, тем больше я не знаю.

caballero
что гупость? писать проект с первой мысли а дальше править если что то сломается? неет, последний мой пост(не считая этого) отличный подход при проектировании приложения. Гораздо проще "вылизать" приложение в момент его разработки, чем пытаться сделать это потом. Если ты не согласен, то у меня для тебя плохие новости


Я так не думаю. Я просто не вижу смысла вести поиск в одной таблице среди миллионов записей которые логически относятся к разным частям приложения. А давай вообще всё и везде хранить в одной таблице? зачем создавать лишние объекты...

А про партиции MySQL(хотя может у DelphinPRO и другая СУБД) начитался много гадкого...


caballero
Представь что проекту 10 лет. Да и увеличение популяции никто не отменял и это число может даже удвоиться.

раздели 38 млн на 7 и представь себе селект из пол миллиарда записей, будет тебе разница... это говорит о том что можно ускорить процесс и снизить нагрузку в 7 раз

Хоть БД и быстрая штука, но не до бесконечности. Грузить её бессовестно тоже не правильно я думаю. Это как говорить Арнольд Шварцнеггер сильный физически, чего он без груза слоняется, давай ему танк на плечи посадим, выдержит же скорее всего... вот это я думаю глупо особенно тогда, когда этот танк вообще не имеет никакого отношения к Арнольду. Не знаю как ты caballero, но я всегда за отделение "мух" от "котлет".

DelphinPRO
Тебе решать Мне если честно разницы нет... я сюда заглянул выразить свое мнение, за одно и послушать адекватную критику, которой к сожалению или даже к счастью не нашел...

(Отредактировано автором: 24 Ноября, 2013 - 23:05:48)

teddy
Сначала поинтересуйся какие выборки будут на эту таблицу. Без этого нет смысла вообще рассуждать.

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

Кроме того работа с многими таблицами усложнит логику программы. Одно дело подставить условие другое дело менять имя таблицы. Если там mysql_query то еще куда ни шло. А если какой нибудь ORM используется. И как ты будет мапить эти таблицы, сэкономивши "на спичках" ?.

Вместо читать вумные книги займись лучше практическим програмированием.

(Отредактировано автором: 25 Ноября, 2013 - 00:18:55)

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

так и делаю но это хобби-проект, могу себе позволить..


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


в основном джойны по нескольким таблицам. например выбрать данные по городам игрока или игроков страны, или города страны итп


разумеется. Более того ключевые поля все числовые INT


голый PDO


обновление данных по крону раз-два в день
просмотр публичный

-----
Чем больше узнаю, тем больше я не знаю.

Вообще, если речь о статистике то есть смысл
ввести таблицу с итоговыми данными - ( со всеми агрегациями и группировками) и туда по крону периодически сгружать данные с основной таблицы.
Тогда вообще вопрос ыстродействия отпадет.

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore