Глава 3: Я был в аду…

Здравствуй, дорогой читатель! Надеюсь, у вас все хорошо, а у меня нет. Я знал, что это произойдет, это первое веб-приложение, которое я создаю в одиночку, так что это должно было случиться. Я думал об изменении идеи приложения, об изменении технологического стека, который я буду использовать. От мыслей об использовании бэкенда до «стоит ли мне использовать AWS Amplify вместо этого?». Я побывал в самых разных местах, но, наконец, довел дело до конца.

UPDATE Я не буду придерживаться Ionic, или, по крайней мере, я думаю, что не буду. Почему? Он не полезен. Я имею в виду, что это действительно хороший фреймворк, но мне все еще не очень удобно с ним работать. Я думал о том, чтобы изучить его. Я даже делал это последние 4-5 дней. Но, опять же, это мне не помогло. Так что, я буду придерживаться базового react с шаблоном Typescript с этого момента. Если я почувствую, что могу сделать из этого приложение, я снова напишу все это на react native. Вот и все. Я сделал одно классное приложение с Ionic, оно действительно классное, но мне потребуется не меньше недели, чтобы стать действительно хорошим в этом. Я НЕ МОГУ ЖДАТЬ ТАК ДОЛГО.

Да, о базовых схемах. Вот они.

Теперь вы, возможно, думаете: «Если ни один из них не является окончательным, то что толку?». Ну, дорогой читатель, все работают по-разному. Я тупой как черт. Поэтому, просто увидев базовые схемы, я могу привести свои мысли в порядок.

Дорожные препятствия, с которыми я столкнулся
-> Ад базы данных.

  1. Каждый конкретный дом (BLOCK) может иметь много пользователей (USER) (семейные соображения) ( BLOCK -> one-to-many -> USER )
  2. Каждый дом (BLOCK) может иметь много билетов. (BLOCK -> one-to-many -> USER)
  3. Каждый билет должен быть виден соответствующему администратору. (ADMIN -> one-to-many -> TICKET)
  4. Кроме того, каждый пользователь может иметь много билетов. (USER -> one-to-many -> TICKET)
  5. Каждый администратор может иметь много пользователей (ADMIN -> one-to-many -> USER).

СОБЫТИЙНАЯ СТОРОНА ВОПРОСА

  1. каждый пользователь может организовать множество мероприятий, и в каждом мероприятии будет участвовать множество пользователей (USER -> many-to-many -> EVENT).
  2. Теперь, если место проведения мероприятия похоже на дом пользователя, это не имеет значения. Фильтр событий не нужен.
  3. Но если пользователь хочет организовать мероприятие в общественном месте, то ему потребуется разрешение администратора, поэтому, при необходимости, за мероприятие будет отвечать один конкретный администратор (ADMIN -> one-to-many -> EVENT).

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

Вот мысленный эксперимент, как пользователь узнает, что администратор начал действовать по его/ее тикету или жалобе. Итак, я должен как-то связать действия администратора с пользователем, чтобы пользователь мог получать информацию поэтапно, например, ACKNOWLEDGED означает, что ваш тикет рассматривается администратором. IN PROGRESS означает, что кто-то занимается решением вашего вопроса. CLOSED, означает, что ваш вопрос решен. Теперь, прежде чем закрыть проблему, администратор должен узнать у пользователя, решена ли его проблема, или есть ли какие-либо предложения, администратор не может закрыть тикет без разрешения пользователя. Итак, кодировать это хорошо, но как создать из этого отношение к базе данных? Я все еще бьюсь головой над этим вопросом. Скрестим пальцы, надеюсь, я найду его,
Вот диаграмма, которую я смог придумать. Она неправильная, мне все еще нужно наметить несколько отношений, но вот она.

Если у кого-нибудь есть предложения или кто может помочь с figma, свяжитесь со мной. Я все еще работаю над многими вещами, так что многое может измениться, я могу использовать mongo DB, вместо postgres, который я планировал. Посмотрим. Пока. Также пожелайте этому тупому парню удачи, чтобы он действительно справился со всем этим. Пока.

Оцените статью
Procodings.ru
Добавить комментарий