1.1, Stax (ok), 14:10, 07/06/2011 [ответить] [﹢﹢﹢] [ · · · ] [↓] [к модератору]
| +/– |
> IP адреса лучше всего хранить как UNSIGNED INT. И использовать MySQL
> функции INET_ATON() и INET_NTOA()
Вот так и делают новые проекты без поддержки 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.5, ws (ok), 11:18, 08/06/2011 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| +/– |
> Мешают неразумные люди, следующие советам, не подумав. Советам вроде этих. И лучше
> всего не давать таких вот сомнительных советов. Ведь храня IP-адрес как
> строку достаточной длины, проблемы уровня хранения потом не возникнет.
Не согласен. Достоинства хранения IP в int более предпочтительные (объем хранимых данных,
скорость выборки). А вот недостаток только тот о котором вы говорите, но это решаемо если разработчик оказался недостаточно предусмотрителен (ALTER TABLE...)
Другими словами вы решаете в ущерб оптимизации возможные перспективы...
Так давайте тогда все данные хранить в строковых типах так проще по вашей логике.
| |
|
5.9, Dmitry (??), 13:07, 09/06/2011 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
Достоинства хранения (да и вообще представления)ip в int более, чем просто сомнительны. Большинство программ ждут, что ip им будет передан как текстовый тип, некоторые готовы принять 4 бинарных октета, int для ip - экзотика. Да и по здравому размышлению не является он таким типом. Не умножайте сущности.
| |
|
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_
| |
6.15, Сергей (??), 03: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 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
| |
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, Сергей (??), 02:15, 25/06/2011 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +/– |
Не все пишут программы для работы в Интернет. Есть программы сбора данных для локальных сетей. Использовать IPv6 в этом случае неразумно, а тратить +12 байт впустую просто глупо - будет БД из одних IP.
| |
|
|
2.18, Stax (ok), 23:33, 17/06/2011 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
> ip только в int!
> вы пробывали учитывать трафик по подсетям? ;)
> в строковом варианте это изврат
Ну, под специфические задачи можно использовать разные способы хранения. Если у вас IP используется для подсчета трафика, храните в INT, никто не запрещает :)
Некоторые еще хранят в виде "C0A80201" в CHAR(8) - для удобства специфических действий.
Но под общую задачу хранения IP-адреса какого-нибудь ресурса, смысла запихивать в INT особо и нет.
| |
|
|
2.17, Stax (ok), 23:31, 17/06/2011 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| +/– |
> эй, чудик, что хранит ip в char, отсортируй-ка их по возрастанию..
А зачем, простите? Сходу даже задач не приходит в голову, где нужно сортировать по IP o.O Поиск по IP, еще понимаю..
| |
|
3.20, Сергей (??), 02: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), 05:39, 19/06/2011 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
Я не понимаю, что такое "максимальный IP". IP это просто адрес, из четырех чисел, если ipv4. Как вы у адреса определяете, какой больше и какой меньше? И главное, зачем?
А для IPv6 вы считаете, что ipv6-in-ipv4 сегмент 2002:: это "больше" и лучше, чем нативные 2001:: адреса? Примерно такая логика?
| |
|
3.21, Сергей (??), 02:33, 18/06/2011 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +/– |
>> эй, чудик, что хранит ip в char, отсортируй-ка их по возрастанию..
> А зачем, простите? Сходу даже задач не приходит в голову, где нужно
> сортировать по IP o.O Поиск по IP, еще понимаю..
Еще более экзотический вариант, в БД храним список подсетей в виде int - IP адрес сети, в виде int - маску сети. Задача проверки в какие из сети входит определенный IP. Вот тут уже получите более серъезный оверхед если будете хранить в char.
| |
|
2.23, Антоним (?), 00:06, 19/06/2011 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +/– |
> эй, чудик, что хранит ip в char, отсортируй-ка их по возрастанию..
легко, если хранить в HEX. Там же можно делать и выборкии по диапазонам.
| |
|
|