- RESTful API\PostgreSQL
- Сущность TAG (таблица tags)
- Все теги всех юзеров хранятся в одной таблице(tags). Названия тегов уникальны(qnique).
- Сущность POST(новость, таблица posts)
- Все посты всех юзеров хранятся в одной таблице(posts)
- Отношение ManyToMany через posts_tags связующую таблицу
- На момент добавления тега сущность поста создана и имеет свой уникальный ID
- Получение всех постов по тегу
- Получение поста со всеми связанными тегами
- Добавление тега у клиента происходит во вьюхе редактирования поста
- Добавление существующего тега к посту
- Добавление нового тега к посту
- Теги вводятся в специально отведенный для них блок(аля medium, evernote, github)
- Теги в одном посте уникальны и не могут повторяться
- Юзер начинает вводить название тега
- Система автокомплита производит поиск тега(глобально по всем тегам в БД)
- Юзер выбирает предложенный тег системой (1)
- Система проверяет присуцтвует ли тег в посте
- FALSE >> аттачит тег к посту(делает запись в связующей таблице posts_tags)
- TRUE >> выдает ошибку
- Система проверяет присуцтвует ли тег в посте
- Юзер выбирает предложенный тег системой (1)
- Юзер вводит новый тег(юзер игнорирует автокомплит)
- Система смотрит нет ли такого же тега в БД
- FALSE >> создает тег и аттачит тег к посту(делает запись в связующей таблице posts_tags)
- TRUE >> Система проверяет присуцтвует ли этот тег в посте
- FALSE >> аттачит тег к посту(делает запись в связующей таблице posts_tags)
- TRUE >> выдает ошибку
- Система смотрит нет ли такого же тега в БД
- Система автокомплита производит поиск тега(глобально по всем тегам в БД)
- Теги вносятся в тело поста(аля twitter, facebook)
- Юзер может добавлять скольнеобходимое количество тегов(в разумных пределах)
- Теги в одном посте не уникальны и могут повторяться
- Юзер начинает вводить название тега
- Система автокомплита производит поиск тега(глобально по всем тегам в БД)
- Юзер выбирает предложенный тег системой (1)
- Система проверяет присуцтвует ли тег в посте
- FALSE >> добавляет ссылку на тег в контент поста и аттачит его к посту(делает запись в связующей таблице posts_tags)
- TRUE >> добавляет только ссылку на тег в контент поста(дабы избежать дублирования в связующей таблице)
- Система проверяет присуцтвует ли тег в посте
- Юзер выбирает предложенный тег системой (1)
- Юзер вводит новый тег(юзер игнорирует автокомплит)
- Система смотрит нет ли такого же тега в БД
- FALSE >> создает тег и аттачит его к посту(делает запись в связующей таблице posts_tags)
- TRUE >> Система проверяет присуцтвует ли этот тег в посте
- FALSE >> добавляет ссылку на тег в контент поста и аттачит его к посту(делает запись в связующей таблице posts_tags)
- TRUE >> добавляет только ссылку на тег в контент поста(дабы избежать дублирования в связующей таблице)
- Система смотрит нет ли такого же тега в БД
- Система автокомплита производит поиск тега(глобально по всем тегам в БД)
(1) - Если желаемынй тег присуцтвует в списке предложенный системой, система принудительно вибирает тег из списка и аттачит его к посту. Что предотвращает ошибку в БД при попытке создать дубликат тега.
- Правильно ли представленны story для решения задачи ?
- Каково ваше видение реализации подобного функционала ?
- Если посмотреть на API github или twitter то у них ID в тегах не используются. Почему так ? Или они хайдят ID или ... ???
- Прошу в комментарии, буду рад получить советы от более опытных разработчиков !)
Post - это "посляшка"? :)
https://translate.google.com/#en/ru/post
Если вы пытаетесь реализовать что-то вроде блога или новостного движка, то лучше называть вещи своими именами, а слово "пост" в русском языке (да и в английском тоже) имеет несколько (читай как "совсем") другое значение, нежели "статья".
Насчёт тэгов:
Если бы вы работали с не реляционной СУБД, то такого вопроса бы не появилось, т.к. там подобные отношения являются плохой практикой. Но и в РСУБД не нужно пытаться из всего сделать сущность и везде использовать отношения, когда введение отношений усложняет понимание и работу с даными.
Если рассматривать "тэг" как самостоятельную сущность, то получается, что это сущность с одним признаком. Но мне кажется, что "тэг" - это всё таки признак сущности "статья". Если нет никакого смысла делать из признака сущности отдельную сущность - то лучше этого не делать. Как говорится: не плодите сущности без необходимости (бритва Оккама).
Я в одном своём проекте где нужно было реализовать работу со статьями сделал без отдельных таблиц и отношений, получилось намного быстрее реализовать и понятно сразу что к чему, к тому же для такого решения проще писать и бэкэнд и фронтэнд, т.к. нет "лишних" методов для работы с тэгами.
Ответ на вопрос "Если посмотреть на API github или twitter то у них ID в тегах не используются. Почему так ? Или они хайдят ID или ... ???": в чём проблема сделать PK из тэга в таблице, которая связывает тэги и статьи?