- 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 или ... ???
- Прошу в комментарии, буду рад получить советы от более опытных разработчиков !)
@0136, о каких нормальных формах может быть речь если в предложенном мной решении нет отношений? Храненике массива вместо скалярного типа данных никак не относится ни к одной из нормальных форм. Где написано, что хранение не скалярного значения нарушает хоть что-нибудь? :)
Какой смысл вы вкладываете в эту ↓ фразу?
Меня больше всего интересует что вы подразумеваете под словом "простым".
Да и что вы к этим нормальным формам прицепились. Если вводить отношения/сущности при любой возможности у вас получится слишком академический подход к построению структуры БД, а академический подход не всегда является удобным, понятным, да и его не всегда можно назвать объективно правильным. Я найду много причин не вводить новую сущность, а вы найдёте столько же причин для того, чтобы её ввести. Разница есть только в том, что вы потом придёте к мысли, что вы зря это сделали, а я быстрее решу поставленную задачу. Поэтому вопрос стоит в том - насколько это необходимо. Я думаю, что в данном кейсе, да и во всех похожих, вынесение тега в отдельную сущность - лишнее.
У меня очень богатый опыт работы как с SQL так и с NoSQL, поверьте мне, я знаю о чём говорю :)