Как организовывать Бд достаточно сложной игры

[Illusiony]

Допустим для игры имеется Бд, допустим MySQL.
Например около 30 таблиц разного размера и сложности.
В некоторой части таблиц производится постоянное пополнение данных путем добавления новых строк в таблице, например id постоянно увеличивается, и при этом часть id предыдущих данных не нужны, а часть нужны, но если их просто перенести, то сслылочные данные не будут верны.

Как ограничивать размер бд в таком случае?
То сесть нужно все равно изменять ссылки, но это практически нереально
Как организовать БД довольно сложной по экономике и механике игры?

Начал разрабатывать игрушку многопользовательскую с сложной экономикой и возможно механикой.

Так вот сложность организации таблиц бд достаточно велика.
Часть данных будет постоянно пополнятся, а часть будет неактуальна.

Как же организовать такую структуру таблиц и как их модифицировать для уменьшения размера с учетом того что, при при перезаписи в неактуальные строки бд новых данных поменяется их так скажем id, и ссылку тоже необходимо менять, а это очень геморно учитывая сложность задачи.

[Stilet]

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

Что-т я не понял почему первичный ключ (если речь идет о нем) должен меняться при редактировании таблицы?

для уменьшения размера

Без геморроя уменьшаться умеют только файловые СУБД (и то не все). Как правило в 90% БД разношерстных их пополнение данными и удаление не приводит к уменьшению размера файла базы - и в этом есть своя целесообразность. В этом случае приходится делать backup-restore. Хотя в случае с Сиквелом или Лотусом этого можно избежать - у него есть инструмент поджимания файлов.

[Виталий Желтяков]

- Денормализация;
- Ключ архивирования;
- Таблица шттщвию

[Illusiony]

Лучше б эту тему закрыли, а не вот эту http://programmersforum.ru/showthread.php?t=255284
Ну хоть эту оставьте одну единственную.
Прошу помощи по вопросу вот этой темы http://programmersforum.ru/showthread.php?t=255284

[phomm]

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

Модуль например - это справочная сущность, их количество у Вас сильно меняться вряд ли будет. Игрок - другая сущность, но уже клиентская, т.к. постоянно растёт и меняется (баны всякие и разбаны) и приложение всегда будет проверять этот список, а каждый игрок будет постоянно проверять свои данные (читать характеристики хотя бы). А вот таблица модулей_у_игроков будет уже сводная - в ней будут ссылки на игрока и на модуль.
Возможно, свойства/фичи для модулей это тоже будет отдельная таблица, справочник с конкретными свойствами каждой фичи, и тогда понадобится таблица один ко многим связывающая модули с включенными в модуль фичами.

О денормализации и прочих оптимизациях стоит думать, но сперва должно написать логику, а не гнаться за тем, что даже пощупать нельзя без рабочей системы, хотя бы на бумаге, а уж строки/байтики да размер базы это просто неграмотное отношение, т.к. преждевременная оптимизация - в целом плоха и это пора уже знать. Менять ссылки, данные и подобные вещи - путь к краху, данные трогать вне бизнес-логики попросту опасно.

[Illusiony]

Да большое спасибо за ответ.
Я никогда не занимался базами данных серьезно и достаточной сложности.
Могли бы посоветовать литературу по этому поводу или блоги с примерами.

[dampirik]

Абсолютно согласен с phomm, не стоит на начальном этапе заниматься преждевременной оптимизацией, как не крутите в процессе разработке у Вас еще много что измениться и оценивать объёмы БД на стадии идеи очень тяжело.
P.S.
Как пример, на сервере я храню небольшую статистику по своему приложению, по селекту он из всей таблицы формирует необходимые данные. Сперва создал просто таблицу без индексов, в результате за год накопилось 1.5милиона записей, запрос стал выполняться 4 сек., сделал индексы, поправил запросы, получил 0.1 сек. На текущий момент меня это вполне устраивает, нужно будет быстрее - сделаю кэш и кучу - кучу других вариантов оптимизации.

[Illusiony]

Стал потихоньку разрабатывать структуру таблиц Бд. У меня нету опыта в этом плане. Немного почитал о связях в таблицах, но полного понимания нету пока что. Начну с простого.
Нужна таблица с данными авторизации, премиальных данных, данных навыков игроков.
В принце пе все эти данные могут быть в 1 таблице, но частота обращений к ним разная и они содержат смысловые различия в использовании данных.
Так вот если из 1 таблицы сделать 3 связанных таблицы, как такая структура называется и и как ее реально создать на MySql.
1) таблица авторизация
2) Премиум
3) навыки
В каждой таблице первичный ключ (в виде числа) в первом столбце, второй столбец у каждой логин.
В таком случае в этих таблицах эти 2 поля первых одинаковые.
Но поиск будет по логину, это нормально?

Опишите эту ситуацию пожалуйста.

[waleri]

Прочитайте про FOREIGN KEY

[Illusiony]

Если, допустим сравнивать 1 большую таблицу и 3 небольших связанных таблицы.
В чем разница в плане производительности и ресурсов? В связанных таблицах запрос реально идет в каждую отдельную таблицу или это лишь для удобства?

Для таких связей используется только innoDB. Но если имеются сложные условия связи, которые затрудняют реализацию связей или делают это невозможным, то использование связанных таблиц непригодно, да и к тому же для некоторых задач MyIsam быстрее.
Возможно ли комбинированное использование данных типов таблиц?