Здравствуй, дорогой читатель! Надеюсь, у вас все хорошо, а у меня нет. Я знал, что это произойдет, это первое веб-приложение, которое я создаю в одиночку, так что это должно было случиться. Я думал об изменении идеи приложения, об изменении технологического стека, который я буду использовать. От мыслей об использовании бэкенда до “стоит ли мне использовать AWS Amplify вместо этого?”. Я побывал в самых разных местах, но, наконец, довел дело до конца.
UPDATE Я не буду придерживаться Ionic, или, по крайней мере, я думаю, что не буду. Почему? Он не полезен. Я имею в виду, что это действительно хороший фреймворк, но мне все еще не очень удобно с ним работать. Я думал о том, чтобы изучить его. Я даже делал это последние 4-5 дней. Но, опять же, это мне не помогло. Так что, я буду придерживаться базового react с шаблоном Typescript с этого момента. Если я почувствую, что могу сделать из этого приложение, я снова напишу все это на react native. Вот и все. Я сделал одно классное приложение с Ionic, оно действительно классное, но мне потребуется не меньше недели, чтобы стать действительно хорошим в этом. Я НЕ МОГУ ЖДАТЬ ТАК ДОЛГО.
Да, о базовых схемах. Вот они.
Теперь вы, возможно, думаете: “Если ни один из них не является окончательным, то что толку?”. Ну, дорогой читатель, все работают по-разному. Я тупой как черт. Поэтому, просто увидев базовые схемы, я могу привести свои мысли в порядок.
Дорожные препятствия, с которыми я столкнулся
-> Ад базы данных.
- Каждый конкретный дом (BLOCK) может иметь много пользователей (USER) (семейные соображения) ( BLOCK -> one-to-many -> USER )
- Каждый дом (BLOCK) может иметь много билетов. (BLOCK -> one-to-many -> USER)
- Каждый билет должен быть виден соответствующему администратору. (ADMIN -> one-to-many -> TICKET)
- Кроме того, каждый пользователь может иметь много билетов. (USER -> one-to-many -> TICKET)
- Каждый администратор может иметь много пользователей (ADMIN -> one-to-many -> USER).
СОБЫТИЙНАЯ СТОРОНА ВОПРОСА
- каждый пользователь может организовать множество мероприятий, и в каждом мероприятии будет участвовать множество пользователей (USER -> many-to-many -> EVENT).
- Теперь, если место проведения мероприятия похоже на дом пользователя, это не имеет значения. Фильтр событий не нужен.
- Но если пользователь хочет организовать мероприятие в общественном месте, то ему потребуется разрешение администратора, поэтому, при необходимости, за мероприятие будет отвечать один конкретный администратор (ADMIN -> one-to-many -> EVENT).
Как вы можете видеть. На первый взгляд я думал, что это будет простое приложение, но на самом деле это не так (по крайней мере, для меня).
Вот мысленный эксперимент, как пользователь узнает, что администратор начал действовать по его/ее тикету или жалобе. Итак, я должен как-то связать действия администратора с пользователем, чтобы пользователь мог получать информацию поэтапно, например, ACKNOWLEDGED означает, что ваш тикет рассматривается администратором. IN PROGRESS означает, что кто-то занимается решением вашего вопроса. CLOSED, означает, что ваш вопрос решен. Теперь, прежде чем закрыть проблему, администратор должен узнать у пользователя, решена ли его проблема, или есть ли какие-либо предложения, администратор не может закрыть тикет без разрешения пользователя. Итак, кодировать это хорошо, но как создать из этого отношение к базе данных? Я все еще бьюсь головой над этим вопросом. Скрестим пальцы, надеюсь, я найду его,
Вот диаграмма, которую я смог придумать. Она неправильная, мне все еще нужно наметить несколько отношений, но вот она.
Если у кого-нибудь есть предложения или кто может помочь с figma, свяжитесь со мной. Я все еще работаю над многими вещами, так что многое может измениться, я могу использовать mongo DB, вместо postgres, который я планировал. Посмотрим. Пока. Также пожелайте этому тупому парню удачи, чтобы он действительно справился со всем этим. Пока.