Форум MySQL

Что ценнее - малый размер таблиц в базе или малое количество обращений к ним? Напрмер, в гостевой можно в таблице с постами хранить и id автора, и его ник - тогда одним запросом выводится и то и другое. Или можно хранить только id, а ник узнавать с помощью дополнительного запроса к таблице пользователей. В первом случае используется лишнее поле, во втором - лишний запрос. Гостевая взята просто для примера; в целом, на что надо обращать внимание?

Верно подмечено, что скорость выполнения и объём базы данных являются практически взаимозаменяемыми величинами (исключение составляет случай, когда скорость падает по причине большого объёма базы). Здесь сложно заранее сказать - это зависит от задачи и условий. Ряд хостингов, например не тарифицируют объём базы данных - бери сколько хочешь (ну так чтобы на тебя внимание не обращали), а оплачиваешь только место под файлы. Кроме того ряд задач требуют максимально быстрого выполнения поиска, в этом случае лучше проиндексировать столбцы, даже если это приведёт к двух-трёх кратному увеличению скорорости. Мы согласны ещё в два раза увеличить объём базы данных, лишь бы скорость не падала. Однако с другой стороны разработчику объём базы данных превышающий лимит его тарифного плана может быть критичным.
Пример который вы привели называется нормализацией (разбиение на несколько таблиц) и денормализацией (сведение в одну таблицу). Трудно сказать заранее, мы в форуме вынесли отдельную таблицу авторов, потому что информацию об авторах смотрят не часто, с другой стороны имя автора и его первичный ключ продублированы в таблице сообщений, чтобы не терять в скорости на двухтабличном запросе, при формировании дерева ответов, что происходит очень часто.
Нельзя дать универсальный ответ на все случаи жизни, это как в экномике пушки и масло, и в программировании скорость и читабельность. Нужно искать всегда компромис. Тенденция однако такова - цены на объём памяти падают, а запросы пользователей растут - поэтому в база данных следует ориентироваться на скорость - но стараться избегать преждевременной оптимизации, ибо по словам классика "это корень всех зол".

Спасибо за столь подробный ответ!

>Пример который вы привели называется нормализацией
>(разбиение на несколько таблиц) и денормализацией (сведение
>в одну таблицу).
Приятно узнать, что ты на самом деле спрашиваешь=)

>Тенденция
>однако такова - цены на объём памяти падают, а запросы
>пользователей растут - поэтому в база данных следует
>ориентироваться на скорость
Вот это и хотелось услышать - к чему, в конечном счете, стремиться.

>но стараться избегать
>преждевременной оптимизации, ибо по словам классика
>"это корень всех зол".
Неслабый классик, который говорил об оптимизации таблиц MySql )))

>>но стараться избегать
>>преждевременной оптимизации, ибо по словам классика
>>"это корень всех зол"
>Неслабый классик, который говорил об оптимизации таблиц
>MySql )))
Ну вряд ли Кнут имел ввиду конкретный код :))), в те времена программист мог за несколько лет поработать на нескольких операционных системах и нескольких платформах - это обобщение вообще на программирование.

Упс... Я как-то при слове "классик" о литературе вспомнил:))