Есть задача организовать хранение данных о нескольких игровых мирах
Не могу определиться - хранить все данные в одной таблице идентифицируя мир по полю в таблице или для каждого мира создавать отдельную таблицу по типу ru1_table, ru2_table.
Второй вариант хорош тем, что таблицы не получатся бесконечно большими, потому что раунд заканчивается и поступление данных прекращается.
PS это не игра, а сайт-дополнение к сторонней игре.
1. DelphinPRO - 24 Ноября, 2013 - 17:57:07 - перейти к сообщению
2. caballero - 24 Ноября, 2013 - 18:17:19 - перейти к сообщению
в одной
а если таблица будет большой используй партицирование
а если таблица будет большой используй партицирование
3. DelphinPRO - 24 Ноября, 2013 - 18:44:29 - перейти к сообщению
Ежедневно по 10-15 тысяч записей на каждый мир (4-7 миров одновременно) в течение года. Все ячейки - числовые (INT).
получается по ~38млн записей в год.
Это большая таблица?
получается по ~38млн записей в год.
Это большая таблица?
4. caballero - 24 Ноября, 2013 - 18:49:08 - перейти к сообщению
таблица как таблица
5. teddy - 24 Ноября, 2013 - 18:53:44 - перейти к сообщению
Хоть я и не самый "навидавшийся" в этом топике, но думаю есть смысл хранить в отдельных таблицах, если объем информации такой большой.
Потому что при селекте на сервере будут искаться записи тупым перебором всех строк в одной таблице, что займет много времени при исполнении запросов, особенно при отсутствии индексов
(Добавление)
А если под каждый город будет выделена своя таблица, то когда уже поиск будет происходить по конкретному городу, анализ будет проходить только по той таблице, которая имеет отношение к данному городу, при этом не затрагивая те записи, которые не имеют отношение к этому городу, как было бы в случае с одной таблицей.
Потому что при селекте на сервере будут искаться записи тупым перебором всех строк в одной таблице, что займет много времени при исполнении запросов, особенно при отсутствии индексов
(Добавление)
А если под каждый город будет выделена своя таблица, то когда уже поиск будет происходить по конкретному городу, анализ будет проходить только по той таблице, которая имеет отношение к данному городу, при этом не затрагивая те записи, которые не имеют отношение к этому городу, как было бы в случае с одной таблицей.
6. caballero - 24 Ноября, 2013 - 19:00:42 - перейти к сообщению
Цитата:
особенно при отсутствии индексов
а с чего бы им отсутствовать?
(Добавление)
Цитата:
А если под каждый город будет выделена своя таблица, то когда уже поиск будет происходить по конкретному городу
а если надо по всем городам? Будем UNION делать из всех таблиц?
перестань писать чушь. Сервера БД и придуманы для работы с большими объемами данных.
7. teddy - 24 Ноября, 2013 - 19:23:15 - перейти к сообщению
caballero пишет:
а если надо по всем городам?
Я на такие вопросы с ходу затрудняюсь ответить хотя бы потому, что проектирование это не дело пяти минут. Первое что приходит на ум, искать по отдельным таблицам(тут могу ошибиться в скорости); Но думаю такой вариант будет все же быстрее. Объясню почему я так думаю:
Дано:
- table1 - 5 записей
- table2 - 10 записей
- table3 - 10000000000000000 записей
Как ты думаешь, что будет быстрее, достать одну запись по условию из table1 и table2(возможно с использованием внешних ключей) или найти эти две записи в table3?
caballero пишет:
перестань писать чушь. Сервера БД и придуманы для работы с большими объемами данных.
Это не чушь. Есть ещё такое понятие как "оптимизация" и будет тебе известно, что на белом свете живут дяди, которые занимаются именно такими вопросами. Если говорить так как ты, то можно создавать приложения по принципу "работает ну и ладно, где сломается там сломается" - но это не есть хорошо.
П:С я ничего не утверждаю, но я бы скорее всего сделал несколько таблиц. Мое мнение по данной теме...
8. DelphinPRO - 24 Ноября, 2013 - 19:29:18 - перейти к сообщению
teddy пишет:
А если под каждый город будет выделена своя таблица
предполагалась отдельная таблица на каждый игровой мир. Данные разных миров никак не пересекаются, их объединение в запросах не потребуется.
(Добавление)
пока сделаю одну таблицу. будут проблемы - будем думать
9. teddy - 24 Ноября, 2013 - 19:41:22 - перейти к сообщению
Да я игровой мир имел ввиду, когда писал город... ) что то меня понесло в браузерки типа БК
Выбор конечно же за тобой, но как вариант если времени достаточно, можно имитировать нагрузку и количество записей в БД, написать несколько реализаций, решить чем и ради чего можно пожертвовать и в итоге выбрать оптимальный вариант
Пробежался как то раз по книге "Совершенный код", так вот, там преостерегали от таких решений и пишут, что "если что, то переделаю" - не самая лучшая идея... и я с ними от части согласен...
П:С прошу не воспринимать этот пост как критику
DelphinPRO пишет:
будут проблемы - будем думать
Выбор конечно же за тобой, но как вариант если времени достаточно, можно имитировать нагрузку и количество записей в БД, написать несколько реализаций, решить чем и ради чего можно пожертвовать и в итоге выбрать оптимальный вариант
Пробежался как то раз по книге "Совершенный код", так вот, там преостерегали от таких решений и пишут, что "если что, то переделаю" - не самая лучшая идея... и я с ними от части согласен...
П:С прошу не воспринимать этот пост как критику
10. caballero - 24 Ноября, 2013 - 19:52:22 - перейти к сообщению
Цитата:
будут проблемы - будем думать
не будет проблем
индекс на поле где номер мира и считай что данные разделены
(Добавление)
Цитата:
Это не чушь. Есть ещё такое понятие как "оптимизация" и будет тебе известно, что на белом свете живут дяди, которые занимаются именно такими вопросами.
эти дяди тебе точно так же бы и сказали - не пори чушь.
Цитата:
Как ты думаешь, что будет быстрее, достать одну запись по условию из table1 и table2(возможно с использованием внешних ключей) или найти эти две записи в table3?
я потому и написал про партицирование таблицы. Никто в здравом уме не лепит отдельную таблицу на отдельный екземпляр сущности.
Цитата:
прошу не воспринимать этот пост как критику
Он воспринимается как глупость потому критикой быть не может.
11. DelphinPRO - 24 Ноября, 2013 - 20:06:16 - перейти к сообщению
teddy Дело еще в том, что "одна таблица" - это весьма условно. на каждый мир будут таблы по игрокам, городам, странам, несколько с динамической статистикой. Если их дублировать на каждый мир - голова опухнет
В общем, посидел, прикинул, решил остановиться на общих таблицах с ключем по мирам.
В конце концов можно устроить "профилактику" раз в год, и ручками удалить неактуальные, устаревшие данные )
В общем, посидел, прикинул, решил остановиться на общих таблицах с ключем по мирам.
В конце концов можно устроить "профилактику" раз в год, и ручками удалить неактуальные, устаревшие данные )
12. teddy - 24 Ноября, 2013 - 22:47:48 - перейти к сообщению
caballero
что гупость? писать проект с первой мысли а дальше править если что то сломается? неет, последний мой пост(не считая этого) отличный подход при проектировании приложения. Гораздо проще "вылизать" приложение в момент его разработки, чем пытаться сделать это потом. Если ты не согласен, то у меня для тебя плохие новости
Я так не думаю. Я просто не вижу смысла вести поиск в одной таблице среди миллионов записей которые логически относятся к разным частям приложения. А давай вообще всё и везде хранить в одной таблице? зачем создавать лишние объекты...
А про партиции MySQL(хотя может у DelphinPRO и другая СУБД) начитался много гадкого...
caballero
Представь что проекту 10 лет. Да и увеличение популяции никто не отменял и это число может даже удвоиться.
раздели 38 млн на 7 и представь себе селект из пол миллиарда записей, будет тебе разница... это говорит о том что можно ускорить процесс и снизить нагрузку в 7 раз
Хоть БД и быстрая штука, но не до бесконечности. Грузить её бессовестно тоже не правильно я думаю. Это как говорить Арнольд Шварцнеггер сильный физически, чего он без груза слоняется, давай ему танк на плечи посадим, выдержит же скорее всего... вот это я думаю глупо особенно тогда, когда этот танк вообще не имеет никакого отношения к Арнольду. Не знаю как ты caballero, но я всегда за отделение "мух" от "котлет".
DelphinPRO
Тебе решать Мне если честно разницы нет... я сюда заглянул выразить свое мнение, за одно и послушать адекватную критику, которой к сожалению или даже к счастью не нашел...
что гупость? писать проект с первой мысли а дальше править если что то сломается? неет, последний мой пост(не считая этого) отличный подход при проектировании приложения. Гораздо проще "вылизать" приложение в момент его разработки, чем пытаться сделать это потом. Если ты не согласен, то у меня для тебя плохие новости
caballero пишет:
эти дяди тебе точно так же бы и сказали - не пори чушь.
Я так не думаю. Я просто не вижу смысла вести поиск в одной таблице среди миллионов записей которые логически относятся к разным частям приложения. А давай вообще всё и везде хранить в одной таблице? зачем создавать лишние объекты...
А про партиции MySQL(хотя может у DelphinPRO и другая СУБД) начитался много гадкого...
Цитата:
получается по ~38млн записей в год.
caballero
Представь что проекту 10 лет. Да и увеличение популяции никто не отменял и это число может даже удвоиться.
Цитата:
4-7 миров одновременно
раздели 38 млн на 7 и представь себе селект из пол миллиарда записей, будет тебе разница... это говорит о том что можно ускорить процесс и снизить нагрузку в 7 раз
Хоть БД и быстрая штука, но не до бесконечности. Грузить её бессовестно тоже не правильно я думаю. Это как говорить Арнольд Шварцнеггер сильный физически, чего он без груза слоняется, давай ему танк на плечи посадим, выдержит же скорее всего... вот это я думаю глупо особенно тогда, когда этот танк вообще не имеет никакого отношения к Арнольду. Не знаю как ты caballero, но я всегда за отделение "мух" от "котлет".
DelphinPRO
Тебе решать Мне если честно разницы нет... я сюда заглянул выразить свое мнение, за одно и послушать адекватную критику, которой к сожалению или даже к счастью не нашел...
13. caballero - 25 Ноября, 2013 - 00:01:00 - перейти к сообщению
teddy
Сначала поинтересуйся какие выборки будут на эту таблицу. Без этого нет смысла вообще рассуждать.
Никаких поисков по миллионам не будет. Потому как на поля учатсвующие в отборе очевидно будут поставлены индексы.
Опять же зависит от того кто будет юзать пользователи или админы будут просматривать статистику раз в день.
Кроме того работа с многими таблицами усложнит логику программы. Одно дело подставить условие другое дело менять имя таблицы. Если там mysql_query то еще куда ни шло. А если какой нибудь ORM используется. И как ты будет мапить эти таблицы, сэкономивши "на спичках" ?.
Вместо читать вумные книги займись лучше практическим програмированием.
Сначала поинтересуйся какие выборки будут на эту таблицу. Без этого нет смысла вообще рассуждать.
Никаких поисков по миллионам не будет. Потому как на поля учатсвующие в отборе очевидно будут поставлены индексы.
Опять же зависит от того кто будет юзать пользователи или админы будут просматривать статистику раз в день.
Кроме того работа с многими таблицами усложнит логику программы. Одно дело подставить условие другое дело менять имя таблицы. Если там mysql_query то еще куда ни шло. А если какой нибудь ORM используется. И как ты будет мапить эти таблицы, сэкономивши "на спичках" ?.
Вместо читать вумные книги займись лучше практическим програмированием.
14. DelphinPRO - 25 Ноября, 2013 - 00:41:17 - перейти к сообщению
teddy пишет:
писать проект с первой мысли а дальше править если что то сломается?
так и делаю но это хобби-проект, могу себе позволить..
teddy пишет:
Представь что проекту 10 лет
да, но как я уже сказал после закрытия мир, можно очистить таблицы от неактуальных данных. Думаю это приемлемо.
caballero пишет:
Сначала поинтересуйся какие выборки будут на эту таблицу
в основном джойны по нескольким таблицам. например выбрать данные по городам игрока или игроков страны, или города страны итп
caballero пишет:
Потому как на поля учатсвующие в отборе очевидно будут поставлены индексы.
разумеется. Более того ключевые поля все числовые INT
caballero пишет:
Если там mysql_query то еще куда ни шло.
голый PDO
caballero пишет:
Опять же зависит от того кто будет юзать пользователи или админы будут просматривать статистику раз в день.
обновление данных по крону раз-два в день
просмотр публичный
15. caballero - 25 Ноября, 2013 - 01:06:15 - перейти к сообщению
Вообще, если речь о статистике то есть смысл
ввести таблицу с итоговыми данными - ( со всеми агрегациями и группировками) и туда по крону периодически сгружать данные с основной таблицы.
Тогда вообще вопрос ыстродействия отпадет.
ввести таблицу с итоговыми данными - ( со всеми агрегациями и группировками) и туда по крону периодически сгружать данные с основной таблицы.
Тогда вообще вопрос ыстродействия отпадет.