Вы можете использовать его следующим образом
function add(el) {
var title = $(el).next("h4").text();
console.log(title);
$("#InsertTitle.h5").text(title);
}
И в HTML
<i onClick="add(this)" class="i-hover"></i>
Примечание: , используя
blockquote>$(this)
непосредственно в функции может не ссылаться на нужный элемент .. поэтому вы можете передать аргумент для (this)
Я думаю, что предложенная вами структура (без «назначенного» поля в соответствии с комментариями) будет работать, с добавлением дополнительной таблицы, скажем «Submissions_User», содержащей ссылку на user_id & amp; инкрементное поле для подсчета заявок. Тогда все, что вам нужно, это «прослушиватель событий» в соответствии с этим постом и метинкс, который вы будете устанавливать.
РЕДАКТИРОВАТЬ: Для значков достижений запускайте прослушиватель событий при каждой отправке (только для пользователя, выполняющего отправку курса) и присваивайте любой соответствующий значок на месте. Для значков, основанных на времени, я каждую ночь выполнял работу CRON. Пройдите один раз по всему списку пользователей и присвойте значки соответствующим образом.
Я думаю, что это один из тех случаев, когда подходит таблица «многие ко многим» (Badges_User).
Но с небольшим изменением, чтобы неназначенные значки не сохранялись.
Я предполагаю, что assigned_at
- это дата и / или время.
По умолчанию у пользователя нет значков.
Badges | Badges_User | User
----------------------------------------------
bd_id | bd_id | user_id
bd_name | user_id | etc
bd_desc | assigned_at |
| |
Таким образом, сохраняются только действительно награжденные значки.
Строка Badges_User создается только тогда, когда пользователь получает значок.
С уважением
& nbsp; & nbsp; & nbsp; & nbsp; Sigersted
относительно скетча, который вы включили: избавьтесь от логического столбца в badges_user. здесь нет смысла: это отношение определяется в терминах предиката «user user_id получил значок bd_id at assign_at».
Что касается вашего общего вопроса: сначала определите схему как реляционную без учета скорости (это будет избавит вас от половины потенциальных проблем с производительностью, возможно, в обмен на другие проблемы с производительностью), правильно проиндексируйте его (что правильно, зависит от шаблонов запросов), а затем, если он медленный, получите (все еще реляционный) дизайн из того, что быстрее . например, вам может потребоваться предварительное вычисление некоторых агрегатов и т. д.
Я бы сохранил структуру типов, аналогичную вашей
Badges(badge_id, badge_name, badge_desc)
Users(user_id, etc)
UserBadges(badge_id, user_id, date_awarded)
А затем добавьте таблицы отслеживания в зависимости от на том, что вы хотите отслеживать и на каком уровне детализации ... затем вы можете соответствующим образом обновить таблицу и установить для нее триггеры, чтобы "присваивать" значки
User_Activity(user_id, posts, upvotes, downvotes, etc...)
Вы также можете отслеживать статистику с другой стороны и запускать награды значками
Posts(post_id, user_id, upvotes, downvotes, etc...)