Цитата:
Сообщение от Tails
Что и откуда тянуть - знает обрабатывающий код/функция, выполняющая какое-то действие. Если это надевание предмета, она запросит данные этого предмета по его id, запросит данные экипируемого слота. Проверит что-то и либо выполнит действие, либо отвалится с сообщением об ошибке. (Такого предмета не существует, был передан не экипируемый предмет, слот уже экипирован, или такого слота не существует) То-есть, в саму субд я не закладываю такого функционала, что-бы она сама подтягивала дополнительные данные из других таблиц. У меня таблица - это просто список записей, которые можно запросить по id или пройтись по всему списку целиком.
|
Действительно здорово! Спасибо большое. Загорелся я твоим подходом, теперь активно думаю, как совместить его с наследуемой архитектурой классов Item внутри программы. Я с позволения ещё несколько вопросов задам, до сих пор не всё на 100% понятно.
1. Я правильно понимаю, что если предмет должен "жить своей жизнью" внутри программы, то "чистый" реляционный подход уже не сработает? Например, если каждое использование аптечки снижает её ресурс на 20%, то остаток по-любому придётся хранить в самом экземпляре. В таком раскладе использовать внутри программы одни только ID точно не выйдет. Верно? Как такие вопросы ты решаешь?
2. Рассматриваю вариант, как мне скрестить ежа и ужа (реляционную модель хранения статических данных с наследуемой ООП-архитектурой внутри программы). Что если указывать прямо в таблице имя присваиваемого предмету класса, чтобы в момент создания вытягивать его по ID и присваивать через getDefinitionByName? А дальше при заполнении свойств проверять на наличие такого свойства у данного класса. Если есть - заполняем, если нет - не заполняем (и выдаём предупреждение).
3. В качестве альтернативы вижу ещё один подход. ВСЕ свойства прописать в классе Item, тем самым решив раз и навсегда проблему наличия/отсутствия свойств, а наследников оставить как маркеры.
Насколько такие "гибридные" подходы применимы и в чём, по твоему мнению, их главные минусы? Плюсы и так понятны. Спасибо.
Добавлено через 27 минут
...ещё забыл, хотел уточнить.\
4. Скажи, пожалуйста, я правильно понимаю, что если нет комплексной СУБД, "знающей", что откуда нужно подтягивать, то получается, что для каждой таблицы нам придётся делать свой персональный класс-парсер, который как раз и будет "знать", что и как мы из неё вытаскиваем?