capitan, для целых чисел нужно использовать intval, для вещественных floatval, но никак не иначе. При работе с большими целыми числами на 32х существуют соответствующие экстеншены приведенные выше. Для проверки является ли строка числом есть функция http://php.net/is_numeric

capitan, можешь применять и регулярку. Тогда смело забьешь на число значащих цифр.

Вопрос в том, что в твоих стандартных проектах ты не упрешься даже в лимит int.

100%-вариант. получим 1, ибо id стандартно - unsigned

Добавлено через 2 минуты и 2 секунды

я упёрся. и не потому, что у меня такая большая база, а потому что у других большая база. 
платёжная система сбрасывает свои данные под уникальным идентификатором, который я пишу к себе в базу. а у них там уже под 20 знаков

А он у них не цифровой. Там что хоть 65000 знаков.

да ладно. в моём случае чисто цифровой

bars80080, 
Я некорректно выразился, но все равно верь мне  я в банке работал.... не в трехлитровой 

Счета, номера карт - не являются числами.
Да, они обычно состоят из одних цифр - но это строки. И исключительно строки.

Добавлено через 1 минуту и 5 секунд
GUID, ID транзакции - тоже не числа. 

а я не работал в банке, но данные о проведённых платежах приходят в виде чисел. особо говорено, что id платежа - уникальный идентификатор состоящий исключительно из цифр. какая мне разница, как и где оно у них там хранится? я ставлю себе bigint и в ус не дую


Simpliest, вот серьёзно, насколько вы лучше меня можете знать приходящий мне формат данных, если я даже не указал о какой системе веду речь?

В каком, простите, месте это стандартно? 
Но в любом случае - это не корректный способ проверки числа.


В PHP любые данные из-вне поступают в виде строк.

Это сообщение отредактировал(а) sTa1kEr - 3.11.2009, 20:04

Почему? Почему не (int) и (float) соответственно?

так это не способ проверки числа вообще, это способ использования переданного id. Только запихнуть нужно куда-нибудь эти манипуляции, в функцию/класс


думаю, "стандартно" нужно понимать как "обычно". В mysql primary key + auto_increment не может создать отрицательный id. А что бывает необходимость в отрицательных id?

Само собой разумеется, что можно использовать (int) и (float). Я лишь имел ввиду то-же самое, что за минуту до меня сказал Ипатьев.

Добавлено через 10 минут и 13 секунд

Да, прошу прощенья, изначально речь шла исключительно об ID. Но суть моего сообщения была в том, что таким способом можно получить заведомо не правильный ID, а это в свою очередь может привести к плачевным последствиям.


С таким же успехом можно сказать, что стандартно ID - это строка из 36 символов, т.к. обычно в MSSQL primaty key - это GUID.

Да, бывает потребность в совершенно разных ID.

Я же сказал уже

И поправился



И плохо. Потому что это 64-битное целое и таким образом ты можешь хранить только 18ти-значные вещи (19я цифра может быть единицей) состоящие исключительно из цифр.
Например, у нас счет 14ти-символьный.
А у вас в России он уже может быть 20ти-символьным (он дейтствительно 20тизначный, но некоторые банки сокращают внутренний счет на несколько цифр)
Номера карт распространенных МПС - 16 символов. Но есть варианты и с 20тью и даже алфавитно-цифровые

Чтобы понять что счет это не число - можешь прочитать хотя бы его определение у вас
Рассчетный счет

Для того чтобы знать что обожжешься совершенно не нужно знать какая температура костра 500 или 2000 градусов.
Речь идет о том, что UID,ID, GUID, счета, номера карточек, серийные номера и т.д. и т.п. - не являются числами хотя и могут состоять исключительно из цифр.

Поэтому хранить ты можешь как угодно, но не забывать чем они являются на самом деле.

В случае с MySQL вас всех вводит в заблуждение автоинкрементное целочисленное поле в качестве sequence.
В более взрослых базах это может быть вообще не число (Oracle, Interbase/Firebird, DB2)

у вас id бывают отрицательные?



ну, это уже зависит от задачи. я думал, что речь идёт от прошлой темы, где проверялся идентификатор. там цель была не в числе, а именно в корректном идентификаторе.



  тогда вообще ваши ремарки бессмыслены. поступают строки, делаю из них что хочу



  


не понял. каким образом из этого:

может получиться не корректный id? 



я сейчас посмотрел, они у меня 15-значные



читать не буду, повторюсь только третий раз: я говорю не о счетах, а об идентификаторах операций. это не сертифицированная каким-то ведомством величина, это всего лишь порядковый номер принятый внутри организации для сохранения единого реестра. да они могли сделать его буквенным, но они сами себе прописали формат, что он - число. и опубликовали формат для всех партнёров, чтобы мы могли с ними сотрудничать. всё


легко может быть. я отдаю этой же системе свои идентификаторы в виде БЦБЦЦЦЦ-ЦЦ, потому что мне так удобно, и это вписывается в их формат данных
но это специфичный формат, и я его парсю соответствующим образом, вытаскивая из него систему оборота, идентификатор заказа и номер операции по ней

но мы говорим о частной ситуации, вытащенной из другой темы. 
и я её в очередной раз решаю инженерным способом, т.е. частно. что, видимо, не приветствуется в программерской среде. почему-то вам всегда нужны универсальные алгоритмы.

вот скажи, можно ли придумать универсальный метод проверки на корректность для входящего идентификатора - состоящего из одних цифр и для идентификатора - БЦБЦЦЦЦ-ЦЦ?

Собственно, зачем используется такая конструкция (int)$value? Посмотрите 1-й пост, ТС использует этот как фильтр
в своих запросах. А нужно ли это? Все нормальные либы используют биндинг для добавления переменных в запрос.

Многие утверждают, что данные должны поступать в бд в неизменном виде, сами при этом нарушая свой принцип подобными 

конструкциями.

ТС аргументировал такое поведение нагруженными проектами. Интересно узнать, какие проекты он считает 

нагруженными?;) На нормальные сервера ставят 64бита, и не изза того, что вы можете выйти за диапазон значений, а 

просто тупо потому, чтобы обеспечить нормальную работу с большими объемами памяти. В этом случае никаких проблем 

начальная конструкция не вызовет.

А вот используя float, проблемы как раз получить можно. Это и точка(запятая), связанная с локализацией,
и представление числа в виде строки, и выполнение арифметических операций, в результате чего будете получать
совсем не то, что ожидаете.

К тому же есть люди, которые используют везде (float), а при этом тип столбца у них в БД какой-нить smallint.
А еще забавно, когда пишут абстрактный слой для бд, при этом сами запросы в никакой другой бд работать не будут,
кроме mysql.
Ради чего усилия тогда, спрашивается?

Кто-то говорит "Я везде использую bigint. Я от всего застрахован". Может тогда для строк заюзать везде longtext?
Чем больше диапазон, тем больше требуется памяти для хранения. А нужно ли это?


Может быть, не стоит создавать дополнительных проблем? Может быть, все на самом деле проще...

я считаю, что bars80080 выбрал неподходящее слово. Более подходящее слово - обычно


не забывая про диапазон значений в этих строках


holy war detected!