 |
|
Модераторы: LSD |
 
|
|
проектирование БД, система заданий, задания, условия, поощрения 
| implements |
|
|||
|
Бывалый  Профиль Группа: Участник Сообщений: 210 Регистрация: 20.7.2010 Репутация: нет Всего: нет |
Доброго времени суток.
Возникла не до понимание как спроектировать БД для заданий с условиями для пользователей. Суть следующая есть задания для пользователей с определенными условиями которые он должен выполнить, условия могут быть в диапазоне {1..10}, условия разные, при выполнении задания пользователь получает вознаграждения, которые тоже отличаются и могут так-же лежать в диапазоне {1..10}. Первое, что приходит в голову создать сущьности 1. Задания(id_условия, id_вознаграждения) 2. Условия(id) 3. Вознаграждения Но как в условия и вознаграждениях прописать разнородные данные, можно конечно создать поля к примеру для 10 условий-10 полей, и проверять уже на стороне приложения бизнес-логики если пустое поле пропускаем, если нет если значение поля ==1, то делать то-то если значение поля ==2, то делать то-то ................................................................ Думаю это бред =), кто-что может подсказать, натолкнуть P.S. Система похожа на квесты в играх. Это сообщение отредактировал(а) implements - 21.10.2014, 07:26 |
|||
|
||||
Загрузка ...
| Akina |
|
||||
|
Советчик Профиль Группа: Модератор Сообщений: 20581 Регистрация: 8.4.2004 Где: Зеленоград Репутация: 13 Всего: 454 |
4. Пользователи
Малопонятная фраза -------------------- О(б)суждение моих действий - в соответствующей теме, пожалуйста. Или в РМ. И высшая инстанция - Администрация форума. |
||||
|
|||||
| implements |
|
||||
|
Бывалый Профиль Группа: Участник Сообщений: 210 Регистрация: 20.7.2010 Репутация: нет Всего: нет |
Эт само собой =)
Смотрите, допустим есть задание с условиями 1. Повысить уровень 2. Напасть куда-то 3. Построить что-то вознаграждение 1. 100 золота 2. Доступ туда-то И эти условия и вознаграждения кардинально разные, и мне нужно как-то их различать и хранить |
||||
|
|||||
| implements |
|
|||
|
Бывалый Профиль Группа: Участник Сообщений: 210 Регистрация: 20.7.2010 Репутация: нет Всего: нет |
можно продумать и прописать все возможные условия в отдельную таблицу и уже связать с заданием, а на стороне приложения-сервера, сделать прослойку для работы этих условий(проверку, и что сделать).
тогда при добавлении нового условия нужно и прослойку обновлять. Добавлено через 10 минут и 32 секунды Мммм даже можно думаю посмотреть в сторону EAV, у каждой сущности свои атрибуты и свои значения Это сообщение отредактировал(а) implements - 21.10.2014, 08:42 |
|||
|
||||
| Akina |
|
|||
|
Советчик Профиль Группа: Модератор Сообщений: 20581 Регистрация: 8.4.2004 Где: Зеленоград Репутация: 13 Всего: 454 |
Нет в них ничего кардинально разного. Есть условие. Есть вознаграждение при выполнении условия. Всё. Остальное - детали, атрибуты задания, которые различаются на стадии логики обработки, и ничем не различаются на стадии хранения. При формализации задания один из главных моментов - остановиться на правильном уровне детализации. -------------------- О(б)суждение моих действий - в соответствующей теме, пожалуйста. Или в РМ. И высшая инстанция - Администрация форума. |
|||
|
||||
| implements |
|
||||
|
Бывалый Профиль Группа: Участник Сообщений: 210 Регистрация: 20.7.2010 Репутация: нет Всего: нет |
возможно, но как я буду различать на стадии создания логики в коде, что и куда прибавлять, проверять и т.д. к примеру 1.собрать 100 палок 2.продать 50 палок 3.купить 10 палок как я пойму что 1-собрать, 2-продать,3-купить и таких фишек куча хотя это уже не к БД вопрос =) а так да
жаль приблизительных примеров нет или диаграмм =) |
||||
|
|||||
| Akina |
|
|||
|
Советчик Профиль Группа: Модератор Сообщений: 20581 Регистрация: 8.4.2004 Где: Зеленоград Репутация: 13 Всего: 454 |
В коде, мать твою, ЧЕГО??? SQL-сервера? ясен пень, нет! значит, в коде клиентского приложения (клиентского по отношению к SQL-серверу, есссно). А клиентское приложение уже должно знать, что задание с кодом 123 - это собрать сотню палок. Оно же должно плюсить палки, и когда их наберётся сто - лезть на сервер с запросом кода действия по выполнению условия. -------------------- О(б)суждение моих действий - в соответствующей теме, пожалуйста. Или в РМ. И высшая инстанция - Администрация форума. |
|||
|
||||
| implements |
|
|||
|
Бывалый Профиль Группа: Участник Сообщений: 210 Регистрация: 20.7.2010 Репутация: нет Всего: нет |
Akina, Да, да гдет так, тока гибкости нет =) было 123, через год, по каким либо причинам(даже машинально перепутали при составлении) стало 256, и сиди думай, что не так!!
а так в принципе понятно, буду делать так. Добавлено через 1 минуту и 2 секунды
и так понятно было ЧЕГО |
|||
|
||||
| Akina |
|
|||
|
Советчик Профиль Группа: Модератор Сообщений: 20581 Регистрация: 8.4.2004 Где: Зеленоград Репутация: 13 Всего: 454 |
А для этого умные людит комментарии придумали. Комментарии в коде клиента, поле комментария (если недостаточно наименования и описания) в таблице... Не говоря уж о документировании, опытной эксплуатации, тестированиях всякческих... -------------------- О(б)суждение моих действий - в соответствующей теме, пожалуйста. Или в РМ. И высшая инстанция - Администрация форума. |
|||
|
||||
| implements |
|
|||
|
Бывалый Профиль Группа: Участник Сообщений: 210 Регистрация: 20.7.2010 Репутация: нет Всего: нет |
у меня мнение другое, да документация должна быть, комментарии и т.д., но все равно, код должен быть "прозрачным" и понятным, чтобы не терять кучу времени на чтение комментариев, и думать, "да блин, что-же там происходит". Ну да ладно, Вам Akina, спасибо, а остальное уже холивары начинаются. |
|||
|
||||
| Akina |
|
|||
|
Советчик Профиль Группа: Модератор Сообщений: 20581 Регистрация: 8.4.2004 Где: Зеленоград Репутация: 13 Всего: 454 |
implements, я думаю, это следствие того, что СУБД не Ваш конёк. Ибо Ваш подход имхо типичен для программиста-процедурщика, редко сталкивающегося с программированием SQL - либо вся логика волочётся на клиента, либо на SQL-сервер хочется вынести то, чему на нём не место.
В частности, фраза
свидетельствует о незнании простого факта - уникальный индекс записи неизменен в течение всего срока жизни базы данных. Даже если запись с этим значением уникального индекса удалена. -------------------- О(б)суждение моих действий - в соответствующей теме, пожалуйста. Или в РМ. И высшая инстанция - Администрация форума. |
|||
|
||||
| implements |
|
||||||
|
Бывалый Профиль Группа: Участник Сообщений: 210 Регистрация: 20.7.2010 Репутация: нет Всего: нет |
Я этого и не отрицаю, будь бы мой конек, вероятность создание этой темы была бы, мизерная.
не стоит делать таких выводов, с контекста моего опыта с SQL
согласен полностью, если это дело будет контролировать сама СУБД, но можно навредить к примеру ручками поменять запись, но это уже ответственность разработчика Банально будет 1000+ заданий, не важно чего, и это надо поддерживать на стороне клиента, всегда помнить, что id=983, это значит "сделать то-то", пусть даже будут комментарии, все равно сложновато будет, ветвление проверок и т.д(что в принципе можно решить грамотным проектированием классов). Вообщем возможно другого подхода нет, буду дерзать этот. P.S. Akina, просьба не ставить себя выше других и делать выводы по одной теме, все в чем-то сильны в чем-то слабы. Это сообщение отредактировал(а) implements - 22.10.2014, 08:54 |
||||||
|
|||||||
| Akina |
|
||||||
|
Советчик Профиль Группа: Модератор Сообщений: 20581 Регистрация: 8.4.2004 Где: Зеленоград Репутация: 13 Всего: 454 |
Вот уж с чем не приходит в голову спорить.
В реальности именно так и строятся системы. Массив ссылок на функции, каждая из которых обрабатывает своё событие (задание), и вызов выбором адреса по индексу. От нумерованного списка этих заданий всё одно не уйти. И помнить (а скорее хранить в документации) по-любому придётся.
Ну это не программная проблема, а административная. К тому же мне лично крайне сложно придумать причину, по которой разработчик будет менять уникальный автоинкремент/ГУИД индекс записи. Который, по большому счёту, ему и видеть не положено, ибо синтетический ключ предназначен исключительно для работы подсистемы контроля целостности и непротиворечивости данных сервера БД. А у пользователя прав на просмотр, не говоря уж об изменении, этого поля не должно быть даже теоретически. -------------------- О(б)суждение моих действий - в соответствующей теме, пожалуйста. Или в РМ. И высшая инстанция - Администрация форума. |
||||||
|
|||||||
|
|
| Правила форума "Общие вопросы по базам данных" | |
|
|
Данный форум предназначен для обсуждения вопросов о базах данных не попадающих под тематику других форумов:
Данный форум не предназначен для:
Если вы не соблюдаете эти правила, не удивляйтесь потом не найдя свою тему/сообщение.
Полезные советы: Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, LSD, Zloxa. |
| 0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей) | |
| 0 Пользователей: | |
| « Предыдущая тема | СУБД, общие вопросы | Следующая тема » |
[ Время генерации скрипта: 0.0887 ] [ Использовано запросов: 22 ] [ GZIP включён ]
Реклама на сайте Информационное спонсорство
|
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |