@android_ru - страница 2775

Сергій

😁

Sergey

Типа висит сервис который шлет постом текст твоей смски на сайт

Sergey

А у тебя нет нихрена

Sergey

И типа управляешь смсками через сайт

Sergey

незнаю зачем оно

Sergey

Осталось тупо удалить входящую смску

Никита 🙃

та не троян это, просто штука для управления смсками онлайн

Но опубликовать в google play не сможешь)

Sergey

То уже не мои проблемы

Sergey

Denis

всем привет! На проект надо добавить room. Должно быть две таблицы: Тренеры, Пользователи. Поля в них полностью идентичны. Вопрос: как будет лучше, сделать базовый класс Entity и наследовать от него эти классы? Или сделать класс пользователя и наследовать его в классе тренера?

Александр

Так, будет класс Пользователь, у которого разные роли? Такой смысл?

Denis

Есть тренеры и есть пользователи(те кто тренируются)

Denis

по сути да

Denis

роли разные

Denis

но все свойства одинаковые

Denis

Просто я боюсь, что если сделаю базовый класс Entity, у меня в бд будет 3 сущности вместо 2

Evgeniy

Тебе же советуют, делай один класс, у которого будет поле роль - тренер или пользователь. Зачем два класса, если они одинаковые?

Martynenko

всем привет! На проект надо добавить room. Должно быть две таблицы: Тренеры, Пользователи. Поля в них полностью идентичны. Вопрос: как будет лучше, сделать базовый класс Entity и наследовать от него эти классы? Или сделать класс пользователя и наследовать его в классе тренера?

enum RoleApp рассматривал?

Denis

проблема в том, что в приложении логика построена на сущностях тренера и пользователя

Denis

и там придется переписывать большой слой

Denis

но, наверное, это единственное правильное решенеи

Denis

решение*

Denis

спасибо за помощь

Martynenko

проблема в том, что в приложении логика построена на сущностях тренера и пользователя

это конечно зло так делать, но создай какой-то левый апп, там сделай наследование и пометь как Entity дочерние сущности) должно сработать)

Denis

я думал об этом, но правильно ли так делать?)

Denis

и кст возникла еще проблема

Denis

у тренера должн быть связь с польователями

Denis

если делать через роли

Denis

то получается не очень удобно

Martynenko

у тренера должн быть связь с польователями

рекурсивная связь 1 ко многим в рамках одной таблицы)

Eugene

у тренера должн быть связь с польователями

Ну пользователь же у конкретного тренера тренируется? Значит таблица один ко многим "У тренера есть пользователи"

Denis

слишком много функций на одну сущность)

Denis

Ну пользователь же у конкретного тренера тренируется? Значит таблица один ко многим "У тренера есть пользователи"

да

Denis

я имел в виду, что через роли нормально это не реализовать

Denis

какая там связь я знаю

Eugene

да

С точки зрения стандартной архитектуры это будет таблицам CoachHasUsers где будут поля coach_id, user_id. Комбинация двух полей внешний ключ. При чем здесь роли, если мы связываем сущности

Denis

мне просто выше советовали сделать одну сущность, у которой просто будут разные роли

Denis

мы про это и вели бесседу

Eugene

мне просто выше советовали сделать одну сущность, у которой просто будут разные роли

Ааа) Ну допустим, хотя я не уверен, что так нужно) Но это не отменяет возможности реализовать это через такую таблицу

Eugene

Связь же через id просто

Denis

это конечно зло так делать, но создай какой-то левый апп, там сделай наследование и пометь как Entity дочерние сущности) должно сработать)

а что насчет такого варианта? Так вообще правильно делать?

Denis

создавать базовый класс

Denis

не сущность

Denis

и наследовать от него два класса

Denis

которые будут сущностями

Martynenko

а что насчет такого варианта? Так вообще правильно делать?

я не пробовал, но может сработать)

Denis

проблема, что сроки ограничены)

Denis

но мб попробовать стоит

Eugene

а что насчет такого варианта? Так вообще правильно делать?

С точки зрения ооп все норм. А вот в бд все равно должна быть просто таблица сущности и таблица связи

Denis

С точки зрения ооп все норм. А вот в бд все равно должна быть просто таблица сущности и таблица связи

Только сейчас допер, что ты имеешь в виду

Denis

и мне нравится это решение

Denis

я так уже делал на одном проекте

Martynenko

С точки зрения ооп все норм. А вот в бд все равно должна быть просто таблица сущности и таблица связи

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

Eugene

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

Если с room? Да, но там тогда лучше создать сущности тренер и юзер отдельно и над юзером накинуть аннотацию связи в третью сущность, например CoachWithUsers

Eugene

Могу пример скинуть

Denis

смотри я делал так: Есть стаблица A и таблица B. А таблица C содержить только A_id и B_id

Denis

если я не ошибаюсь, то это называется ассоциативной таблицей

Denis

ты это имеешь в виду?

Eugene

смотри я делал так: Есть стаблица A и таблица B. А таблица C содержить только A_id и B_id

Это самый чистый и самый правильный вариант

Denis

спасибо, не знаю, как сам не вспомнил, что так делал)

Eugene

ты это имеешь в виду?

Ты из таблицы C получаешь все B_id, которые связаны с A_id, а потом достанешь сущности из таблицы B их

Denis

ну это я знаю) Просто почему-то не вспомнил, что так уже делал) Спасибо большое за помощь!

Eugene

ну это я знаю) Просто почему-то не вспомнил, что так уже делал) Спасибо большое за помощь!

Ну главное, что в итоге пришли к правильному решению) Пожалуйста;)

Dmitry

господа socket-io кто юзал? как вам?

Sergey

С точки зрения стандартной архитектуры это будет таблицам CoachHasUsers где будут поля coach_id, user_id. Комбинация двух полей внешний ключ. При чем здесь роли, если мы связываем сущности

Но только это многие-ко-многим, а не один-ко-многим. Надо ограничение на уникальность юзера добавлять, что бы он к нескольким тренерам не подвязался.

Chris Matt

Это приложение анимировано с помощью canvas? Или вы создали анимацию вида? Я хочу сделать это так же. https://play.google.com/store/apps/details?id=kr.com.hcb.gotcha

Sergey

ну это я знаю) Просто почему-то не вспомнил, что так уже делал) Спасибо большое за помощь!

https://t.me/android_ru/494117

Alexandr

Это приложение анимировано с помощью canvas? Или вы создали анимацию вида? Я хочу сделать это так же. https://play.google.com/store/apps/details?id=kr.com.hcb.gotcha

libgdx?

Eugene

Но только это многие-ко-многим, а не один-ко-многим. Надо ограничение на уникальность юзера добавлять, что бы он к нескольким тренерам не подвязался.

Один тренер ко многим пользователям. При чем здесь многие ко многим?

Chris Matt

Я думаю, что это сделано с Android

Eugene

Но только это многие-ко-многим, а не один-ко-многим. Надо ограничение на уникальность юзера добавлять, что бы он к нескольким тренерам не подвязался.

У одного юзера не может быть много тренеров, в обратную сторону это не должно работать

Martynenko

У одного юзера не может быть много тренеров, в обратную сторону это не должно работать

разве?) я думаю будет)

Eugene

разве?) я думаю будет)

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

Martynenko

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

ну по умолчанию такое решение имеент отношение многие ко многим) так как физически через таблицу посредника работает)

Chris Matt

Мне так грустно.

Eugene

ну по умолчанию такое решение имеент отношение многие ко многим) так как физически через таблицу посредника работает)

Да, верно, перечитал статью

Martynenko

Да, верно, перечитал статью

я с универа хорошо запомнил проектирование БД)

Eugene