forum.opennet.ru - "Раздел полезных советов: Рекомендации по оптимальному исполь..." (28)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

"Раздел полезных советов: Рекомендации по оптимальному исполь..."

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Раздел полезных советов: Рекомендации по оптимальному исполь..."	+/–
Сообщение от auto_tips (ok) on 07-Июн-11, 14:10
Материал основан на рекомендациях, данных в книге "MySQL Оптимизация производительности", в которой подробно рассказано почему каждая рекомендация работает так, а не иначе. В заметке лишь приведены ключевые моменты, в стиле "Делайте так!". Все нижесказанное будет относиться к MySQL 5.1 и выше. Движок InnoDB. Для MyISAM также верно почти все нижесказанное. Прежде чем говорить о типах, рекомендация относительно []NULL/ NOT NULL[]. Наличие флага NULL, увеличивает объем данных при хранении на диске. И немного нагружает индексы. Определяйте типы полей как NOT NULL, и указывайте DEFAULT VALUE. Большой выигрыш в производительности это не даст, но как говорится "Копейка рубль бережет". []UUID[] - удалите тире или преобразуйте в 16 байтовые числа UNHEX() и сохранить в столбце BIN(16). Извлекать данные в шестнадцатеричном формате можно с помощью MySQL функции HEX(). []IP[] адреса лучше всего хранить как UNSIGNED INT. И использовать MySQL функции INET_ATON() и INET_NTOA() И так, наиболее часто используются типы int, varchar/char, date/time, enum. ++ Выбор оптимальных типов данных. 1. []INT[] - все понятно, ничего интересного. 2. []CHAR / VARCHAR[] VARCHAR имеет переменную длину в файле. Занимает столько места сколько записано данных. При UPDATE если данных стало больше - выделяется место в другом месте файла. Это создает дополнительную нагрузку и является причиной фрагментации. Используйте VARCHAR если данные обновляются редко, либо используется сложная кодировка, например UTF-8. Идеально для хранения неизменяемых данных. CHAR имеет фиксированную длину в файле. Фрагментация ему не страшна. CHAR полезен когда нужно хранить короткие строки приблизительно одинаковой длинны. Частое обновление не ведет к фрагментации. Идеален для хранение MD5 (CHAR(32)). Старайтесь использовать CHAR, сортировка по такому полю обходится сильно "дешевле". 3. []DATETIME / TIMESTAMP[] - Используйте TIMESTAMP, он занимает на диске меньше места. 4. []ENUM[] При создании таблицы: CREATE TABLE enum_test ( e ENUM('fish','dog','apple') NOT NULL); создается справочник-индекс в *.frm файле. И при последующих INSERT/UPDATE в базу записывается номер(индекс) ENUM поля. INSERT INTO enum_test(e) VALUES ('fish'),('dog'),('apple'); SELECT e + 0 FROM enum_test; вернет 1 3 2 И сортировка происходит (сюрприз) по этим целочисленным значениям :) SELECT e FROM enum_test ORDER BY e; fish apple dog Обойти это неудобство можно используя FIELD(). Не используйте JOIN между CHAR/VARCHAR и ENUM. URL: Обсуждается: http://www.opennet.me/tips/info/2586.shtml
Ответить \| Правка \| Cообщить модератору

Оглавление

Рекомендации по оптимальному использованию типов данных в MySQL, Stax, 14:10 , 07-Июн-11, (1)

Рекомендации по оптимальному использованию типов данных в MySQL, igor, 20:13 , 07-Июн-11, (2)

Рекомендации по оптимальному использованию типов данных в MySQL, Stax, 22:54 , 07-Июн-11, (3) +1

Рекомендации по оптимальному использованию типов данных в MySQL, Анончик, 01:37 , 08-Июн-11, (4)
Рекомендации по оптимальному использованию типов данных в MySQL, ws, 11:18 , 08-Июн-11, (5)

Рекомендации по оптимальному использованию типов данных в MySQL, Dmitry, 13:07 , 09-Июн-11, (9)

Рекомендации по оптимальному использованию типов данных в MySQL, ws, 19:15 , 09-Июн-11, (10)

Рекомендации по оптимальному использованию типов данных в MySQL, Антоним, 00:04 , 19-Июн-11, (22)

Рекомендации по оптимальному использованию типов данных в MySQL, ws, 18:46 , 20-Июн-11, (25)

Рекомендации по оптимальному использованию типов данных в MySQL, Сергей, 03:05 , 17-Июн-11, (15)

Рекомендации по оптимальному использованию типов данных в MySQL, angra, 13:41 , 08-Июн-11, (6)

Рекомендации по оптимальному использованию типов данных в MySQL, zoonman, 20:27 , 08-Июн-11, (8)

Рекомендации по оптимальному использованию типов данных в MySQL, zoonman, 20:25 , 08-Июн-11, (7)
Рекомендации по оптимальному использованию типов данных в MySQL, Alex, 16:13 , 14-Июн-11, (12)

Рекомендации по оптимальному использованию типов данных в MySQL, Stax, 23:29 , 17-Июн-11, (16)

Рекомендации по оптимальному использованию типов данных в MySQL, Axel, 16:46 , 15-Июн-11, (13)

Рекомендации по оптимальному использованию типов данных в MySQL, Stax, 23:34 , 17-Июн-11, (19)

Рекомендации по оптимальному использованию типов данных в MySQL, Сергей, 02:15 , 25-Июн-11, (27)
Рекомендации по оптимальному использованию типов данных в MySQL, Дмитрий, 03:15 , 06-Ноя-15, (28)

Рекомендации по оптимальному использованию типов данных в MySQL, Елка, 21:06 , 13-Июн-11, (11) +1

Рекомендации по оптимальному использованию типов данных в MySQL, Stax, 23:33 , 17-Июн-11, (18)

Рекомендации по оптимальному использованию типов данных в MySQL, Av, 06:05 , 16-Июн-11, (14)

Рекомендации по оптимальному использованию типов данных в MySQL, Stax, 23:31 , 17-Июн-11, (17)

Рекомендации по оптимальному использованию типов данных в MySQL, Сергей, 02:29 , 18-Июн-11, (20)

Рекомендации по оптимальному использованию типов данных в MySQL, Stax, 05:39 , 19-Июн-11, (24)

Рекомендации по оптимальному использованию типов данных в MySQL, COBA, 00:39 , 24-Июн-11, (26)

Рекомендации по оптимальному использованию типов данных в MySQL, Сергей, 02:33 , 18-Июн-11, (21)

Рекомендации по оптимальному использованию типов данных в MySQL, Антоним, 00:06 , 19-Июн-11, (23)

Сообщения по теме [Сортировка по ответам | RSS]

1. "Рекомендации по оптимальному использованию типов данных в MySQL" +/–

Сообщение от Stax (ok) on 07-Июн-11, 14:10

> IP адреса лучше всего хранить как UNSIGNED INT. И использовать MySQL
> функции INET_ATON() и INET_NTOA()
Вот так и делают новые проекты без поддержки IPv6. Зато сэкономили несколько байт, ура!

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Рекомендации по оптимальному использованию типов данных в MySQL" +/–

Сообщение от igor (??) on 07-Июн-11, 20:13

Никто не мешает использовать поля вроде BINARY для хранения 128-битных ipv6 адресов...

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "Рекомендации по оптимальному использованию типов данных в MySQL" +1 +/–

Сообщение от Stax (ok) on 07-Июн-11, 22:54

Мешают неразумные люди, следующие советам, не подумав. Советам вроде этих. И лучше всего не давать таких вот сомнительных советов. Ведь храня IP-адрес как строку достаточной длины, проблемы уровня хранения потом не возникнет.
Это вот тоже из серии "вредные советы"
> 3. DATETIME / TIMESTAMP - Используйте TIMESTAMP, он занимает на диске меньше места.
TIMESTAMP совершенно НЕ предназначен для хранения даты, он предназначен для хранения UPDATED/CREATED.. И не надо его использовать для чего-либо другого. Никогда. Пожалуйста!
Из-за таких советов горе-программисты пишут такой код, который считает, что дату можно класть в TIMESTAMP. Ага, два раза. На андроиде в контакт-листе завести день рождения человека до 1970 года невозможно. Ну не рождались тогда, по мнению гугла! Совершенно реальное поле "день рождения", который оптимизаторы запихнули в аналог TIMESTAMP. Я хоть в IT разбираюсь, мне просто смешно. А вот что далекие от IT люди думают по поводу таких вот ограничений, интересно?..

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "Рекомендации по оптимальному использованию типов данных в MySQL" +/–

Сообщение от Анончик on 08-Июн-11, 01:37

[quote]А вот что далекие от IT люди думают по поводу таких вот ограничений, интересно?..[/quote]
"Ух ты".

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

5. "Рекомендации по оптимальному использованию типов данных в MySQL" +/–

Сообщение от ws (ok) on 08-Июн-11, 11:18

> Мешают неразумные люди, следующие советам, не подумав. Советам вроде этих. И лучше
> всего не давать таких вот сомнительных советов. Ведь храня IP-адрес как
> строку достаточной длины, проблемы уровня хранения потом не возникнет.
Не согласен. Достоинства хранения IP в int более предпочтительные (объем хранимых данных,
скорость выборки). А вот недостаток только тот о котором вы говорите, но это решаемо если разработчик оказался недостаточно предусмотрителен (ALTER TABLE...)
Другими словами вы решаете в ущерб оптимизации возможные перспективы...
Так давайте тогда все данные хранить в строковых типах так проще по вашей логике.

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

6. "Рекомендации по оптимальному использованию типов данных в MySQL" +/–

Сообщение от angra (ok) on 08-Июн-11, 13:41

>Ведь храня IP-адрес как строку достаточной длины, проблемы уровня хранения потом не возникнет.
И что будет достаточной длиной? Предусмотреть разную длину CHAR для IPv4 и IPv6 абсолютно то же самое, что и предусмотреть правильный размер INT для них же. А если писать с расчетом на светлое будущее, то вообще все нужно в TEXT хранить, вот только в суровом настоящем такой проект жрать место, работать будет как черепаха и до светлого будущего не доживет. Кстати как вы собираетесь сортировать или искать диапазоны IP в текстовом виде да еще сразу с учетом разного представления v6 и v4?

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

7. "Рекомендации по оптимальному использованию типов данных в MySQL" +/–

Сообщение от zoonman (ok) on 08-Июн-11, 20:25

Дополню немного:
The TIMESTAMP data type has a range of '1970-01-01 00:00:01' UTC to '2038-01-19 03:14:07' UTC.
The DATETIME type is used when you need values that contain both date and time information. MySQL retrieves and displays DATETIME values in 'YYYY-MM-DD HH:MM:SS' format. The supported range is '1000-01-01 00:00:00' to '9999-12-31 23:59:59'.
RTFM http://dev.mysql.com/doc/refman/5.5/en/datetime.html

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

8. "Рекомендации по оптимальному использованию типов данных в MySQL" +/–

Сообщение от zoonman (ok) on 08-Июн-11, 20:27

Плохо, что нет просто UDF типа данных IP-address. А уж там он хоть IPv8...

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

9. "Рекомендации по оптимальному использованию типов данных в MySQL" +/–

Сообщение от Dmitry (??) on 09-Июн-11, 13:07

Достоинства хранения (да и вообще представления)ip в int более, чем просто сомнительны. Большинство программ ждут, что ip им будет передан как текстовый тип, некоторые готовы принять 4 бинарных октета, int для ip - экзотика. Да и по здравому размышлению не является он таким типом. Не умножайте сущности.

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

10. "Рекомендации по оптимальному использованию типов данных в MySQL" +/–

Сообщение от ws (ok) on 09-Июн-11, 19:15

> Достоинства хранения (да и вообще представления)ip в int более, чем просто сомнительны.
> Большинство программ ждут, что ip им будет передан как текстовый тип,
> некоторые готовы принять 4 бинарных октета, int для ip - экзотика.
> Да и по здравому размышлению не является он таким типом. Не
> умножайте сущности.
А вы не интересовались как сетевой стек ОС оперирует IP чтобы так утверждать? Да да! Использует все те же целые числа. Так кто плодит сущности?
IP как мы привыкли видеть нужен только для человека - для удобства использования.
Для тех программ (и людей тоже), которые хотят видеть в удобном представлении IP и были придуманы функции INET_ATON(), INET_NTOA() http://dev.mysql.com/doc/refman/5.5/en/miscellaneous-functio...

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

11. "Рекомендации по оптимальному использованию типов данных в MySQL" +1 +/–

Сообщение от Елка on 13-Июн-11, 21:06

ip только в int!
вы пробывали учитывать трафик по подсетям? ;)
в строковом варианте это изврат

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

12. "Рекомендации по оптимальному использованию типов данных в MySQL" +/–

Сообщение от Alex (??) on 14-Июн-11, 16:13

>На андроиде в контакт-листе завести день рождения человека до 1970 года невозможно.
Уточните какая версия андроида, т.к. на 2.2.1 вполне нормально заносятся в диапазоне от 1902 до 2036

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

13. "Рекомендации по оптимальному использованию типов данных в MySQL" +/–

Сообщение от Axel (??) on 15-Июн-11, 16:46

Берём signed int и вполне себе записываем даты < 1.1.1970 как отрицательные числа.

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

14. "Рекомендации по оптимальному использованию типов данных в MySQL" +/–

Сообщение от Av (??) on 16-Июн-11, 06:05

эй, чудик, что хранит ip в char, отсортируй-ка их по возрастанию..

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

15. "Рекомендации по оптимальному использованию типов данных в MySQL" +/–

Сообщение от Сергей (??) on 17-Июн-11, 03:05

Сразу видно что не писали ничего серьезного с IP :) Еще одно преимущество это возможность быстрой выборки диапазона, например какие IP входят в определенную подсеть или в определенный диапазон. Делать INET_ATON на каждом поле при выборках хорошо? Мало того я даже MAC-адреса храню в виде INT64 и тоже только из за возможности выбирать диапазоны!
А насчет v6 можно вобще использовать префикс + последние 4 октета в виде того же INT!

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

16. "Рекомендации по оптимальному использованию типов данных в MySQL" +/–

Сообщение от Stax (ok) on 17-Июн-11, 23:29

2.2.2
Из LG Optimus 2x.

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

17. "Рекомендации по оптимальному использованию типов данных в MySQL" +/–

Сообщение от Stax (ok) on 17-Июн-11, 23:31

> эй, чудик, что хранит ip в char, отсортируй-ка их по возрастанию..
А зачем, простите? Сходу даже задач не приходит в голову, где нужно сортировать по IP o.O Поиск по IP, еще понимаю..

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

18. "Рекомендации по оптимальному использованию типов данных в MySQL" +/–

Сообщение от Stax (ok) on 17-Июн-11, 23:33

> ip только в int!
> вы пробывали учитывать трафик по подсетям? ;)
> в строковом варианте это изврат
Ну, под специфические задачи можно использовать разные способы хранения. Если у вас IP используется для подсчета трафика, храните в INT, никто не запрещает :)
Некоторые еще хранят в виде "C0A80201" в CHAR(8) - для удобства специфических действий.
Но под общую задачу хранения IP-адреса какого-нибудь ресурса, смысла запихивать в INT особо и нет.

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

19. "Рекомендации по оптимальному использованию типов данных в MySQL" +/–

Сообщение от Stax (ok) on 17-Июн-11, 23:34

> Берём signed int и вполне себе записываем даты < 1.1.1970 как отрицательные
> числа.
Не шутите так :) Во-первых, нестандартно, во-вторых, ну выйграете несколько десятилетий - но даты и до этой бывают.

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

20. "Рекомендации по оптимальному использованию типов данных в MySQL" +/–

Сообщение от Сергей (??) on 18-Июн-11, 02:29

Взять максимальный IP по выборке например:
SELECT * FROM table WHERE expr... ORDER BY int_ip DESC LIMIT 1;
в вашем случае при хранении в char это:
SELECT * FROM table WHERE expr... ORDER BY INET_ATON(char_ip) DESC LIMIT 1;
что соответственно overhead

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

21. "Рекомендации по оптимальному использованию типов данных в MySQL" +/–

Сообщение от Сергей (??) on 18-Июн-11, 02:33

>> эй, чудик, что хранит ip в char, отсортируй-ка их по возрастанию..
> А зачем, простите? Сходу даже задач не приходит в голову, где нужно
> сортировать по IP o.O Поиск по IP, еще понимаю..
Еще более экзотический вариант, в БД храним список подсетей в виде int - IP адрес сети, в виде int - маску сети. Задача проверки в какие из сети входит определенный IP. Вот тут уже получите более серъезный оверхед если будете хранить в char.

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

22. "Рекомендации по оптимальному использованию типов данных в MySQL" +/–

Сообщение от Антоним on 19-Июн-11, 00:04

Что вы чушь несёте. Стек использует бинарные строки, но никак не ЗНАКОВЫЕ целые

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

23. "Рекомендации по оптимальному использованию типов данных в MySQL" +/–

Сообщение от Антоним on 19-Июн-11, 00:06

> эй, чудик, что хранит ip в char, отсортируй-ка их по возрастанию..
легко, если хранить в HEX. Там же можно делать и выборкии по диапазонам.

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

24. "Рекомендации по оптимальному использованию типов данных в MySQL" +/–

Сообщение от Stax (ok) on 19-Июн-11, 05:39

Я не понимаю, что такое "максимальный IP". IP это просто адрес, из четырех чисел, если ipv4. Как вы у адреса определяете, какой больше и какой меньше? И главное, зачем?
А для IPv6 вы считаете, что ipv6-in-ipv4 сегмент 2002:: это "больше" и лучше, чем нативные 2001:: адреса? Примерно такая логика?

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

25. "Рекомендации по оптимальному использованию типов данных в MySQL" +/–

Сообщение от ws (ok) on 20-Июн-11, 18:46

> Что вы чушь несёте. Стек использует бинарные строки, но никак не ЗНАКОВЫЕ
> целые
За знаковые я ничего не говорил, а говорил за целы числа! Для вас есть замечательная команда для посвящения:
man inet_pton
И вот цитата из него:
"
AF_INET
              src points to a character string containing an IPv4 network address in dotted-decimal format, "ddd.ddd.ddd.ddd", where  ddd  is  a  decimal
              number  of  up  to  three  digits  in  the  range  0 to 255.  The address is converted to a struct in_addr and copied to dst, which must be
              sizeof(struct in_addr) (4) bytes (32 bits) long.
"
Думаю сами переведете...

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

26. "Рекомендации по оптимальному использованию типов данных в MySQL" +/–

Сообщение от COBA on 24-Июн-11, 00:39

А зачем? а чтобы выдать допустим следующий ip клиенту. Это довольно частая операция для провайдеров.

Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

27. "Рекомендации по оптимальному использованию типов данных в MySQL" +/–

Сообщение от Сергей (??) on 25-Июн-11, 02:15

Не все пишут программы для работы в Интернет. Есть программы сбора данных для локальных сетей. Использовать IPv6 в этом случае неразумно, а тратить +12 байт впустую просто глупо - будет БД из одних IP.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

28. "Рекомендации по оптимальному использованию типов данных в MySQL" +/–

Сообщение от Дмитрий (??) on 06-Ноя-15, 03:15

Вот кстати IPv6 хранить в BINARY(16), есть специальные функции для работы с ними
https://intsystem.org/coding/kak-rabotat-s-ipv6-v-php/
INET6_ATON(expr) и INET6_NTOA(expr), но они доступны с версии MySQL 5.6.3. До этой версии есть специальное расширение.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру


	1. "Рекомендации по оптимальному использованию типов данных в MySQL"	+/–
	Сообщение от Stax (ok) on 07-Июн-11, 14:10
	> IP адреса лучше всего хранить как UNSIGNED INT. И использовать MySQL > функции INET_ATON() и INET_NTOA() Вот так и делают новые проекты без поддержки IPv6. Зато сэкономили несколько байт, ура!
	Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	2. "Рекомендации по оптимальному использованию типов данных в MySQL"	+/–
	Сообщение от igor (??) on 07-Июн-11, 20:13
	Никто не мешает использовать поля вроде BINARY для хранения 128-битных ipv6 адресов...
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	3. "Рекомендации по оптимальному использованию типов данных в MySQL"	+1 +/–
	Сообщение от Stax (ok) on 07-Июн-11, 22:54
	Мешают неразумные люди, следующие советам, не подумав. Советам вроде этих. И лучше всего не давать таких вот сомнительных советов. Ведь храня IP-адрес как строку достаточной длины, проблемы уровня хранения потом не возникнет. Это вот тоже из серии "вредные советы" > 3. DATETIME / TIMESTAMP - Используйте TIMESTAMP, он занимает на диске меньше места. TIMESTAMP совершенно НЕ предназначен для хранения даты, он предназначен для хранения UPDATED/CREATED.. И не надо его использовать для чего-либо другого. Никогда. Пожалуйста! Из-за таких советов горе-программисты пишут такой код, который считает, что дату можно класть в TIMESTAMP. Ага, два раза. На андроиде в контакт-листе завести день рождения человека до 1970 года невозможно. Ну не рождались тогда, по мнению гугла! Совершенно реальное поле "день рождения", который оптимизаторы запихнули в аналог TIMESTAMP. Я хоть в IT разбираюсь, мне просто смешно. А вот что далекие от IT люди думают по поводу таких вот ограничений, интересно?..
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору


	4. "Рекомендации по оптимальному использованию типов данных в MySQL"	+/–
	Сообщение от Анончик on 08-Июн-11, 01:37
	[quote]А вот что далекие от IT люди думают по поводу таких вот ограничений, интересно?..[/quote] "Ух ты".
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	5. "Рекомендации по оптимальному использованию типов данных в MySQL"	+/–
	Сообщение от ws (ok) on 08-Июн-11, 11:18
	> Мешают неразумные люди, следующие советам, не подумав. Советам вроде этих. И лучше > всего не давать таких вот сомнительных советов. Ведь храня IP-адрес как > строку достаточной длины, проблемы уровня хранения потом не возникнет. Не согласен. Достоинства хранения IP в int более предпочтительные (объем хранимых данных, скорость выборки). А вот недостаток только тот о котором вы говорите, но это решаемо если разработчик оказался недостаточно предусмотрителен (ALTER TABLE...) Другими словами вы решаете в ущерб оптимизации возможные перспективы... Так давайте тогда все данные хранить в строковых типах так проще по вашей логике.
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	6. "Рекомендации по оптимальному использованию типов данных в MySQL"	+/–
	Сообщение от angra (ok) on 08-Июн-11, 13:41
	>Ведь храня IP-адрес как строку достаточной длины, проблемы уровня хранения потом не возникнет. И что будет достаточной длиной? Предусмотреть разную длину CHAR для IPv4 и IPv6 абсолютно то же самое, что и предусмотреть правильный размер INT для них же. А если писать с расчетом на светлое будущее, то вообще все нужно в TEXT хранить, вот только в суровом настоящем такой проект жрать место, работать будет как черепаха и до светлого будущего не доживет. Кстати как вы собираетесь сортировать или искать диапазоны IP в текстовом виде да еще сразу с учетом разного представления v6 и v4?
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	7. "Рекомендации по оптимальному использованию типов данных в MySQL"	+/–
	Сообщение от zoonman (ok) on 08-Июн-11, 20:25
	Дополню немного: The TIMESTAMP data type has a range of '1970-01-01 00:00:01' UTC to '2038-01-19 03:14:07' UTC. The DATETIME type is used when you need values that contain both date and time information. MySQL retrieves and displays DATETIME values in 'YYYY-MM-DD HH:MM:SS' format. The supported range is '1000-01-01 00:00:00' to '9999-12-31 23:59:59'. RTFM http://dev.mysql.com/doc/refman/5.5/en/datetime.html
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	8. "Рекомендации по оптимальному использованию типов данных в MySQL"	+/–
	Сообщение от zoonman (ok) on 08-Июн-11, 20:27
	Плохо, что нет просто UDF типа данных IP-address. А уж там он хоть IPv8...
	Ответить \| Правка \| ^ к родителю #6 \| Наверх \| Cообщить модератору


	9. "Рекомендации по оптимальному использованию типов данных в MySQL"	+/–
	Сообщение от Dmitry (??) on 09-Июн-11, 13:07
	Достоинства хранения (да и вообще представления)ip в int более, чем просто сомнительны. Большинство программ ждут, что ip им будет передан как текстовый тип, некоторые готовы принять 4 бинарных октета, int для ip - экзотика. Да и по здравому размышлению не является он таким типом. Не умножайте сущности.
	Ответить \| Правка \| ^ к родителю #5 \| Наверх \| Cообщить модератору


	10. "Рекомендации по оптимальному использованию типов данных в MySQL"	+/–
	Сообщение от ws (ok) on 09-Июн-11, 19:15
	> Достоинства хранения (да и вообще представления)ip в int более, чем просто сомнительны. > Большинство программ ждут, что ip им будет передан как текстовый тип, > некоторые готовы принять 4 бинарных октета, int для ip - экзотика. > Да и по здравому размышлению не является он таким типом. Не > умножайте сущности. А вы не интересовались как сетевой стек ОС оперирует IP чтобы так утверждать? Да да! Использует все те же целые числа. Так кто плодит сущности? IP как мы привыкли видеть нужен только для человека - для удобства использования. Для тех программ (и людей тоже), которые хотят видеть в удобном представлении IP и были придуманы функции INET_ATON(), INET_NTOA() http://dev.mysql.com/doc/refman/5.5/en/miscellaneous-functio...
	Ответить \| Правка \| ^ к родителю #9 \| Наверх \| Cообщить модератору


	11. "Рекомендации по оптимальному использованию типов данных в MySQL"	+1 +/–
	Сообщение от Елка on 13-Июн-11, 21:06
	ip только в int! вы пробывали учитывать трафик по подсетям? ;) в строковом варианте это изврат
	Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	12. "Рекомендации по оптимальному использованию типов данных в MySQL"	+/–
	Сообщение от Alex (??) on 14-Июн-11, 16:13
	>На андроиде в контакт-листе завести день рождения человека до 1970 года невозможно. Уточните какая версия андроида, т.к. на 2.2.1 вполне нормально заносятся в диапазоне от 1902 до 2036
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	13. "Рекомендации по оптимальному использованию типов данных в MySQL"	+/–
	Сообщение от Axel (??) on 15-Июн-11, 16:46
	Берём signed int и вполне себе записываем даты < 1.1.1970 как отрицательные числа.
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	14. "Рекомендации по оптимальному использованию типов данных в MySQL"	+/–
	Сообщение от Av (??) on 16-Июн-11, 06:05
	эй, чудик, что хранит ip в char, отсортируй-ка их по возрастанию..
	Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	15. "Рекомендации по оптимальному использованию типов данных в MySQL"	+/–
	Сообщение от Сергей (??) on 17-Июн-11, 03:05
	Сразу видно что не писали ничего серьезного с IP :) Еще одно преимущество это возможность быстрой выборки диапазона, например какие IP входят в определенную подсеть или в определенный диапазон. Делать INET_ATON на каждом поле при выборках хорошо? Мало того я даже MAC-адреса храню в виде INT64 и тоже только из за возможности выбирать диапазоны! А насчет v6 можно вобще использовать префикс + последние 4 октета в виде того же INT!
	Ответить \| Правка \| ^ к родителю #9 \| Наверх \| Cообщить модератору


	16. "Рекомендации по оптимальному использованию типов данных в MySQL"	+/–
	Сообщение от Stax (ok) on 17-Июн-11, 23:29
	2.2.2 Из LG Optimus 2x.
	Ответить \| Правка \| ^ к родителю #12 \| Наверх \| Cообщить модератору


	17. "Рекомендации по оптимальному использованию типов данных в MySQL"	+/–
	Сообщение от Stax (ok) on 17-Июн-11, 23:31
	> эй, чудик, что хранит ip в char, отсортируй-ка их по возрастанию.. А зачем, простите? Сходу даже задач не приходит в голову, где нужно сортировать по IP o.O Поиск по IP, еще понимаю..
	Ответить \| Правка \| ^ к родителю #14 \| Наверх \| Cообщить модератору


	18. "Рекомендации по оптимальному использованию типов данных в MySQL"	+/–
	Сообщение от Stax (ok) on 17-Июн-11, 23:33
	> ip только в int! > вы пробывали учитывать трафик по подсетям? ;) > в строковом варианте это изврат Ну, под специфические задачи можно использовать разные способы хранения. Если у вас IP используется для подсчета трафика, храните в INT, никто не запрещает :) Некоторые еще хранят в виде "C0A80201" в CHAR(8) - для удобства специфических действий. Но под общую задачу хранения IP-адреса какого-нибудь ресурса, смысла запихивать в INT особо и нет.
	Ответить \| Правка \| ^ к родителю #11 \| Наверх \| Cообщить модератору


	19. "Рекомендации по оптимальному использованию типов данных в MySQL"	+/–
	Сообщение от Stax (ok) on 17-Июн-11, 23:34
	> Берём signed int и вполне себе записываем даты < 1.1.1970 как отрицательные > числа. Не шутите так :) Во-первых, нестандартно, во-вторых, ну выйграете несколько десятилетий - но даты и до этой бывают.
	Ответить \| Правка \| ^ к родителю #13 \| Наверх \| Cообщить модератору


	20. "Рекомендации по оптимальному использованию типов данных в MySQL"	+/–
	Сообщение от Сергей (??) on 18-Июн-11, 02:29
	Взять максимальный IP по выборке например: SELECT * FROM table WHERE expr... ORDER BY int_ip DESC LIMIT 1; в вашем случае при хранении в char это: SELECT * FROM table WHERE expr... ORDER BY INET_ATON(char_ip) DESC LIMIT 1; что соответственно overhead
	Ответить \| Правка \| ^ к родителю #17 \| Наверх \| Cообщить модератору


	21. "Рекомендации по оптимальному использованию типов данных в MySQL"	+/–
	Сообщение от Сергей (??) on 18-Июн-11, 02:33
	>> эй, чудик, что хранит ip в char, отсортируй-ка их по возрастанию.. > А зачем, простите? Сходу даже задач не приходит в голову, где нужно > сортировать по IP o.O Поиск по IP, еще понимаю.. Еще более экзотический вариант, в БД храним список подсетей в виде int - IP адрес сети, в виде int - маску сети. Задача проверки в какие из сети входит определенный IP. Вот тут уже получите более серъезный оверхед если будете хранить в char.
	Ответить \| Правка \| ^ к родителю #17 \| Наверх \| Cообщить модератору


	22. "Рекомендации по оптимальному использованию типов данных в MySQL"	+/–
	Сообщение от Антоним on 19-Июн-11, 00:04
	Что вы чушь несёте. Стек использует бинарные строки, но никак не ЗНАКОВЫЕ целые
	Ответить \| Правка \| ^ к родителю #10 \| Наверх \| Cообщить модератору


	23. "Рекомендации по оптимальному использованию типов данных в MySQL"	+/–
	Сообщение от Антоним on 19-Июн-11, 00:06
	> эй, чудик, что хранит ip в char, отсортируй-ка их по возрастанию.. легко, если хранить в HEX. Там же можно делать и выборкии по диапазонам.
	Ответить \| Правка \| ^ к родителю #14 \| Наверх \| Cообщить модератору


	24. "Рекомендации по оптимальному использованию типов данных в MySQL"	+/–
	Сообщение от Stax (ok) on 19-Июн-11, 05:39
	Я не понимаю, что такое "максимальный IP". IP это просто адрес, из четырех чисел, если ipv4. Как вы у адреса определяете, какой больше и какой меньше? И главное, зачем? А для IPv6 вы считаете, что ipv6-in-ipv4 сегмент 2002:: это "больше" и лучше, чем нативные 2001:: адреса? Примерно такая логика?
	Ответить \| Правка \| ^ к родителю #20 \| Наверх \| Cообщить модератору


	25. "Рекомендации по оптимальному использованию типов данных в MySQL"	+/–
	Сообщение от ws (ok) on 20-Июн-11, 18:46
	> Что вы чушь несёте. Стек использует бинарные строки, но никак не ЗНАКОВЫЕ > целые За знаковые я ничего не говорил, а говорил за целы числа! Для вас есть замечательная команда для посвящения: man inet_pton И вот цитата из него: " AF_INET src points to a character string containing an IPv4 network address in dotted-decimal format, "ddd.ddd.ddd.ddd", where ddd is a decimal number of up to three digits in the range 0 to 255. The address is converted to a struct in_addr and copied to dst, which must be sizeof(struct in_addr) (4) bytes (32 bits) long. " Думаю сами переведете...
	Ответить \| Правка \| ^ к родителю #22 \| Наверх \| Cообщить модератору


	26. "Рекомендации по оптимальному использованию типов данных в MySQL"	+/–
	Сообщение от COBA on 24-Июн-11, 00:39
	А зачем? а чтобы выдать допустим следующий ip клиенту. Это довольно частая операция для провайдеров.
	Ответить \| Правка \| ^ к родителю #24 \| Наверх \| Cообщить модератору


	27. "Рекомендации по оптимальному использованию типов данных в MySQL"	+/–
	Сообщение от Сергей (??) on 25-Июн-11, 02:15
	Не все пишут программы для работы в Интернет. Есть программы сбора данных для локальных сетей. Использовать IPv6 в этом случае неразумно, а тратить +12 байт впустую просто глупо - будет БД из одних IP.
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	28. "Рекомендации по оптимальному использованию типов данных в MySQL"	+/–
	Сообщение от Дмитрий (??) on 06-Ноя-15, 03:15
	Вот кстати IPv6 хранить в BINARY(16), есть специальные функции для работы с ними https://intsystem.org/coding/kak-rabotat-s-ipv6-v-php/ INET6_ATON(expr) и INET6_NTOA(expr), но они доступны с версии MySQL 5.6.3. До этой версии есть специальное расширение.
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору