Форум программистов [Powered by Invision Power Board]

Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > СУБД, общие вопросы > проектирование БД, система заданий

Автор: implements 21.10.2014, 07:24

Доброго времени суток.
Возникла не до понимание как спроектировать БД для заданий с условиями для пользователей.
Суть следующая есть задания для пользователей с определенными условиями которые он должен выполнить, условия могут быть в диапазоне {1..10}, условия разные, при выполнении задания пользователь получает вознаграждения, которые тоже отличаются и могут так-же лежать в диапазоне {1..10}.
Первое, что приходит в голову создать сущьности
1. Задания(id_условия, id_вознаграждения)
2. Условия(id)
3. Вознаграждения
Но как в условия и вознаграждениях прописать разнородные данные, можно конечно создать поля к примеру для 10 условий-10 полей, и проверять уже на стороне приложения бизнес-логики
если пустое поле пропускаем, если нет
если значение поля ==1, то делать то-то
если значение поля ==2, то делать то-то
................................................................

Думаю это бред =), кто-что может подсказать, натолкнуть

P.S. Система похожа на квесты в играх.

Автор: Akina 21.10.2014, 07:51

Цитата(implements @ 21.10.2014, 08:24

)

Первое, что приходит в голову создать сущьности
1. Задания(id_условия, id_вознаграждения)
2. Условия(id)
3. Вознаграждения

4. Пользователи

Цитата(implements @ 21.10.2014, 08:24

)

как в условия и вознаграждениях прописать разнородные данные, можно конечно создать поля к примеру для 10 условий-10 полей, и проверять уже на стороне приложения бизнес-логики
если пустое поле пропускаем, если нет
если значение поля ==1, то делать то-то
если значение поля ==2, то делать то-то

Малопонятная фраза

Автор: implements 21.10.2014, 08:23

Цитата(Akina @ 21.10.2014, 07:51

)

4. Пользователи

Эт само собой =)

Цитата(Akina @ 21.10.2014, 07:51

)

Малопонятная фраза

Смотрите, допустим есть задание с условиями
1. Повысить уровень
2. Напасть куда-то
3. Построить что-то

вознаграждение
1. 100 золота
2. Доступ туда-то

И эти условия и вознаграждения кардинально разные, и мне нужно как-то их различать и хранить

Автор: implements 21.10.2014, 08:41

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

Добавлено через 10 минут и 32 секунды
Мммм даже можно думаю посмотреть в сторону EAV, у каждой сущности свои атрибуты и свои значения

Автор: Akina 21.10.2014, 09:51

Цитата(implements @ 21.10.2014, 09:23

)

допустим есть задание с условиями
1. Повысить уровень
2. Напасть куда-то
3. Построить что-то
вознаграждение
1. 100 золота
2. Доступ туда-то
И эти условия и вознаграждения кардинально разные, и мне нужно как-то их различать и хранить

Нет в них ничего кардинально разного. Есть условие. Есть вознаграждение при выполнении условия. Всё. Остальное - детали, атрибуты задания, которые различаются на стадии логики обработки, и ничем не различаются на стадии хранения.

При формализации задания один из главных моментов - остановиться на правильном уровне детализации.

Автор: implements 21.10.2014, 09:59

Цитата(Akina @ 21.10.2014, 09:51

)

Нет в них ничего кардинально разного.

возможно, но как я буду различать на стадии создания логики в коде, что и куда прибавлять, проверять и т.д.
к примеру
1.собрать 100 палок
2.продать 50 палок
3.купить 10 палок

как я пойму что 1-собрать, 2-продать,3-купить
и таких фишек куча

хотя это уже не к БД вопрос =)
а так да

Цитата(Akina @ 21.10.2014, 09:51

)

остановиться на правильном уровне детализации.

жаль приблизительных примеров нет или диаграмм =)

Автор: Akina 21.10.2014, 11:07

Цитата(implements @ 21.10.2014, 10:59

)

как я буду различать на стадии создания логики в коде

В коде, мать твою, ЧЕГО??? SQL-сервера? ясен пень, нет! значит, в коде клиентского приложения (клиентского по отношению к SQL-серверу, есссно). А клиентское приложение уже должно знать, что задание с кодом 123 - это собрать сотню палок. Оно же должно плюсить палки, и когда их наберётся сто - лезть на сервер с запросом кода действия по выполнению условия.

Автор: implements 21.10.2014, 11:14

Akina, Да, да гдет так, тока гибкости нет =) было 123, через год, по каким либо причинам(даже машинально перепутали при составлении) стало 256, и сиди думай, что не так!!

а так в принципе понятно, буду делать так.

Добавлено через 1 минуту и 2 секунды

Цитата(Akina @ 21.10.2014, 11:07

)

В коде, мать твою, ЧЕГО??? SQL-сервера? ясен пень, нет!

и так понятно было ЧЕГО

Автор: Akina 21.10.2014, 14:44

Цитата(implements @ 21.10.2014, 12:14

)

было 123, через год, по каким либо причинам(даже машинально перепутали при составлении) стало 256, и сиди думай, что не так!!

А для этого умные людит комментарии придумали. Комментарии в коде клиента, поле комментария (если недостаточно наименования и описания) в таблице...
Не говоря уж о документировании, опытной эксплуатации, тестированиях всякческих...

Автор: implements 22.10.2014, 07:34

Цитата(Akina @ 21.10.2014, 14:44

)

А для этого умные людит комментарии придумали.

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

Ну да ладно, Вам Akina, спасибо, а остальное уже холивары начинаются.

Автор: Akina 22.10.2014, 08:15

implements, я думаю, это следствие того, что СУБД не Ваш конёк. Ибо Ваш подход имхо типичен для программиста-процедурщика, редко сталкивающегося с программированием SQL - либо вся логика волочётся на клиента, либо на SQL-сервер хочется вынести то, чему на нём не место.

В частности, фраза

Цитата(implements @ 21.10.2014, 12:14

)

было 123, через год, по каким либо причинам(даже машинально перепутали при составлении) стало 256

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

Автор: implements 22.10.2014, 08:52

Цитата(Akina @ 22.10.2014, 08:15

)

что СУБД не Ваш конёк

Я этого и не отрицаю, будь бы мой конек, вероятность создание этой темы была бы, мизерная.

Цитата(Akina @ 22.10.2014, 08:15

)

программиста-процедурщика

не стоит делать таких выводов, с контекста моего опыта с SQL

Цитата(Akina @ 22.10.2014, 08:15

)

согласен полностью, если это дело будет контролировать сама СУБД, но можно навредить к примеру ручками поменять запись, но это уже ответственность разработчика

Банально будет 1000+ заданий, не важно чего, и это надо поддерживать на стороне клиента, всегда помнить, что id=983, это значит "сделать то-то", пусть даже будут комментарии, все равно сложновато будет, ветвление проверок и т.д(что в принципе можно решить грамотным проектированием классов). Вообщем возможно другого подхода нет, буду дерзать этот.

P.S. Akina, просьба не ставить себя выше других и делать выводы по одной теме, все в чем-то сильны в чем-то слабы.

Автор: Akina 22.10.2014, 15:31

Цитата(implements @ 22.10.2014, 09:52

)

все в чем-то сильны в чем-то слабы.

Вот уж с чем не приходит в голову спорить.

Цитата(implements @ 22.10.2014, 09:52

)

Банально будет 1000+ заданий, не важно чего, и это надо поддерживать на стороне клиента, всегда помнить, что id=983, это значит "сделать то-то", пусть даже будут комментарии, все равно сложновато будет, ветвление проверок и т.д

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

Цитата(implements @ 22.10.2014, 09:52

)

можно навредить к примеру ручками поменять запись, но это уже ответственность разработчика

Ну это не программная проблема, а административная.
К тому же мне лично крайне сложно придумать причину, по которой разработчик будет менять уникальный автоинкремент/ГУИД индекс записи. Который, по большому счёту, ему и видеть не положено, ибо синтетический ключ предназначен исключительно для работы подсистемы контроля целостности и непротиворечивости данных сервера БД. А у пользователя прав на просмотр, не говоря уж об изменении, этого поля не должно быть даже теоретически.