Как вы думаете имеет ли смысл делать такую необычную структуру комментариев?

dkameleon, вообще-то я спрашивал вопрос "Будет ли такая система оптимальной"? Или все же лучше оставить всё как есть, т.е. индексы + кэш. Я не утверждал, что предложенный мною вариант будет лучше, а спрашивал "Будет ли он лучше?". Пошла уже вторая страница а никто так и не дал вразумительного ответа и не объяснил почему.

Впрочем, тему можно закрывать. Я уже получил подробный ответ на другом форуме.

Если бы такая системы была оптимальной - её бы все юзали. Он она не удобна и не функциональна. Поэтому её никто не юзает.

Вообще неплохо бы вам ознакомиться с теорией БД, хотя бы обзорную статейку про нормализацию почитать.

развивайте тему! я взял уже попкорн

seodude, я уже получил подробный ответ в другом форуме, так что развивать эту тему в этом форуме не буду, так что отложи пока попкорн. Еще будут темы, в которых он тебе понадобится.

Не будет, так как:

1) Неудобно управлять тысячами таблиц

2) Невозможно в принципе легко получить данные нескольких комментариев, скажем для поиска, модерации, RSS и т.п.

3) В любой ОС (хостинге, VDS) есть ограничение на кол-во файлов, на каждую таблицу создается 3 файла.

4) Имена таблиц по сути тоже хранятся в таких же таблицах (где же ещё?), т.е. чтобы получить таблицу с именем XXX_11, MYSQL выполнит запрос вида SELECT * FROM ... WHERE NAME = 'XXX_11';

WhiteSmartFox, спасибо за информацию.

Ошибочное замечание. Самые быстрые индексы это когда использует авто генерация значений, т.е. ключ числовой и идет по порядку. Скорость чтения и записи с такими индексам может быть теоретически почти равна скорости чтения данных из отдельного файла, т.е. если бы вы каждую запись хранили в отдельном файле (не буду объяснять почему, поверьте знаю что говорю - сам писал подобные индексы файловой БД), если в таблице нет индексов MySQL вынужден просматривать ВСЕ записи, т.е. при миллионах записях скорость чтения с индексами и без может отличатся в почти сотни тысяч раз.

P.S. Да у MySQL есть проблемы при частом чтении и записи в очень большие таблицы (с миллионами записей), но обычно оно возникает при текстовых индексах (скорость работы с ними в десятки и сотни раз медленнее чем индексов автогенерируемых полей) или не правильных SQL запросах, тогда имеет смысл разделить таблицы, но делить таблицы менее чем до 10000 записей не рационально. То есть можно делить на таблицы вида:

comments_1 - c 0 до 10 тыс

comments_2 - с 10001 до 20000

и т.д.

Либо пересмотреть структуру БД так чтобы она работала с авто генерируемыми полями.

Master812, вы меня расстроили :(

продолжайте пожалуйста! хочется продолжения!

Master812, предлагаю сразу пойти дальше: в своем самописном движке блога отдельные рубрики разбейте на разные базы данных. ну и верхом совершенства будет разные разделы разнести по разным серверам.

orphelin, красава))