select count(*) from post_like where post_id = ?post_id
А если я захочу закэшировать результат? бегать после каждого лайка по таблице дорого, насколько я понимаю. + пользователь может передумать и поменять лайк на дизлайк
А если я захочу закэшировать результат? бегать после каждого лайка по таблице дорого, насколько я понимаю. + пользователь может передумать и поменять лайк на дизлайк
я тебе ранее написал, заведи поле like_count в посте
Несколько вопросов по теме: FK лучше делать между user_id - post_id или id - post_id (user_id - 6 цифр, id - индекс пользователя в таблице ? Нужно ли писать PRAGMA foreign_keys = ON ? Как оптимально запретить несколько голосов от 1 юзера (оставляя возможность переголосовать)? Гуглил по этой теме, но авторитетного ответа не нашел
Несколько вопросов по теме: FK лучше делать между user_id - post_id или id - post_id (user_id - 6 цифр, id - индекс пользователя в таблице ? Нужно ли писать PRAGMA foreign_keys = ON ? Как оптимально запретить несколько голосов от 1 юзера (оставляя возможность переголосовать)? Гуглил по этой теме, но авторитетного ответа не нашел
Я могу так написать: FOREIGN KEY (user_id) REFERENCES users (user_id) ON DELETE CASCADE, А могу так: FOREIGN KEY (id) REFERENCES users (user_id) ON DELETE CASCADE, По логике разницы нет, но вдруг ..
DDL cursor.execute("""CREATE TABLE IF NOT EXISTS users_ids( id INTEGER PRIMARY KEY, user_id INTEGER NOT NULL UNIQUE)""")
Я могу так написать: FOREIGN KEY (user_id) REFERENCES users (user_id) ON DELETE CASCADE, А могу так: FOREIGN KEY (id) REFERENCES users (user_id) ON DELETE CASCADE, По логике разницы нет, но вдруг ..
DDL cursor.execute("""CREATE TABLE IF NOT EXISTS users_ids( id INTEGER PRIMARY KEY, user_id INTEGER NOT NULL UNIQUE)""")
Хотелось бы, чтобы старые клиенты могли пользоваться новыми данными, а новые старыми и чтобы там были изменения серьезнее добавления полей, например, изменение, что-то ещё такое