The OpenNET Project: Рекомендації щодо раціонального використання типів даних в MySQL

/ - > IP адреси найкраще зберігати як UNSIGNED INT. І використовувати MySQL
> Функції INET_ATON () і INET_NTOA ()

Ось так і роблять нові проекти без підтримки IPv6. Зате заощадили кілька байт, ура!

• 2.2 , igor (??), 20:13, 07/06/2011 [ ^ ] [ ^^ ] [ ^^^ ] [ відповісти ]

/ - Ніхто не заважає використовувати поля на зразок BINARY для зберігання 128-бітних ipv6 адрес ...

• 3.3 , Stax (Ok), 22:54 07/06/2011 [ ^ ] [ ^^ ] [ ^^^ ] [ відповісти ]

+1 + / - Заважають нерозумні люди, такі радам, не подумавши. Радам на кшталт цих. І краще за все не давати таких ось сумнівних рад. Адже зберігаючи IP-адреса як рядок достатньої довжини, проблеми рівня зберігання потім не виникне.

Це ось теж із серії "шкідливі поради"
> 3. DATETIME / TIMESTAMP - Використовуйте TIMESTAMP, він займає на диску менше місця.

TIMESTAMP абсолютно НЕ призначений для зберігання дати, він призначений для зберігання UPDATED / CREATED .. І не треба його використовувати для чого-небудь іншого. Ніколи. Будь ласка!

Через таких рад горе-програмісти пишуть такий код, який вважає, що дату можна класти в TIMESTAMP. Ага, два рази. На андроїд в контакт-листі завести день народження людини до 1970 року неможливо. Ну не народжувалися тоді, на думку гугла! Абсолютно реальне поле "день народження", який оптимізатори запхали в аналог TIMESTAMP. Я хоч в IT розбираюся, мені просто смішно. А ось що далекі від IT люди думають з приводу таких ось обмежень, цікаво? ..

• 4.4 , Анончік (?), 1:37, 08/06/2011 [ ^ ] [ ^^ ] [ ^^^ ] [ відповісти ]

/ - [Quote] А ось що далекі від IT люди думають з приводу таких ось обмежень, цікаво? .. [/ quote]
"Ух ти".

• 4.5 , ws (Ok), 11:18 08/06/2011 [ ^ ] [ ^^ ] [ ^^^ ] [ відповісти ]

/ - > Заважають нерозумні люди, такі радам, не подумавши. Радам на кшталт цих. І краще
> За все не давати таких ось сумнівних рад. Адже зберігаючи IP-адреса як
> Рядок достатньої довжини, проблеми рівня зберігання потім не виникне.

Не згоден. Переваги зберігання IP в int більш бажані (обсяг збережених даних,
швидкість вибірки). А ось недолік тільки той про який ви говорите, але це можна вирішити якщо розробник виявився недостатньо передбачливий (ALTER TABLE ...)
Іншими словами ви вирішуєте на шкоду оптимізації можливі перспективи ...
Так давайте тоді всі дані зберігати в строкових типах так простіше за вашою логікою.

• 6.10 , ws (Ok), 19:15, 09/06/2011 [ ^ ] [ ^^ ] [ ^^^ ] [ відповісти ]

/ - > Переваги зберігання (та й взагалі уявлення) ip в int більш, ніж просто сумнівні.
> Більшість програм чекають, що ip їм буде переданий як текстовий тип,
> Деякі готові прийняти 4 бінарних октету, int для ip - екзотика.
> Та й за здоровим глуздом не є він таким типом. Чи не
> Множте суті.

А ви не цікавилися як мережевий стек ОС оперує IP щоб так стверджувати? Так Так! Використовує всі ті ж цілі числа. Так хто плодить суті?
IP як ми звикли бачити потрібен тільки для людини - для зручності використання.

Для тих програм (і людей теж), які хочуть бачити в зручному поданні IP і були придумані функції INET_ATON (), INET_NTOA () http://dev.mysql.com/doc/refman/5.5/en/miscellaneous-functions.html#function_

• 7.22 , антонім (?), 00:04, 19/06/2011 [ ^ ] [ ^^ ] [ ^^^ ] [ відповісти ]

/ - Що ви нісенітниця несете. Стек використовує бінарні рядки, але ніяк не ЗНАКОВІ цілі

• 6.15 , Сергій (??), 3:05, 17/06/2011 [ ^ ] [ ^^ ] [ ^^^ ] [ відповісти ]

/ - Відразу видно що не писали нічого серйозного з IP :) Ще одна перевага це можливість швидкої вибірки діапазону, наприклад які IP входять в певну підмережа або в певний діапазон. Робити INET_ATON на кожному полі при вибірках добре? Мало того я навіть MAC-адреси зберігаю у вигляді INT64 і теж тільки через можливості вибирати діапазони!
А щодо v6 можна вобще використовувати префікс + останні 4 октету у вигляді того ж INT!

• 4.6 , angra (Ok), 13:41, 08/06/2011 [ ^ ] [ ^^ ] [ ^^^ ] [ відповісти ]

/ - > Адже зберігаючи IP-адреса як рядок достатньої довжини, проблеми рівня зберігання потім не виникне.

І що буде достатньою довжиною? Передбачити різну довжину CHAR для IPv4 і IPv6 абсолютно те ж саме, що і передбачити правильний розмір INT для них же. А якщо писати з розрахунком на світле майбутнє, то взагалі все потрібно в TEXT зберігати, ось тільки в суворому сьогоденні такий проект жерти місце, працювати буде як черепаха і до світлого майбутнього не доживе. До речі як ви збираєтеся сортувати або шукати діапазони IP в текстовому вигляді та ще відразу з урахуванням різного уявлення v6 і v4?

• 4.7 , zoonman (Ok), 20:25, 08/06/2011 [ ^ ] [ ^^ ] [ ^^^ ] [ відповісти ]

/ - Доповню небагато:

The TIMESTAMP data type has a range of '1970-01-01 00:00:01' UTC to '2038-01-19 3: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

• 4.12 , Alex (??), 16:13, 14/06/2011 [ ^ ] [ ^^ ] [ ^^^ ] [ відповісти ]

/ - > На андроїд в контакт-листі завести день народження людини до 1970 року неможливо.

Уточніть яка версія андроїда, тому що на 2.2.1 цілком нормально заносяться в діапазоні від 1902 до 2036

• 5.19 , Stax (Ok), 23:34 17/06/2011 [ ^ ] [ ^^ ] [ ^^^ ] [ відповісти ]

/ - > Беремо signed int і цілком собі записуємо дати <1.1.1970 як негативні
> Числа.

Не жартуйте так :) По-перше, нестандартно, по-друге, ну виграли кілька десятиліть - але дати і до цієї бувають.

• 2.27 , Сергій (??), 2:15, 25/06/2011 [ ^ ] [ ^^ ] [ ^^^ ] [ відповісти ]

/ - Не всі пишуть програми для роботи в Інтернет. Є програми збору даних для локальних мереж. Використовувати IPv6 в цьому випадку нерозумно, а витрачати +12 байт даремно просто нерозумно - буде БД з одних IP.

• 2.18 , Stax (Ok), 23:33 17/06/2011 [ ^ ] [ ^^ ] [ ^^^ ] [ відповісти ]

/ - > Ip тільки в int!
&gt; Ви Пробував враховувати трафік по подсетям? ;)
> В строковому варіанті це перекрутив

Ну, під специфічні завдання можна використовувати різні способи зберігання. Якщо у вас IP використовується для підрахунку трафіку, зберігайте в INT, ніхто не забороняє :)

Деякі ще зберігають у вигляді "C0A80201" в CHAR (8) - для зручності специфічних дій.

Але під загальну задачу зберігання IP-адреси якогось ресурсу, сенсу запихати в INT особливо і немає.

• 2.17 , Stax (Ok), 23:31, 17/06/2011 [ ^ ] [ ^^ ] [ ^^^ ] [ відповісти ]

/ - > Агов, дивак, що зберігає ip в char, відсортуйте-ка їх по зростанню ..

А навіщо, вибачте? Відразу навіть завдань не приходить в голову, де потрібно сортувати по IP oO Пошук по IP, ще розумію ..

• 3.20 , Сергій (??), 2:29, 18/06/2011 [ ^ ] [ ^^ ] [ ^^^ ] [ відповісти ]

/ - Взяти максимальний 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

• 4.24 , Stax (Ok), 5:39, 19/06/2011 [ ^ ] [ ^^ ] [ ^^^ ] [ відповісти ]

/ - Я не розумію, що таке "максимальний IP". IP це просто адреса, з чотирьох чисел, якщо ipv4. Як ви у адреси визначаєте, який більше і який менше? І головне, навіщо?

А для IPv6 ви вважаєте, що ipv6-in-ipv4 сегмент 2002 :: це "більше" і краще, ніж нативні 2001 :: адреси? Приблизно така логіка?

• 3.21 , Сергій (??), 2:33, 18/06/2011 [ ^ ] [ ^^ ] [ ^^^ ] [ відповісти ]

/ - >> агов, дивак, що зберігає ip в char, відсортуйте-ка їх по зростанню ..
> А навіщо, вибачте? Відразу навіть завдань не приходить в голову, де потрібно
> Сортувати по IP oO Пошук по IP, ще розумію ..

Ще більш екзотичний варіант, в БД зберігаємо список підмереж у вигляді int - IP адреса мережі, у вигляді int - маску мережі. Завдання перевірки в які з мережі входить певний IP. Ось тут вже отримаєте більш серйозно оверхед якщо будете зберігати в char.

• 2.23 , антонім (?), 00:06, 19/06/2011 [ ^ ] [ ^^ ] [ ^^^ ] [ відповісти ]

/ - > Агов, дивак, що зберігає ip в char, відсортуйте-ка їх по зростанню ..

легко, якщо зберігати в HEX. Там же можна робити і вибірка по діапазонах.