Создание сайтов и программирование
я бы в случае с большой бд, при создании темы не запись в табло лепил бы, а новую таблицу создавал..))
ну т.е. у каждой темы форума будет своя таблица "dcom" с комментариями)
а можно наоборот просто разделить уже имеющуюся таблицу на десяток.
в случае с гиговыми таблами это таки должно дать немало пользы))
и да, в случае когда у каждой темы своя табла, максимально допустимое кол-во комментов конечно тоже не может стать бесконечным, но без лагов вырастет как минимум в разы.
Создание сайтов и программирование
Вкратце разъясню, что делает запрос:
берёт данные об обсуждениях (постах/темах), его категории...
Подробнее... берёт данные об обсуждениях (постах/темах), его категории...
0 0 2
Комментарии (45)
ответил JohnDidact
по идее исходя из здравого смысла должно быть как то так:
null ~ запись не существует
false ~ существует с отрицательным вариантом
true ~ существует с положительным вариантом
'' ~ существует но пусто(в зависимости от выбранной проверки, может прилететь любой из ответов)
если проверка на существование записи то тру, если на наличие содержимого в ней то нул\фальш
null ~ запись не существует
false ~ существует с отрицательным вариантом
true ~ существует с положительным вариантом
'' ~ существует но пусто(в зависимости от выбранной проверки, может прилететь любой из ответов)
если проверка на существование записи то тру, если на наличие содержимого в ней то нул\фальш
Имею ввиду, что поле hidden имеет вид char(0) и содержит либо NULL, либо пустую строку. Крч... Тот запрос в теме - опа полная, как я понял. Решил от такого подхода отказаться и кэшировать на сервере то, что обновляется не так часто. Да и с джоинами решил быть осторожен. Ещё и предпочёл использовать в запросах временные таблицы (один хрен джоины их создают, чё мне бы не создавать, потом к ним всё липить, дабы фулскан по таблице не шёл), и индексы тож...
У меня возник ещё один вопрос. ТОчнее, не вопрос, а просьюа готовго решения.
Есть таблица dcom (список комментариев), поля - id int(4), did int(4), hidden tinyint(1). did - id темы, к кторой относятся коменты, hidden - скрыт ли комент, принимает 2 занчения (либо 0, либо 1). Задача получить 10 айдишников нескрытых комментариев, котроые относятся к теме с айди 7, отсортировать по возрастанию айди комента. Запрос, ясное дело, выглядит так:
У меня возник ещё один вопрос. ТОчнее, не вопрос, а просьюа готовго решения.
Есть таблица dcom (список комментариев), поля - id int(4), did int(4), hidden tinyint(1). did - id темы, к кторой относятся коменты, hidden - скрыт ли комент, принимает 2 занчения (либо 0, либо 1). Задача получить 10 айдишников нескрытых комментариев, котроые относятся к теме с айди 7, отсортировать по возрастанию айди комента. Запрос, ясное дело, выглядит так:
SELECT id FROM dcom
WHERE did = 7 AND hidden = 0
ORDER BY id
LIMIT 10
Вопрос возник в том, какой индекс использовать для более быстрого ответа. Если использовать чисто первичный ключ (id), то мускул полностью проходит по индексам, но в табле проходит только по 10 строкам, руководствуясь LIMIT. Если использовать индекс dcom(did,hidden), то как бы и норм (type: ref), но проходит по всем строкам, которые соответствуют условию, невзирая на LIMIT. Добавляя id к составному индексу ничего не изменялось. Мускл хоть и использовал эти индексы, но использовал их не полностью (часть их, от 7_0_2, он использовал 7_0, так же от 1_7_0 использовалось только...хз что именно - 5 байтов (int и tinyint)). В общем вопрос про индексы. Как составить индекс, чтоб запрос выполнялся максимально быстро? Пожалуйста подскажи) Вообще, такой запрос - это извращение. Практически все таблицы в запросе будут полностью просканированы... Временная табла будет боооольшим весом, если не влезет (а она не влезет) в оперативную память (тут ещё можно упомянуть про tmp_table_size и max_heap_table_size, но автор пока что туп, лучше его этии пока что не загонять), то запишется на диск, что вообще не хорошо.
Как составить индекс, чтоб запрос выполнялся максимально быстро?
по функционалу хз, но по извращениям идейка таки естья бы в случае с большой бд, при создании темы не запись в табло лепил бы, а новую таблицу создавал..))
ну т.е. у каждой темы форума будет своя таблица "dcom" с комментариями)
а можно наоборот просто разделить уже имеющуюся таблицу на десяток.
в случае с гиговыми таблами это таки должно дать немало пользы))
и да, в случае когда у каждой темы своя табла, максимально допустимое кол-во комментов конечно тоже не может стать бесконечным, но без лагов вырастет как минимум в разы.
Если использовать индекс dcom(did,hidden), то как бы и норм (type: ref), но проходит по всем строкам, которые соответствуют условию, невзирая на LIMIT
а запросы одинаковые делал? если да то проверь настройки самих столбцов ид"ов через PMA иль прочую sql-админку(autoincrement, notnull и вот это вот всё) и проверь на опечатки, мб лимит во 2м варианте просто отвалился или применяется только к части запроса а не ко всему. ответил PAI3EJI
Планируется, что темы будут создаваться примерно ежеминутно всеми пользователями форума… Не слишком ли дохрена таблов будет?) Мне тоже в голову такая мысль приходила - удобней мне было с этим работать. Но таблиц вышло бы немеренно. Существует вообще ограничение на кол-во таблиц?
На счёт лимит… я тут подумал Может я рано делаю выводы? У меня таблица размером примерно в строк 20, так как я на локалке пилю. Может нужно больше строк, чтобы мускул решения какие-либо принимал. Да дошло, что он должен не ровно по limit проходить, а до того, как все совпадения обнаружит. То есть, промежутояные, между теми, которые в условия входят, он тоже ведь обходит??? Или хз, я уже путаться начинаю. Нужно мне больше данных)
Вообще, мой грешок - это ранняя оптимизация. Из-за неё я ничего не могу закончить. Вечно что-то допиливаю или перепиливаю. И если перепилю одно, то нужно будет и второе перепилить. Раньше, общаясь с БД, использовал mysql функции, затем функции mysqli, потом класс PDO. И буквально вчера перешёл на класс MySQLi, так как там можно без проблем делать мультизапросы и вытаскивать с каждого инфу. В PDO я такого не нашёл.
На счёт лимит… я тут подумал Может я рано делаю выводы? У меня таблица размером примерно в строк 20, так как я на локалке пилю. Может нужно больше строк, чтобы мускул решения какие-либо принимал. Да дошло, что он должен не ровно по limit проходить, а до того, как все совпадения обнаружит. То есть, промежутояные, между теми, которые в условия входят, он тоже ведь обходит??? Или хз, я уже путаться начинаю. Нужно мне больше данных)
Вообще, мой грешок - это ранняя оптимизация. Из-за неё я ничего не могу закончить. Вечно что-то допиливаю или перепиливаю. И если перепилю одно, то нужно будет и второе перепилить. Раньше, общаясь с БД, использовал mysql функции, затем функции mysqli, потом класс PDO. И буквально вчера перешёл на класс MySQLi, так как там можно без проблем делать мультизапросы и вытаскивать с каждого инфу. В PDO я такого не нашёл.
Для добавления комментариев необходимо авторизоваться
Флибустьеры
Грабь корабли! Побеждай монстров! Создавай уникаль...