artur3
14.03.2016 - 13:05
Алоха. Что делать когда заканчиваются возможности int а позже и BIGINT ?
sergeiss
14.03.2016 - 13:20
В связи с чем они заканчиваются? Это автоинкремент так быстро растет, что ли? Или это абстрактный вопрос был?
_____________
*
Хэлп по PHP*
Описалово по JavaScript *
Хэлп и СУБД для PostgreSQL*
Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги. *
"накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)
inpost
14.03.2016 - 13:25
И как такое могло случиться? Может быть неверная архитектура?
_____________
Обучаю веб-программированию качественно и не дорого:
http://school-php.comФрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).
sergeiss
это абстрактный вопрос вызванный особенностью автоинкремент
inpost
архитектура сейчас продумывается отсюда и вопрос
Цитата (Guest @ 14.03.2016 - 09:42) |
вызванный особенностью автоинкремент |
Если добавлять записи в таблицу со скоростью 100000 в секунду, то чтобы закончился bigint придется подождать около 584942 лет. Так что не стоит париться по этому поводу.
kaww
и когда мы медленно подойдем к этому лимиту то... , что делать?
вместо 19 значных чисел может быть лучше использовать метку времени и пользователя?
Цитата (kaww @ 14.03.2016 - 13:45) |
Если добавлять записи в таблицу со скоростью 100000 в секунду, то чтобы закончился bigint придется подождать около 584942 лет. Так что не стоит париться по этому поводу. |
Ты где то ошибся. То ли записей в 10 раз больше в секунду, то ли лет в 10 раз больше)
Цитата (Guest @ 14.03.2016 - 09:53) |
Ты где то ошибся. |
Вроде верно:
SELECT 18446744073709551615 / 1000000 / 60 / 60 / 24 / 365;
Разве что стоило вместо 365 использовать 365.25, тогда немного меньше получится.
T1grOK
14.03.2016 - 13:58
Цитата (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
14.03.2016 - 14:01
P.S. Я бы проводил предпроектый анализ и акцентировал внимание на более приземленных проблемах, т-к с вероятностью 100% вы столкнетесь с массой проблем и максимальное значение BIGINT будет на самом последнем месте.
_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api
T1grOK
14.03.2016 - 14:17
kaww
100000 != 1000000
_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api
T1grOK
система основана использовании апи одного известного сервиса
иерархия структур
продавец
группа отваров
товары
свойства
можете сказать что стоит более детально проработать
inpost
14.03.2016 - 14:24
Ох эти теоретики
Когда закончится bigint, то специально для тебя MySQL разработает veryBigInt
_____________
Обучаю веб-программированию качественно и не дорого:
http://school-php.comФрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).
Попробуй для начало лимит привисить..
A BIGINT's range is -
9223372036854775808 to
9223372036854775807.
The unsigned range is 0 to
18446744073709551615.
Быстрый ответ:
Powered by dgreen
Здесь расположена полная версия этой страницы.