Костыли в базе данных

@Dragon6 · Регистрация: 10.02.2011

Студворк — интернет-сервис помощи студентам

Здравствуйте.
Проектирую БД для небольшого своего проекта (что-то вроде форумной ролевой игры).
У меня есть таблицы:
characters - персонажи, их имена, расы, характеристики,
races - возможные расы, соединяется с таблицей characters связью один-ко-многим
creatures - мобы, их имена, описания, характеристики.
Как вы могли заметить, у персонажей и существ есть характеристики, причем они абсолютно идентичны (стандартные сила, ловкость, телосложение, интеллект). Вот я и решил вынести их в отдельную таблицу characteristics. Но тогда столкнулся с следующей "проблемой" - соединять ее с этими таблицами связью один-к-одному (то есть, по первичному ключу) проблематично, а в противном случае получается связь один-ко-многим. То есть, один и тот же персонаж (либо один и тот же моб, либо один из персонажей и один из мобов) имеют один и тот же список характеристик, а значит - изменится у одного, изменится и у другого. Чисто практически, эта проблема, как мне кажется, не очень глобальна, так как такие пересечения довольно легко обойти, но вообще получается костыль...
Как мне поступить в таком случае? Объединить характеристики с персонажами и существами, а в случае изменения списка характеристик просто менять их в двух местах?
Для большей ясности картины, прикладываю примерную схему БД:

@sKotenok · 26.04.2014, 11:51

Dragon6, создайте таблицу current_characteristics и храните там текущие значения характеристик для каждого перса (моба)!.
Вообще - зачем вам 3 отдельные таблицы? characters, creatures, characteristics - можно свести в одну.

@Dragon6 · 26.04.2014, 17:38 **[ТС]**

Сообщение от sKotenok

Вообще - зачем вам 3 отдельные таблицы? characters, creatures, characteristics - можно свести в одну.

Например?

@sKotenok · 26.04.2014, 19:06

Dragon6, я не знаю всех глубин логики и как оно у вас устроено, поэтому описываю издалека.
- Расы. явно нужны.
- Персонажи. Логично, что нужны. Но! Скорее всего нужные 2 таблицы:
1 - справочник (каких персонажей вообще можно создавать). Тут начальные значения характеристик и т.п.
(Возможно, что "Расы" - как раз и будет этим справочником, или же там нечто иное)
2 - оперативная (кто сейчас присутствует в игре). При появлении сюда копируется запись, при "умирании", она отсюда удаляется. По сути тут инстансы (обьекты), а в 1й - классы, если сравнить с ООП.
- Характеристики - Логично держать в таблице "Персы" чем юзать связь 1-1.
- Мобы - Почему бы не закинуть их в таблицу к Персам, добавив поле "Играбелный/бот" - это упростит итоговую структуру до 2х-3х таблиц, с которыми работать можно единообразно.

@Dragon6 · 27.04.2014, 20:24 **[ТС]**

sKotenok, В принципе, я с вами согласен, но насчет мобов, их с персонажами совмещать в одну таблицу, невзирая на то, что их структура немного разная? (то есть, мобы имеют описание desc, которого нет у персонажей и т.д.)
И насчет характеристик, я их решил вынести в отдельную таблицу по той причине, что довольно много объектов будут иметь ряд одинаковых характеристик. И вот у меня появился еще такой вопрос:
Если я вдруг захочу добавить в эту базу еще и предметы (таблица items, к примеру). Предметы будут иметь имя, описание и бонус, который дают своему обладателю. Этот бонус - по сути, модификаторы к характеристикам игрока. И вот мой вопрос: в таком случае, характеристики стоит вынести в отдельную таблицу и, где надо, хранить указатель на запись в этой таблице или лучше в каждой таблице, где нужны характеристики, создавать атрибуты str, dex, end, int и т.д.?

@VisualNIK · 29.04.2014, 09:44

Dragon6,

Сообщение от Dragon6

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

Те поля, которые есть у одного но нет у другого можно не заполнять (NULL). По сути явного отличия по схеме не видно; у мобов просто ещё одно поле desc.
критерии характеристики все равно одинаковы будут у всех...зачем их выносить в отдельную таблицу...характеристики принадлежат персонажу и мобу, это не отдельная сущность..

Сообщение от Dragon6

Если я вдруг захочу добавить в эту базу еще и предметы (таблица items, к примеру). Предметы будут иметь имя, описание и бонус, который дают своему обладателю. Этот бонус - по сути, модификаторы к характеристикам игрока. И вот мой вопрос: в таком случае, характеристики стоит вынести в отдельную таблицу

Тут опять же предметы будут принадлежать не характеристикам а какому-то

Сообщение от sKotenok

(кто сейчас присутствует в игре)

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

@Dragon6 · 29.04.2014, 20:21 **[ТС]**

Сообщение от VisualNIK

Тут опять же предметы будут принадлежать не характеристикам а какому-то

Но предметам будут пренадлежать характеристики

@VisualNIK · 30.04.2014, 05:32

Dragon6, ааа...т.е. у предмета тоже будут свои характеристики, отличные от характеристик персонажа? ну опять же, мне кажется, характеристики будут относится к предмету, следовательно должен быть справочник предметов у которого в качестве полей, кроме всего прочего будут эти его характеристики...

Добавлено через 5 минут
Dragon6, понимаете, наборы характеристик принадлежат непосредственно объекту...наименование персонажа - тоже характеристика, но её же вы не выносите отдельно...

Новые блоги и статьи Все статьи Все блоги /
Изучаю kubernetes lagorue 13.01.2026 А пригодятся-ли мне знания kubernetes в России?	Сукцессия микоризы: основная теория в виде двух уравнений. anaschu 11.01.2026 https:/ / rutube. ru/ video/ 7a537f578d808e67a3c6fd818a44a5c4/	WordPad для Windows 11 Jel 10.01.2026 WordPad для Windows 11 — это приложение, которое восстанавливает классический текстовый редактор WordPad в операционной системе Windows 11. После того как Microsoft исключила WordPad из. . .	Classic Notepad for Windows 11 Jel 10.01.2026 Old Classic Notepad for Windows 11 Приложение для Windows 11, позволяющее пользователям вернуть классическую версию текстового редактора «Блокнот» из Windows 10. Программа предоставляет более. . .
Почему дизайн решает? Neotwalker 09.01.2026 В современном мире, где конкуренция за внимание потребителя достигла пика, дизайн становится мощным инструментом для успеха бренда. Это не просто красивый внешний вид продукта или сайта — это. . .	Модель микоризы: классовый агентный подход 3 anaschu 06.01.2026 aa0a7f55b50dd51c5ec569d2d10c54f6/ O1rJuneU_ls https:/ / vkvideo. ru/ video-115721503_456239114	Owen Logic: О недопустимости использования связки «аналоговый ПИД» + RegKZR ФедосеевПавел 06.01.2026 Owen Logic: О недопустимости использования связки «аналоговый ПИД» + RegKZR ВВЕДЕНИЕ Введу сокращения: аналоговый ПИД — ПИД регулятор с управляющим выходом в виде числа в диапазоне от 0% до. . .	Модель микоризы: классовый агентный подход 2 anaschu 06.01.2026 репозиторий https:/ / github. com/ shumilovas/ fungi ветка по-частям. коммит Create переделка под биомассу. txt вход sc, но sm считается внутри мицелия. кстати, обьем тоже должен там считаться. . . .

@Dragon6 5 / 5 / 4 Регистрация: 10.02.2011 Сообщений: 48

	Костыли в базе данных 24.04.2014, 23:50. Показов 1795. Ответов 7 Метки нет (Все метки) Здравствуйте. Проектирую БД для небольшого своего проекта (что-то вроде форумной ролевой игры). У меня есть таблицы: characters - персонажи, их имена, расы, характеристики, races - возможные расы, соединяется с таблицей characters связью один-ко-многим creatures - мобы, их имена, описания, характеристики. Как вы могли заметить, у персонажей и существ есть характеристики, причем они абсолютно идентичны (стандартные сила, ловкость, телосложение, интеллект). Вот я и решил вынести их в отдельную таблицу characteristics. Но тогда столкнулся с следующей "проблемой" - соединять ее с этими таблицами связью один-к-одному (то есть, по первичному ключу) проблематично, а в противном случае получается связь один-ко-многим. То есть, один и тот же персонаж (либо один и тот же моб, либо один из персонажей и один из мобов) имеют один и тот же список характеристик, а значит - изменится у одного, изменится и у другого. Чисто практически, эта проблема, как мне кажется, не очень глобальна, так как такие пересечения довольно легко обойти, но вообще получается костыль... Как мне поступить в таком случае? Объединить характеристики с персонажами и существами, а в случае изменения списка характеристик просто менять их в двух местах? Для большей ясности картины, прикладываю примерную схему БД: Миниатюры 0

@sKotenok 363 / 334 / 38 Регистрация: 29.03.2011 Сообщений: 838
	26.04.2014, 11:51
	Dragon6, создайте таблицу current_characteristics и храните там текущие значения характеристик для каждого перса (моба)!. Вообще - зачем вам 3 отдельные таблицы? characters, creatures, characteristics - можно свести в одну. 0

@sKotenok 363 / 334 / 38 Регистрация: 29.03.2011 Сообщений: 838
	26.04.2014, 19:06
	Dragon6, я не знаю всех глубин логики и как оно у вас устроено, поэтому описываю издалека. - Расы. явно нужны. - Персонажи. Логично, что нужны. Но! Скорее всего нужные 2 таблицы: 1 - справочник (каких персонажей вообще можно создавать). Тут начальные значения характеристик и т.п. (Возможно, что "Расы" - как раз и будет этим справочником, или же там нечто иное) 2 - оперативная (кто сейчас присутствует в игре). При появлении сюда копируется запись, при "умирании", она отсюда удаляется. По сути тут инстансы (обьекты), а в 1й - классы, если сравнить с ООП. - Характеристики - Логично держать в таблице "Персы" чем юзать связь 1-1. - Мобы - Почему бы не закинуть их в таблицу к Персам, добавив поле "Играбелный/бот" - это упростит итоговую структуру до 2х-3х таблиц, с которыми работать можно единообразно. 1

@Dragon6 5 / 5 / 4 Регистрация: 10.02.2011 Сообщений: 48
	27.04.2014, 20:24 [ТС]
	sKotenok, В принципе, я с вами согласен, но насчет мобов, их с персонажами совмещать в одну таблицу, невзирая на то, что их структура немного разная? (то есть, мобы имеют описание desc, которого нет у персонажей и т.д.) И насчет характеристик, я их решил вынести в отдельную таблицу по той причине, что довольно много объектов будут иметь ряд одинаковых характеристик. И вот у меня появился еще такой вопрос: Если я вдруг захочу добавить в эту базу еще и предметы (таблица items, к примеру). Предметы будут иметь имя, описание и бонус, который дают своему обладателю. Этот бонус - по сути, модификаторы к характеристикам игрока. И вот мой вопрос: в таком случае, характеристики стоит вынести в отдельную таблицу и, где надо, хранить указатель на запись в этой таблице или лучше в каждой таблице, где нужны характеристики, создавать атрибуты str, dex, end, int и т.д.? 0

@VisualNIK 8 / 8 / 4 Регистрация: 29.10.2012 Сообщений: 167
	30.04.2014, 05:32
	Сообщение было отмечено Dragon6 как решение Решение Dragon6, ааа...т.е. у предмета тоже будут свои характеристики, отличные от характеристик персонажа? ну опять же, мне кажется, характеристики будут относится к предмету, следовательно должен быть справочник предметов у которого в качестве полей, кроме всего прочего будут эти его характеристики... Добавлено через 5 минут Dragon6, понимаете, наборы характеристик принадлежат непосредственно объекту...наименование персонажа - тоже характеристика, но её же вы не выносите отдельно... 1

Костыли в базе данных

Решение