У нас с JS есть общая тайна - мы оба не разбираемся в больших числах

5

1 год назад

все числа строками, в самом js есть явный тип bigint и библиотечки для big decimal и прочего

3

Lazy42

1 год назад

Почему? В данном примере всё довольно логично и предсказуемо, в том смысле, что язык некорректно работает с невалидными данными. Например, в каких-нибудь плюсах можно тоже поиметь проблем с переполнением. Про допустимый диапазон значений number пишут в каждой 2 статье для новичков. Единственный косяк именно джаваскрипта (а не кривой реализации браузеров, привет сафари ебаное), который можно отнести к "магии" - это typeof null == object, про что тоже знает каждая собака

4

https://262.ecma-international.org/6.0/#sec-typeof-operator-...

1 год назад

Единственный косяк именно джаваскрипта (а не кривой реализации браузеров, привет сафари ебаное), который можно отнести к "магии" - это typeof null == object

Всё по спеке. И typeof null, и number который инты херит. Всё по спеке, просто спека г-но =)

Valax

1 год назад

Блин. Дорогой ТС, как въехать в эту хрень? Есть необходимость прокачать навык чтения кода и понимания каких-то базовых основ программирования, но я хз, с чего вообще начать (((

1

1 год назад

Зависит от стартового уровня. Но главное практика (если с постановкой задач проблема - можно начать в любом интерактивном учебнике)

1 год назад

Нет, это не метаданные. Это часть натурального ключа.

Задача сортировки стоит всегда - это и самой БД нужно для эффективного индексирования, это и возрастающие индексы для восстановления порядка операций. Работать с ним везде как со структурой (т.е. явно передавать N чисел) или строкой просто неэффективно на больших объёмах плюс затрудняет ряд промежуточных сервисов, где в принципе эта инфа просто хранится as is и бегает туда-сюда (да-да, из-за JS она теперь бегает как строка, но для текстового формата обмена это пара кавычек лишних, пофик). Т.е. условному саппорту знать, что там внутри, не нужно - для них это число, оно уникально, всё. Аналогично с 3rd party и внутренними сервисами, которые делают аналитику, начисления через двухфазный коммит и т.п.

1 год назад

прикинул на пальцах примерчик с номером карты

16-значный номер умещается в 54 бита

дата истечения (4 цифры) ещё 10 бит

Итого номер + дата истечения = одно 64-битное целое (8 байт).

Если строкой - это 20 байт.

При этом в номере карты есть - номер платёжной системы, БИК банка, номер самой карты и контрольные разряды для UX (при вводе вручную ошибка в паре цифр не страшна и может быть провалидирована на UI)

Вот что-то похожее было у нас с transaction id и почему это было число и почему его подрезание привело к проблемам.

CrowsZero

1 год назад

Зачем нужно переводить это число в инт если не стоит задача сортировки например? Ведь если есть биты маршрутизации то это уже просто метаданные

1 год назад

Нет, это не метаданные. Это часть натурального ключа.

Задача сортировки стоит всегда - это и самой БД нужно для эффективного индексирования, это и возрастающие индексы для восстановления порядка операций. Работать с ним везде как со структурой (т.е. явно передавать N чисел) или строкой просто неэффективно на больших объёмах плюс затрудняет ряд промежуточных сервисов, где в принципе эта инфа просто хранится as is и бегает туда-сюда (да-да, из-за JS она теперь бегает как строка, но для текстового формата обмена это пара кавычек лишних, пофик). Т.е. условному саппорту знать, что там внутри, не нужно - для них это число, оно уникально, всё. Аналогично с 3rd party и внутренними сервисами, которые делают аналитику, начисления через двухфазный коммит и т.п.

CrowsZero

1 год назад

А откуда такие большие id взялись?

1 год назад

ЕМНИП кейс был с transaction id, которые включали биты для маршрутизации и шардирования, а потому в определённый момент "лимит" на инты был исчерпан. Детали не помню, но условно 32 бита были под шардирование и для JS в неудачном шарде поместится всего 1млн транзакций.