Привет. Есть модуль событий. Задача модуля заключается в том, чтобы публиковать события, создавать регистрацию (принимать заявки). По типу яндекс афиша. Типы мероприятий: соревнование, мастер-класс, батлы, курсы и т д. Каждый тип может иметь отличительные данные. Например, на мастеркласс требуется лектор. Каждое событие может проходить в несколько периодов: разово или в определенные даты 21 марта и 1 апреля, 5 декабря и тд.
Например, есть событие Олимпиада искусств, у неё своя афиша и другие данные. В рамках которой проходит: фестиваль любителей, мастер-класс по актерскому мастерству «Грация», и курсы для преподавателей «стимул».
Все эти типы имеют свою систему регистрации. Все типы обьединяются под одним общим событием Олимпиада искусств. Но столько подтипов бывает не всегда.
Как мне лучше обьединить и выводить все типы в одном событии?
Предполагаю, что надо будет создать событие. Затем к этому событию создать типы: фестиваль, курс, мастер-класс. Правильно ли я мыслю? Как бы поступили вы? как лучше сделать?
Узел - имеет свой тип и содержит свои свойства в зависимости от выбранного типа.
Узлы имеют связи.
Для контроля узлов всего графа - создаётся событийный обсервер.
Он следит за корректностью статусов и целостности связанных/зависимых событий.
Также, он ведёт исторический лог смены статусов: открыто/завершено, и другие показатели мероприятий.
Любые другие объекты просто имеют связи по идентификатору с нужным узлом в "дереве" мероприятий (например, лектор).
xmoonlight, Узел графа - объект, который связан или соединен с одним или несколькими другими объектами, как я понимаю. Если вы об этом. Если говорить честно, то я никогда не сталкивался с таким толкованием, поэтому и потерялся)
Что касается ника - это не показатель уровня познаний. Выбрал этот Ник, так как мой стандартный был занят. А этот был свободен.
Узел - имеет свой тип и содержит свои свойства в зависимости от выбранного типа.
Исходя из этого создаём объект События, со своим типом. У него есть разные фабричные методы или фабрики как это объект создаётся в зависимости от типа мероприятия. Каждый тип имеет свои свойства, которые ему нужны. Но объединено это все в одном объекте. Так? Или что-то не то понял? Просто вы ещё говорили про события и синхронизацию данных. Тут я совсем не понял. В общем я что-то запутался)
Может быть есть какие-то примеры? Чтобы не на словах, а на коде понять?)) Спасибо за помощь!
xmoonlight, кстати. У меня такая же проблема с персонами этих всех мероприятий. Есть: участники, организаторы, лекторы, наставники и т д. С одной стороны их можно всех обьединить в одно - персоны. Но с д другой стороны у них могут быть/или не быть какие-либо данные. Например, у участника может быть закреплённый наставник. А у остальных наставников быть не может.
С этим я тоже застрял. Проблема прохожая. И решение тоже, думаю.
xmoonlight, просто я выше писал примерно такой вариант:
Мероприятия
Событие
Id
Name
Despription
Status
Periods //Периоды дат, к которым привязаны все типы. Например, Фестиваль проходит с 10-12-2020 по 11-12-2020 и с 20-12-2020 по 21-12-2020
Соревнование
Id
PeriodId
Name
Status
OrganizerId
OrganizationId
Plases //Площадки 1 или больш
Регистрация
//Система регистрации
Счёт
//Система счёта
Мастер-класс
id
PeriodId
Name
MentorId
Status
OrganizerId
OrganizationId
IsCertification
Prices
Регистрация
//Система регистрации
Счёт
//Система счёта
Батлы
id
PeriodId
Name
Status
OrganizerId
OrganizationId
Nominations
Juges
Регистрация
//Система регистрации
Счёт
//Система счёта
Связь по UUID (id)
Но вы почему-то стали говорить как я понимаю узел) Вот я и подумал, что не то. И говорю вам, что так не делал. Поэтому, я скорее всего не имею такого опыта или понимания) С узлами в терминологии не приходилось встречаться....
Dmitry, поясняю.
У Вас сейчас однотипные объекты со слегка различающимися полями.
При этом, пока нет никакой вложенности этих однотипных объектов друг в друга.
Также, у Вас есть общие поля у этих объектов, которые дублируют своё назначение.
Задача: из всего этого сделать ОДИН объект, который будет унифицированным по отношению к любому из указанных. Это и будет "узел".
xmoonlight, понятно) то есть плодить много сущностей по разному типу не требуется? Но такой объект будет со временем увеличиваться в размерах. Разные поля будут использоваться в зависимости от типа мероприятия. А если мне потребуется много свойств в таком объекте? Объект будет иметь несколько тысяч строк. Разбираться в таком объекте будет сложно.
К тому же есть такой факт, что 1 событие может иметь несколько других событий. В главном событии сводится вся статистика и управление.
Dmitry, неверно!
Объект узла имеет свойства и связи И только тогда, когда это необходимо.
Каждое свойство такого узла - это связь на отдельную сущность - на нужную таблицу. Например, NameId ссылается на таблицу имён. И по т.п. задаются все остальные необходимые свойства для узла.
Связи между самими узлами позволяют строить любое "дерево" (граф/иерархию и т.п.).
Пример одного мероприятия с конкурсом и банкетом:
-----
Мероприятие1 -> Конкурс -> Награждение
Мероприятие1 -> Банкет
-----
И т.д.
Кто этим управляет и следит - написано в моём ответе.
xmoonlight, чуть чуть начинаю понимать вашу мысль. Но все равно познания и опыта в этом нет. Есть ли где-то пример посмотреть это на коде? Был бы очень благодарен. Не обязательно, конечно пример такой же как у меня. Разберусь и с другим. Просто никогда так не делал или делал, но не понимаю.
Про паттерн наблюдателя понятно в целом. Проблема именно в понимании граф узла на коде. Почитал статьи на эту тему. Но больше понимаю через код)
xmoonlight, Мне писать код не нужно) Сам с телефона и понимаю Вас) С этой темой не знаком от слова вообще. Поэтому я и не понял ваш ответ) Мне главное понять суть, а дальше я накопаю. Наверняка есть какие-то видео разборы на примере кода. Наверняка у вас есть подобное в личной базе знаний. Буду рад если поделитесь этими ссылками. Потому что я прочитал статьи на хабре про узлы, но это не совсем понятно. И пример там был математический. Он далёк от моей.
xmoonlight, что касается станет ли это отправкой к познанию деревьев, то тут просто. Знаком C nested sets. Если мне поможет в решении данная тема и так оно действительно должно быть, то это точно, что я её буду изучать. Так как над подобной задачей уже мучаюсь около трёх месяцев. Как сделать просто и быстро знаю, но хочется сделать правильно и хорошо. И если ещё узнаю что-то новое - будет плюс в двойне. Пишу на symfony и доктрина.
Наверняка у вас есть подобное в личной базе знаний.
у меня нет ничего в БЗ по архитектурам. Только сниппеты личного кода по частым типовым задачам.
Вот тут можно почитать про то, что такое дерево/граф.
Кратко, на интернете: компы/сервера/мобилы - это листья, роутеры/свитчи/файрволлы - это узлы, провода - рёбра, а всё в совокупности - это тип графа: дерево.
Dmitry, абстрагируйтесь от изначальной зависимости всех объектов: "рассыпьте их".
И то, что их будет собирать в единую заданную сущность - и будет узлом.
А то, от чего этот узел будет зависеть - будет ещё одним подобным узлом, но уже "родителем" по отношению к нему.
Все связи между узлами (и задание свойств узла) - это только таблицы связей идентификаторов в узлах. Это будут рёбра.
xmoonlight, да примерно понимаю) просто я привык мыслить агрегатами, сущностями, свойствами, а тут что-то новое))) Разберусь, думаю) Надо завтра нашу лекцию с утра почитать на свежую голову и дойдёт)
xmoonlight, поизучай я деревья)) Да, тема обширная. Капец как сложно))) Смотрел вот этот вебинар Но я все равно не понял как это можно применить к моему случаю.
Dmitry, не смотри веббинары никакие! Это только сбивает с верного понимания относительно твоей задачи.
Википедия, твоя задача, бумага, карандаш - это всё, что требуется.
Ах-да... Чуть не забыл: МОЗГ! ;)
xmoonlight, ахах. Блин)) Я реально голову сломал уже. Примеров таких подобных нет. Прогуглил. Вебинар хороший. Толковый парень. Но я не понял как это применить ко мне. В других задачах понимаю. А тут нет. С Википедии тоже не особо понял. Мозги вроде есть, но как будто нет
Простой
