BION wrote:

> В таблицах будут храниться имена и пути к файлам, соответственно длины
> текстовых строк от ~5 и более.
> База mysql, также будет fulltext search.
> Всегда пользовался форматом varchar, но при изучении вопроса
> использования типов полей случайно наткнулся вот на это (выделено болдом)
> автор

Разница, о которой тут говорится, всегда незначительная - она гораздо
меньше (на несколько порядков), чем время чтения с диска - самой
длительной операции в СУБД, поэтому этой разницей можно принебречь,
а на проблему плюнуть. Единственное, если у вас в поле тупо ВСЕГДА
N символов, типа как 'Y' или 'N' или gender = 'm'/'f' или какой-то
шифр типа штрих-кода, с фиксированным кол-вом знаков, то тогда
грех не использовать CHAR просто потому, что VARCHAR не нужен.

Если мы рассматриваем конкретно MySQL, то тут нужно отметить,
что то, как реально реализуется VARCHAR, зависит целиком от
storage engine. Часто char реализуется внутри как varchar,
просто чтобы не париться с лишним типом данных, так
точно было в SolidDB (мир его праху) и, кажется, так
реализовано в InnoDB.

Подобное может наблюдаться и в других СУБД, поскольку оба типа данных
стандартизированы, и их нужно поддерживать, а внутри представление
обоих типов данных может быть одинаковым (обычно varchar, потому
что у char могут быть накладные расходы при хранении в виде хвостовых
пробелов).
Posted via ActualForum NNTP Server 1.4