Comments 38
Слегка сумбурно и не очень понятно. ИМХО, dev.mysql.com/doc/refman/5.0/en/data-types.html всё же лучше, к тому же описывает все особенности работы с типами.
Полностью с тобой согласен. Сперва мануал! (Увы, многие его толком не читают, потом приходится искать иголку в стоге сена: «Ввели одно, получили другое.»)
У меня была задача сделать программную предпроверку всех сохраняемых данных в базу. Чтобы не получить СЮРПРИЗ при считывании из нее. Поэтому выложил промежуточный вариант описания данных в виде такого массива.
У меня была задача сделать программную предпроверку всех сохраняемых данных в базу. Чтобы не получить СЮРПРИЗ при считывании из нее. Поэтому выложил промежуточный вариант описания данных в виде такого массива.
Такие тонкие вопросы при реальной работе лучше всегда перепроверять в официальной документации: dev.mysql.com/doc/refman/5.0/en/data-types.html
(Это не упрёк автору, это хорошая практика разработки. Хотя с другой стороны, новичок в базах данных, который видит это разнообразие типов впервые, обязан всё равно читать документацию. В общем, не совсем ясно, может ли такая простыня из цифр быть кому-нибудь полезна...)
(Это не упрёк автору, это хорошая практика разработки. Хотя с другой стороны, новичок в базах данных, который видит это разнообразие типов впервые, обязан всё равно читать документацию. В общем, не совсем ясно, может ли такая простыня из цифр быть кому-нибудь полезна...)
Думаю стоит ещё описать разницу типов, которые у вас тут описаны как одинаковые по сути, например decimal, blob/text и тп.
Интересно узнать, кто как хранит дату и время? Поделитесь опытом.
Я как-то увидел, что в CMS MODx дата/время храниться в поле типа INT. Мне понравилось и теперь делаю также ))
Я как-то увидел, что в CMS MODx дата/время храниться в поле типа INT. Мне понравилось и теперь делаю также ))
Очень удобно хранить время в UNIX_TIMESTAMP, быстро, шустро. С диапазонами при хорошей математике вообще нет никаких проблем — делай как хочу и что хочу.
Правда неудобно смотреть на даты типа 1218635068 (кто слёту скажет, что это равно 2008-08-13 13:44:28 [я не ошибся?])
Правда к счастью, МУСКЛ хорошо и быстро справляется, что с полями ДатыВремени что с Числовыми.
Вобщем как вам удобно.
Правда неудобно смотреть на даты типа 1218635068 (кто слёту скажет, что это равно 2008-08-13 13:44:28 [я не ошибся?])
Правда к счастью, МУСКЛ хорошо и быстро справляется, что с полями ДатыВремени что с Числовыми.
Вобщем как вам удобно.
UFO just landed and posted this here
Ну если до 2038 у Вашего приложения дожить перспектив нет, то можно и unix timestamp'ами даты хранить. Вообще же единственные достоинтсва такого способа — экономия места и простота ввода-вывода из базы/в базу (не надо думать про локали, timezone'ы и прочее). Из недостатков — узкий диапазон дат, секундное разрешение (да, у DATETIME в MySQL оно тоже секундное; в других DBMS это может быть и по-другому, как, например, как в PostgreSQL), неудобство работы с датами (типа: составить отчет на понедельник второй недели марта).
UFO just landed and posted this here
Вот не понятно с текстовыми полями. Каким образом там взялись 65537, для записи этого числа, требуется уже не 16 байт, а 17. Что уже не кратно 8, значит не удобно для хранения в памяти.
Ничего не перепутано?
Ничего не перепутано?
Насколько я понял со скупой документации, для поля TEXT длиной 65535, используется 65535 байт на хранение самого текста + 2 байта служебных.
TINETEXT — 1 байт служебный,
в MEDIUMTEXT уже 3 байта.
Для чего и как, затрудняюсь ответить…
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)
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)
а можно вопрос.
буквально вчера читал документацию по типу decimal:
DECIMAL[(M[, D])] пишется что M — количество цифр до запятой, D — количество цифр после запятой.
получается что тип DECIMAL(6,6) должен позволить мне записать в ячейку число типа 123456.123456
но на практике число 123456.123456 превращается в 0.999999
почему такое происходит? скорее всего я что-то делаю не так.
буквально вчера читал документацию по типу 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 — кол-во цифр (max 65 цифр), d — сколько из них могут быть после запятой».
Т.е. M это общее число цифр. А вот сколько из них забрать под десятичную часть.
Т.е. DECIMAL(6,6) из 6ти доступных цифр, все их определил как десятичные.
вопрос снят. виной всему моя невнимательность
DECIMAL[(M[, D])] M — общее количество цифр, D — количество цифр после запятой.
то биш что бы сохранить число 123456.123456 мне нужен тип DECIMAL(12,6)
DECIMAL[(M[, D])] M — общее количество цифр, D — количество цифр после запятой.
то биш что бы сохранить число 123456.123456 мне нужен тип DECIMAL(12,6)
Не могу понять, как этот топик в хабраленту попал
UFO just landed and posted this here
Я вот не понял.
Вы этот массив в скриптах собираетесь использовать? Тогда каким образом? И главное зачем?
А если нет, то зачем в таком виде? Табличкой понятнее было бы.
Вы этот массив в скриптах собираетесь использовать? Тогда каким образом? И главное зачем?
А если нет, то зачем в таком виде? Табличкой понятнее было бы.
К вашему сведению, в пятой версии MySQL varchar может быть и больше 255 символов.
Что я хотел бы увидеть под заголовком «Типы данных в 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
В 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/
очень хороший учебник
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.
Только я бы структурировал по возрастанию информацию о подтипах, в 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 (если это про количество символов) указано верно.
зы: читал по диагонали, так что если что перепутал, извиняйте.
А вот и нет.
Значение byte зависит от кодировки, т. е. для utf-8 будет не 255, а 255 * 3 = 765 байт. И +1 байт, который содержит количество символов (НЕ БАЙТОВ!).
Ну а length (если это про количество символов) указано верно.
зы: читал по диагонали, так что если что перепутал, извиняйте.
О! теперь бы справочник по postgreSQL :)
Sign up to leave a comment.
Типы данных в MySQL (сжатый справочник для PHP программиста)