SELECT --выбрать
c.name as category_id, -- колонку name из c и обозначить её как category_id
r.id, r.name, r.country_id, p.category_id -- колонки id, name, country_id из p
FROM -- из
" . $this->table_name . " p --какой-то таблицы, обозначая её как p
LEFT JOIN -- соединив её слева
category c -- с таблицей category (обозначая её как c)
ON p.category_id = c.id -- по совпадению значений в колонках category_id и id
WHERE -- накладывая условие
p.id = ? -- поле id из p равно какому-то значению
LIMIT 0,1 -- и выбрать одну (первую) запись (а сортировки-то и нет! Какую считать первой?)
SELECT
`tokens`.*
FROM `tokens`
ORDER BY REPLACE(SUBSTRING_INDEX(s_short,';',3), SUBSTRING_INDEX(s_short,';',2), '') DESC;SELECT
`tokens`.*
FROM `tokens`
ORDER BY SUBSTRING_INDEX(SUBSTRING_INDEX(s_short,';',3),';',-1) DESC;У меня сейчас имеется одна таблица для одного поста.Точно? Это на сайте будет один пост? Или под каждый пост будет таблица? Или все таки одна таблица для постов? (читать про нормальные формы бд, 1,2 и 3 НФ)
Но как лучше реализовать комментарии, чтобы была одна таблица, но там хранились комментарии из разных постов?Очень просто: Таблица, где будет поле post_id, которое будет указывать на пост, к которому относится комментарий. Если структура иерархическая, то еще parent_id, указывающий на какой комментарий это ответ. (Читать про отношения Один-ко-многим, хотя и про остальные тоже для общего развития. Ну и про иерархические структуры через nested sets)
понимаете, если будет много комментов, то долго будет обрабатываться. =/Понимаете, вы нихрена не разбираетесь в вопросе, но уже уверенно несете чушь про "будет долго обрабатываться", хотя точно этого не знаете (спойлер: не будет долго обрабатываться).
CREATE TABLE book (
id INTEGER PRIMARY KEY,
title VARCHAR(128),
year INTEGER,
author_id INTEGER,
FOREIGN KEY(author_id) REFERENCES author(id)
);
UPDATE TABLE_NAME
SET field_name = LOWER(field_name)