Ряды в MySQL
 

Вобщем я недавно скачал скрипт (на php) работающий с мускулом и когда увидел структуру таблиц ужаснулся: в некоторых его таблицах было до 100 (!) рядов.
Максимум рядов которые я создавал в своих скриптах был окола 35, и то я думал что это не хорошо...
Так вот вопрос: какое оптимальное количество рядов в одной таблице мускула ?
ЗЫ
А то я в поиске что то не нашел нормальной документации по этому поводу.

Каких рядов?
Если имеется виду полей в таблице.. то тут вам не ответят касаемо нужного кол-ва.
Я думаю вам стоит почитать по теории нормализации таблиц. И структуру реляционных баз данных..

Ведь дело не в кол-ве, а в правильной нормализации

Вопрос о практике.

Теперь о рядах. Вообще ряд это row. И к структуре они имеют весьма отдалённое отношение. Структура, - это поля, их типы, индексы и т.д. Количество полей вцелом ничем не ограничено. На быстродействии больше сказывается их тип.

Сам по себе вопрос "какое оптимальное количество полей в одной таблице мускула" абсурден. Вы что поля просто так создавали? Наверно они всё-таки зачем-то нужны...

ну если имеется ввиду row.. то тогда согласен с тобой.. тут судить о всем выше сказанном не стоит..
Я думал имеется виду структура таблицы, а не данные.

У меня в игре в таблице чата более 750 000 этих самых row

оптимальное для чего?? помнится у меня стоял вопрос как организовать таблицу - сделать много колонок (это те которые имеют тип, индексы, т.е. структура), или сэкономить на колонках, но при этом количество записей (это вроде и есть rows про которые говорят) увеличится, в итоге никто толком ответить на этот вопрос и не смог....:( на практике пришел к выводу о том, что быстродействие зависит от обоих параметров, и по ходу приходить к какому-то оптимуму приходится экспериментальным путем:) то, что рядов (наверное колонок, т.е. структуры в данном случае) 100 штук - это нормально, наверняка, как правильно заметил RaZEr они создавались из каких-то соображений, и их уменьшение приводит к чему-то другому не очень хорошему. А вообще огромное влияние на быстродейтвие всяческих запросов оказывает не столько размер таблицы, а правильное расставление индексов (по крайней мере на SELECT, а INSERT будет дольше работать)...
во-во, у меня например в таблицах до 1000000 записей достигается (потом в хистори откладывается часть), и при этом количество полей тоже немаленькое, штук 20 есть (сейчас точно уж не помню) и работает достаточно быстро... ;)

Во первых извините что не уточнил с самого начала (просто был соным с утра :rolleyes: ):
Речь конечно же идет о полях.
Вопрос состоит в том, что лучше задействовать на практике: 2 таблицы с уникальными идентификаторами (на уникальных стоит индекс, больше индексы не использую, так как поиск происходит исключеительно по id) с 50 полями в каждой или же стоит объеденить эти таблицы в одну.
Я конечно понимаю, что вопрос звучит мягко сказать страно, так как есть много параметров (например какие даные чаще нужны, общее количество запросов и т.д.), но все же.
Например: онлайн игра (просто для примера), таблицы users и parameters (игровые параметры игрока). Так как фактически в users храниться информация, которая нужна только при входе (пароль, статус и т.д.) и parameters, к которой есть обращение практически с каждой страницы.
Стоит ли их объеденить или лучше использовать две отдельные небольшие таблицы ?

ну просто лучше логически разделять таблицы, но также не надо слишком увлекаться этим, т.е. нужно делать именно там, где это действительно необходимо, т.е. если ты юзаешь одну таблицу при каждом входе и очень часто, а другую один раз в год, то понятно, что не стоит их объединять, просто все зависит от конкретной ситуации, и чаще всего это выявляется опытным путем:)