Микросервисы как выводить общий профиль?

grinat, тоже так думаю. Хлипкая картина будет. Думаю, что все таки пока api лучше. Правильно предлагаете. Подожду ещё комментариев и критики. Если не будет идей, то так и поступлю.

Микросервисы как выводить общий профиль?

grinat, ну как вариант, да. А если все аватарки записывать папку avatars и уже от туда доставать по www.site.ru/avatars/1.jpg

Где 1 = user_id

Хотя тут вопрос с форматом) Если формат один проблем нет. А если png, то проблем чуть больше)

Микросервисы как выводить общий профиль?

grinat, так в цикле будет куча запросов

Микросервисы как выводить общий профиль?

Проблема в отражении участников событии, а именно общего аватара. Как с ним быть? Аватар пока будет единый. Единый аватар будет создаваться в user, но аватар может выводиться во всех сервисах: мероприятия, блог, магазин, отзывы... соотвественно у этих микросервисов будут свои сущности-профили, в которых нужно будет выводить общий аватар. Пример Gavatar. Но им пользоваться не хочу.

Микросервисы как выводить общий профиль?

Я понимаю, что нужно использовать абстракцию между модулями и этим пользуюсь. Для отрисовки использую либо viewModel либо саму сущность. Но дело не в этом.

Как запрашивать данные из user мне понятно. Примерно так же, скорее всего, связывать города.

Это можно делать и без абстракции используя голый SQL запрос который записываем во viewModel. Но речь идёт больше об аватарке. Если посмотреть на яндекс - аватарка там едина во всех сервисах.

Каким образом это осуществить? Предполагаю что нужно сохранять в одно место по id user и доставать во всех сервисах по user_id

Как произвести правильный подсчет в тесте?

macho992, дак в этом и проблема что никто понять ваш код не может. Для этого и говорю, чтобы его отрефакторили. А так если используете дебаг, то смотрите по точкам останова какие-данные где получаются. Если не используете дебаг делайте var_dump(array_key_exists($question->id, $answers)); die(); И так же смотрите какие значения получаются. Если, например, у вас array_key_exists($question->id, $answers) должен вызывать true, а у вас false, то вот она ошибка. И так далее по всем строкам и значениям. Смотрите что передаете и что получаете.

У вас скодом проблемы) Его сложно прочитать даже вам. Где то вы используете хэлпер для получения значения, а где-то просто $answers[$question->id], хотя можно использовать ArrayHelper::getValue()... Пишите код не для машины, а для человека! Код должны читать как английские предложения... Создай мне новый счетчик очков. Проверь существует ли .... Получи мне ID ...

$questionPoint = QuestionPoint::create($param);
if ($questionPoint->isExists($id)) {
      $questionPoint->deleteById($id);
      $questionPoint->....;
}

$questionPoint->getAmount(); //получаем количество для записи в базу.

Если проведете процедуру описанную выше, то сами найдёте ошибку. А так сложно сказать что вам надо и что получается.

Архитектура проекта и таблиц. Как сделать?

Vitsliputsli, да. Согласен. Что-то не подумал....

Yii\web\User как работает access token?

1. Зачем вы присваиваете пустой пароль прямо из контроллера? Может быть в этом проблема?
2. Смотрите ваш Inedfity класс как он вас авторизует. Токене используется в основном для api, сомневаюсь, что он вам вообще нужен. Токен работает так же как и пароль. Генерируется строка каким-то определенным методом. Далее повторяя такой же метод с такими же данными получается токен. Если токен генерируемый = токен а базе - система авторизует вас.

Архитектура таблиц. Как лучше сделать?

d-stream, немного понял.
Школы танцев и школа рисования будет одна и та же таблица. Если данные совсем другие, то придется сделать отдельную таблицу со связью. В связанной таблице указать эти данные. например. ortaganization.art (организация школы рисования и в art таблице дополнительные поля.) Думаю так...

Архитектура проекта и таблиц. Как сделать?

sim3x, понял) спасибо

Архитектура проекта и таблиц. Как сделать?

sim3x, в отдельной таблице будут только те данные которые нужны. То есть если это анкета преподавателя, то ему нужно портфолио. А другим не нужно. Или же общие данные можно хранить в таблице user, а не общие данные выносить в вспомогательные таблицы? Например

user_teachers
- portfolio

Архитектура проекта и таблиц. Как сделать?

Vitsliputsli, с этим я соглашусь. Но это может быть и просто структура проекта. Даже в документации так написано. Скорее всего-то один модуль правильно. Точнее одно приложение. На этом зацикливаться не стоит, думаю.
Что можете сказать по структуре базы? Все ли на ваш взгляд правильно? Предлагают например обьединить таблицу профиля в user.

Архитектура проекта и таблиц. Как сделать?

Vitsliputsli, это модули yii. Они больше для структуры. Потому что полноценный модуль независим. У меня же зависимости и по таблицам и по коду. Только стараюсь реализовать связи через абстракцию.

Архитектура проекта и таблиц. Как сделать?

По password и password_hash ошибка) Хотел другое роле написать

Что убрать понял
. Объединяю профиль и таблицу user. Тоже понятно. Но если таблица будет одна, то не повлечет ли это в проекте много условий в виде if else. Например, что если это танцор, то заполнить ник и так далее?

Может быть это разделить на таблицы и избавиться от этих условий в проекте? Если да, то как лучше разнести? И получается их нужно синхронизировать

Архитектура таблиц. Как лучше сделать?

d-stream, смотрите в общем весь вопрос описал получше....

Всем привет!

Насмотревшись уроки Елисеева Дмитрия, а конкретно по независимым модулям Стал задумываться как все построить?

Раньше задавал подобный вопрос, но так для себя и не понял. Постараюсь развёрнуто задать его снова.

Изначально делил ВСЕ на модули

Модуль USER
Отвечает за авторизацию и хранение основных настроек: авторизация, восстановление пароля, регистрация...

Таблица user
Таблица profile

Модуль DISCIPLINE
Отвечает за хранение данных дисциплин

Модуль ORGANIZATION
Раздел организаций (школы танцев, коллективы, музыкальные школы...) отвечает за хранение информации об организациях, статистика организаций, Контакты, отзывы.

У людей организации может быть несколько ролей: директор, руководитель, тренер, хореограф.... танцоры, певец, спортсмен....

Модуль EVENT
Модуль мероприятий отвечает за работу с мероприятиями и календаря

Мероприятия могут организовывать организаторы и организации.

У мероприятия могут быть люди:
организатор, ведущий, счётчик, волонтёр, охранник

Таблица оргкомитет.

Модуль REGISTRATION
Отвечает за регистрацию участников на мероприятие, ведёт статистику, рейтинг, приём оплаты, подсчёт финансов, выгрузка различных отчетов и списков.

Таблицы:
Наставники: преподаватель, хореограф, тренер... (из модуля организации)
Участники: танцор, спортсмен, певец...(из модуля организации)

У меня получается полная связь между таблицами и модулями. И теперь я думаю как спроектировать базу. Ведь профиль у всех одинаковый, но роли могут быть разные и отличаться несколько полей. При этом мне необходимо искать по всем людям, выводить их друзей, показывать кто онлайн, кто оффлайн, выводить общий рейтинг.

Немного подумав понял, что модулей слишком много. Много относится к одному модулю организации. Поэтому разумнее обьединить часть модулей в модуль организации.

Вот что получается, если объединить по организации:

МОДУЛЬ USER

user
- email
- password
- hash
- vizit_at

people
- id
- user_id
- last_name
- first_name
- middle_name
- birthday
- gender

friend
- from_id
- to_id
- status

message
- from_id
- to_id
- text

МОДУЛЬ ДИСЦИПЛИН

discipline (дисциплины)
- id
- name

МОДУЛЬ ОРГАНИЗАЦИИ

organization
- id
- name
- type (тип организации: Школа танцев, музыкальная школа, спортивная школа....)
- event_count
- people_count

org_rewiew (отзывы)
- id
- people_id (может быть Null)
- text
- active

org_people люди организации)
- org_id
- people_id
- role (директор, танцор, руководитель, тренер, певец спортсмен...)

org_people_director
- id
- people_id
- position (должность)

org_people_dancer
- id
- people_id
- nickname (ник)

- org_people_dancer_mentor (наставники танцора)
- dancer_id (id people)
- mentor_id (id people)
- role (тренер, руководитель, педагог)

/// и так по всем ролям, где нужны дополнительные поля

organization_event (мероприятия организации)
- id
- org_id (Организация)
- name
- date_from
- date_to
- type (фестиваль, мастер-класс, лагерь...)

org_evt_discipline (дисциплины для регистрации)
- event_id
- discipline_id
- active

org_evt_request (заявки)
- id
- event_id
- discipline_id
- reg_number
- cost
- cost_payd
- cost_discount_percent
- cost_dicount_amount
- participant_count
- mentor_count
- contact_email
- contact-phone
- status (ждёт оплаты, оплачено, выполнена, отменена, отменена участником)

org_evt_req_participant (участники, связь заявки и людей)
участниками могут быть все люди без привязки к организации
- request_id
- people_id
- role (танцор, певец, спортсмен)

org_evt_req_mentor (наставники, связь заявки и людей)
Наставниками могут быть все люди
- request_id
- people_id
- role (директор, руководитель, тренер, педагог)

Пример подобного проекта вот: https://godance.tv
Но там нет функционала регистрации.

Архитектура таблиц. Как лучше сделать?

d-stream, через связь employee.user_id => people.user_id это получили профиль. Если нужно контакт, то через таблицу people к people contact. Или опять не правильно мыслю?))

Как реализовать личную переписку на сайте по типу диалогов в ВК?

Могу. А что именно нужно? Там же всё понятно)

Архитектура таблиц. Как лучше сделать?

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

Получается такая структура:

User:
- id
- email
-password

People
- user_id
- last_name
- first_name
- middle_name

People Contact
- people_id
- email
- phone

Далее пошли таблицы модулей:

Модуль организации:

Persone
- id
- user_id
- nickname
....

Employee
- id
- user_id
- должность
...

Все контакты подгружаются у сотрудников и личностей по связям с таблицей People Contact, а аватар и фамилия по связи с People Contact

Архитектура таблиц. Как лучше сделать?

Вот пример https://godance.tv/

Архитектура таблиц. Как лучше сделать?

d-stream, просто не очень хорошо знаю именно правильное построение баз. Можете для тупых на пальцах объяснить?) Просто давно с этим вопросом хожу и никак не могу разобраться как делать... могу даже заплатить за пояснения)

Исходя из ваших слов я понял следующее:

Делать одну общую таблицу профиль, или контрагенты, или люди.

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

В модуле регистрация создаём Таблицы участников и наставников.

В модуле мероприятия создаём таблицу оргкомитет: организатор, ведущий...

В этих таблицах есть поле owner_id с которым связываем профиль (контрагент.), но при этом все поля: ФИО телефон у них свои.

Чтобы эти данные были везде одинаковые - делаем синхронизацию таблиц по полю owner_id. При редактировании ищем по этому id во всех таблицах и обновляем информацию. Этой синхронизацией будет заниматься модуль медиатор.

Правильно я мыслю?

Или же создавать один профиль(контрагент) и ссылаться на него во всех этих модулях и подзавить на независимость модулей))