Comments 38
Полностью с тобой согласен. Сперва мануал! (Увы, многие его толком не читают, потом приходится искать иголку в стоге сена: «Ввели одно, получили другое.»)

У меня была задача сделать программную предпроверку всех сохраняемых данных в базу. Чтобы не получить СЮРПРИЗ при считывании из нее. Поэтому выложил промежуточный вариант описания данных в виде такого массива.
Такие тонкие вопросы при реальной работе лучше всегда перепроверять в официальной документации: dev.mysql.com/doc/refman/5.0/en/data-types.html

(Это не упрёк автору, это хорошая практика разработки. Хотя с другой стороны, новичок в базах данных, который видит это разнообразие типов впервые, обязан всё равно читать документацию. В общем, не совсем ясно, может ли такая простыня из цифр быть кому-нибудь полезна...)
Считаю, что может быть полезной для машинной обработки сохраняемых данных.
Думаю стоит ещё описать разницу типов, которые у вас тут описаны как одинаковые по сути, например decimal, blob/text и тп.
К сожалению, эту тему в данный момент нет времени раскрыть. Но как подвернется свободная минута — обязательно.
Интересно узнать, кто как хранит дату и время? Поделитесь опытом.
Я как-то увидел, что в CMS MODx дата/время храниться в поле типа INT. Мне понравилось и теперь делаю также ))
Очень удобно хранить время в UNIX_TIMESTAMP, быстро, шустро. С диапазонами при хорошей математике вообще нет никаких проблем — делай как хочу и что хочу.

Правда неудобно смотреть на даты типа 1218635068 (кто слёту скажет, что это равно 2008-08-13 13:44:28 [я не ошибся?])

Правда к счастью, МУСКЛ хорошо и быстро справляется, что с полями ДатыВремени что с Числовыми.

Вобщем как вам удобно.
UFO landed and left these words here
Ну если до 2038 у Вашего приложения дожить перспектив нет, то можно и unix timestamp'ами даты хранить. Вообще же единственные достоинтсва такого способа — экономия места и простота ввода-вывода из базы/в базу (не надо думать про локали, timezone'ы и прочее). Из недостатков — узкий диапазон дат, секундное разрешение (да, у DATETIME в MySQL оно тоже секундное; в других DBMS это может быть и по-другому, как, например, как в PostgreSQL), неудобство работы с датами (типа: составить отчет на понедельник второй недели марта).
UFO landed and left these words here
Вот не понятно с текстовыми полями. Каким образом там взялись 65537, для записи этого числа, требуется уже не 16 байт, а 17. Что уже не кратно 8, значит не удобно для хранения в памяти.
Ничего не перепутано?
Насколько я понял со скупой документации, для поля TEXT длиной 65535, используется 65535 байт на хранение самого текста + 2 байта служебных.

TINETEXT — 1 байт служебный,
в MEDIUMTEXT уже 3 байта.

Для чего и как, затрудняюсь ответить…
TINETEXT может быть длиной до 255 байт; для хранения самой длины достаточно одного беззнакового байта (0-255); суммарная длина 255 + 1 = 256.

MEDIUMTEXT может быть длиной до 16777215 = 2^24-1; для хранения длины достаточно трёх байт без знака; суммарная длина 16777215 + 3 = 16777218. А у вас 16777219. Откуда взяли цифру?

Кстати, я же говорил что нужно читать документацию, верно? Тут ведь всё написано dev.mysql.com/doc/refman/5.0/en/storage-requirements.html (первый абзац после таблицы Storage Requirements for String Types)
Да очень просто у меня получилось: 5 + 3 = 9 (Как будто и в моем калькуляторе дырочку просверлить нельзя :) ).

Спасибо, ошибку исправил. И запомнил что 5 + 3 = 8 )))
а можно вопрос.
буквально вчера читал документацию по типу decimal:
DECIMAL[(M[, D])] пишется что M — количество цифр до запятой, D — количество цифр после запятой.

получается что тип DECIMAL(6,6) должен позволить мне записать в ячейку число типа 123456.123456
но на практике число 123456.123456 превращается в 0.999999

почему такое происходит? скорее всего я что-то делаю не так.

В тексте могли взглядом не заметить.

Цитата из текста:
«DECIMAL(M, D) m — кол-во цифр (max 65 цифр), d — сколько из них могут быть после запятой».

Т.е. M это общее число цифр. А вот сколько из них забрать под десятичную часть.

Т.е. DECIMAL(6,6) из 6ти доступных цифр, все их определил как десятичные.
вопрос снят. виной всему моя невнимательность

DECIMAL[(M[, D])] M — общее количество цифр, D — количество цифр после запятой.
то биш что бы сохранить число 123456.123456 мне нужен тип DECIMAL(12,6)
Давим на большинство.

Боюсь ошибиться, но по-моему здесь каждый второй знает и работает на PHP и MySQL.
Даже если так, то и этот народ ничего нового не почерпнет из статью: эта информация в более удобоваримой форме доступна на mysql.com
UFO landed and left these words here
Я вот не понял.
Вы этот массив в скриптах собираетесь использовать? Тогда каким образом? И главное зачем?
А если нет, то зачем в таком виде? Табличкой понятнее было бы.
Я че-то тоже не врубился… Автор, кстати, пробовал вообще в PHP писать 'umax'=>4294967295, не говоря уже про 'max'=>9223372036854775807?
Эти числа идут через обертку классов (В коде они просто убраны).

Для себя, если надо использовать (в хелпере например), возмите эти числа в кавычках и используйте. )
К вашему сведению, в пятой версии MySQL varchar может быть и больше 255 символов.
Да есть такая информация, но насколько я помню это начинается с какойто версии 5.0.XXX,
т.к. в 5.0.1 этого еще не было.
*какой-то

Посмотрел в мануале с версии 5.0.3 начинается.
Что я хотел бы увидеть под заголовком «Типы данных в MySQL (сжатый справочник для PHP программиста)»?

В MySQL есть довольно много разнообразных типов данных, причём многие из них ещё могут быть записаны под разными именами (из соображений совместимости) и иметь множество несущественных опций. На практике вам почти никогда не потребуется тщательно раздумывать над особенностями реализации, например, различных строковых типов; поэтому дальше — краткий перечень самых базовых сведений, которые вам действительно понадобятся.

Целые числа — integer.
Вещественные числа — double.
Булевы значения — bool (принимают значения true и false; или 1 и 0).
Перечисления — enum('male', 'female').
Строковые значения — varchar(L), если L (максимальная длина) меньше 65536, или text(L) в ином случае.
Бинарные данные — blob(L), где L — максимальный размер.
Дата и время — datetime.

Остальное обычно не требуется, однако при необходимости вы всегда можете прочесть dev.mysql.com/doc/refman/5.0/en/data-types.html
дополню ссылочкой в тему:
очень хороший учебник
newcontinent.ru/h/mysqlc/
Автору большое спасибо. С массивом идея хорошая — доходчиво и понятно ))

Только я бы структурировал по возрастанию информацию о подтипах, в TEXT и INT особенно, так тконечно разобраться можно, но при расположении по возрастанию еще и зрительно бы запоминалось лучше.

И насчет VARCHAR уточнение, из мануала собственно: «The length can be specified as a value from 0 to 255 before MySQL 5.0.3, and 0 to 65,535 in 5.0.3 and later versions.» — начиная с версии 5.0.3 уже не 0-255, а 0- 65,535.
Как главный редактор русскоязычного перевода доки на MySQL, я рекомендую в него не заглядывать — он уже сказочно морально устарел.
Строка для примера: 'char'=>Array('byte'=>256, 'min_byte'=>2, 'length'=>255)

А вот и нет.
Значение byte зависит от кодировки, т. е. для utf-8 будет не 255, а 255 * 3 = 765 байт. И +1 байт, который содержит количество символов (НЕ БАЙТОВ!).

Ну а length (если это про количество символов) указано верно.

зы: читал по диагонали, так что если что перепутал, извиняйте.
Only those users with full accounts are able to leave comments. Log in, please.