[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: что делать когда заканчиваются int
Страницы: 1, 2
artur3
Алоха. Что делать когда заканчиваются возможности int а позже и BIGINT ?
sergeiss
В связи с чем они заканчиваются? Это автоинкремент так быстро растет, что ли? Или это абстрактный вопрос был?

_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL

* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.

* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)

user posted image
inpost
И как такое могло случиться? Может быть неверная архитектура?

_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).
Guest
sergeiss
это абстрактный вопрос вызванный особенностью автоинкремент

inpost
архитектура сейчас продумывается отсюда и вопрос
kaww
Цитата (Guest @ 14.03.2016 - 09:42)
вызванный особенностью автоинкремент

Если добавлять записи в таблицу со скоростью 100000 в секунду, то чтобы закончился bigint придется подождать около 584942 лет. Так что не стоит париться по этому поводу.
Guest
kaww
и когда мы медленно подойдем к этому лимиту то... , что делать?
Guest
вместо 19 значных чисел может быть лучше использовать метку времени и пользователя?
Guest
Цитата (kaww @ 14.03.2016 - 13:45)
Если добавлять записи в таблицу со скоростью 100000 в секунду, то чтобы закончился bigint придется подождать около 584942 лет. Так что не стоит париться по этому поводу.

Ты где то ошибся. То ли записей в 10 раз больше в секунду, то ли лет в 10 раз больше)
kaww
Цитата (Guest @ 14.03.2016 - 09:53)
Ты где то ошибся.

Вроде верно:
SELECT 18446744073709551615 / 1000000 / 60 / 60 / 24 / 365;

Разве что стоило вместо 365 использовать 365.25, тогда немного меньше получится.
T1grOK
Цитата (Guest @ 14.03.2016 - 09:50)
и когда мы медленно подойдем к этому лимиту то... , что делать?

Вы сейчас шутите что ли?) Несколько сот тысячелетий для вас не аргумент?

Если на то пошло то ни одна СУБД в мире не сможет вменяемо-быстро обрабатывать столько данных (если подразумевается конечно хранение и дальнейшая обработка).
Если действительно дойдет дело до оперирования огромным количеством данных, то нужно будет использовать целый комплекс подходов и различных инструментов размазанных по немалому серверному кластеру.

_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api
T1grOK
P.S. Я бы проводил предпроектый анализ и акцентировал внимание на более приземленных проблемах, т-к с вероятностью 100% вы столкнетесь с массой проблем и максимальное значение BIGINT будет на самом последнем месте.

_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api
T1grOK
kaww
100000 != 1000000

_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api
Guest
T1grOK
система основана использовании апи одного известного сервиса

иерархия структур
продавец
группа отваров
товары
свойства

можете сказать что стоит более детально проработать
inpost
Ох эти теоретики wink.gif
Когда закончится bigint, то специально для тебя MySQL разработает veryBigInt wink.gif

_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).
Oyeme
Попробуй для начало лимит привисить.. laugh.gif

A BIGINT's range is -9223372036854775808 to 9223372036854775807.

The unsigned range is 0 to 18446744073709551615.
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.