SQL-запрос. Считается ли это извращением?

Ещё такой подход мне в голову пришёл… не знаю, делают ли так и нормально ли это, но суть:
Для тем/комментариев использовать по 2 таблицы, типа discus (com) и discus_body (com_body). В discus столбцы id (первичный уникальный ключ с автоинкрементом), pubdate (дата публикации), closed (закрытая или открытая тема), dcid (id категории, в которой лежит тема), num_com (кол-во клиентов), last_cid (id крайнего комента). По всем этим полям можно будет сортировать или делать выборку. То есть, получать только закрытые темы, или только принадлежащие той или иной категории. И сортировать, по дате публикации (но здесь я предпочёл не по дате, а по id), по количеству коментов, по обсуждаемым… А в таблице discus_com id (первичный уникальный ключ БЕЗ автоинкремента - означает id темы (про вторичный ключ я нихрена ещё не понял… потом этим займусь), subject, content и ещё всякая инфа.

то что ты написал, это называется связи. Один к одному, один ко многим, многие ко многим. Только в промежуточной таблице должны быть только id темы и id комментариев, которые относятся к этой теме. Про оптимизацию, её нужно делать только при необходимости. Когда без этого никак. Возьми себе за правило это. Данных надо больше забить в базу, гораздо больше, и то это не покажет тебе реальных результатов, только приблизительные

Ok. Спасибо

кому как. а вообще, дабы избежать путаницы под коменты создаешь доп базу и весь десяток таблиц с комментами держишь в ней. причем вполне можно держать несколько коннектов как к разныб бд(пдо, ми скл, ми скл"и, склЛайт и т.д.) а можно к одной. обычно хосты указывают какие бд можно создавать у них и в каком кол-ве, так что в случае чего моно перепрыгнуть на другой хост, ну а на локалке просто установить нужную.
и да, у разных бд разный функционал и оптимизированость под разные кейсы(видел на хабре статью, там в некоторых случаях разница в разы)
ну и соответственно под комменты можно выбрать что то оптимизированное скажем под 1кк+ запросов в минуту\час\день\хз чо там еще. а скажем под сами темы что нить с удобными селектами лимитами и прочими ништяками для конструирования специфической выборки
нууу теоритически да и должно быть указано в описаниях самих бд на оф сайтах. сам этим не интересовался, так что цифр даж примерных у мну нету =(
таки нет. лимит на то и лимит чтоб останавливать по достижении указанного кол-ва. если не то получается то вариантов есть несколько:
опечатка, запутался в скобках(ну лимит установился не для запроса целиком а только для его части), ну или худшее но и наименее вероятное: сис.баг в самой бд
по сути по той же причине всё это бросил))
только есть пара ощитумых НО:
1. оптимизация это когда у тя уже есть работающий более менее корректно(хотя бы в рамках тз)
2. если меняешь планы до написания кода - это таки проектирование архитектуры проекта
3. а если переписываешь до релиза но код уже хоть какой то есть, это сраное сада маза...

как у меня так похоже у тебя как раз 3й вариант.
в свое время вот такой велик изобрел:
$db = [
query => ['mysql_query()', 'mysqli_query()', 'sqllite_query()'],
connect=>....
];
конечно в проде такое врятли стоит ставить но для экспериментов более чем годится) и да, у разных бд разные функии по разному используются, тот же коннект у SqlLite и MySql вообще разные пндц насколько. так что для более менее внятного и стабильного переключения между бд они вроде таки в разных ключах были хотя хз, уже не уверен.
в конечном итоге выглядело как то так:
core.php
$auth = [
mysql=> [name, 012, 345],
mysqli=> [name2, 678, 9ab],
];
$db_types=[index=>0, auth=>1, mail=>0];


index.php
$this = 'index';
require_once(core.php);
$dbc = $db[connect][$db_types[$this]]($auth[$db_types[$this]])
// хотя пожалуй тут уже ошибок куча, пора наверн спать
т.е. как только скажем таблы почты перенес с mysql на mysqli, достаточно было в $db_types в ключе mail сменить 0 на 1 и вся почта уже конектилась корректно к другой бд
// но естественно приходилось вычитывать форумы залпом перед добавлением функций, да и делалось все на чистом энтузиазме - JustForFan и эдак на 10й функции процесс заглох))
вроде чо то понял но чо именно понял еще не понял))
ну а серьёзно эм... пытаешь предъугадать все столбцы какие только могут быть полезны в одной табле а во второй только пара самых необходимых столбцов чтоб остальными не перегружать бд? если да то это актуально в мастабах гугла яндекса и прочих, если у тя скажем нет своего десятка дата центров которые прям щас уже перегружены, то прост забей и делай одну адекватную таблу)
когда и если вырастешь до масштаба гугла, нанять охапку рандомных фрилансеров уж явно не будет проблемой.