CREATE TABLE tasks (
id PRIMARY KEY,
definition,
performer_id REFERENCES performer (id)
expired_at DATETIME
);
UPDATE tasks
SET performer_id = @performer_idб
expired_at = NOW() + INTERVAL 'performing time'
WHERE ( expired_at IS NULL or expired_at < NOW() )
AND ( id = @task_id )
print base64_decode('0KnQtdC/0LAg0KHQзtdGA0LPQtdC5'); // Щепа Сергей
?utf-8?Q?=D0=A9=D0=B5=D0=BF=D0=B0 =D0=A1=D0=B5=D1=80=D0=B3=D0=B5=D0=B9?=
У меня сейчас имеется одна таблица для одного поста.Точно? Это на сайте будет один пост? Или под каждый пост будет таблица? Или все таки одна таблица для постов? (читать про нормальные формы бд, 1,2 и 3 НФ)
Но как лучше реализовать комментарии, чтобы была одна таблица, но там хранились комментарии из разных постов?Очень просто: Таблица, где будет поле post_id, которое будет указывать на пост, к которому относится комментарий. Если структура иерархическая, то еще parent_id, указывающий на какой комментарий это ответ. (Читать про отношения Один-ко-многим, хотя и про остальные тоже для общего развития. Ну и про иерархические структуры через nested sets)
понимаете, если будет много комментов, то долго будет обрабатываться. =/Понимаете, вы нихрена не разбираетесь в вопросе, но уже уверенно несете чушь про "будет долго обрабатываться", хотя точно этого не знаете (спойлер: не будет долго обрабатываться).
Может его выкупят конкуренты или еще как-то получить от него пользу?
его особо не монетизировать
Делаю точь в точь,ага, конечно, оставьте эти сказки кому то другому. Не знаю что там за лекция, но там точно будет не так как у вас
Не нравитсо именно это
Invalid default value for 'post_date'