- 1
- 2
- 3
- 4
Зачем в базах данных нужны несколько вариаций одного и того же типа?
Например, "tinyint", "mediumint", "smallint" и "bigint". Зачем они нужны, если
можно было бы просто сделать один "int", причём равнозначный нынешнему
"bigint"? Что даёт этот искусственно раздутый выбор целочисленных типов?
Ведь под хранение smallint нужно меньше байт, чем для int. Умножь разницу в размерах на количество записей и получишь количество сэкономленной памяти.
?
Можешь швырять деньги в сервер, но всё равно проиграешь по скорости работы.
И я не понимаю: 40 тысяч обезьян пишут 24/7 сообщения типа "прив", "ок", "че дел", ")". Что в этом случае делает программист, который работает с базой? Ставит Long_Long_very_Big_int для поля с айдишником, чтобы побольше сообщений вместилось? А не боится, что айдишник переполнится и будет багор?
Ну или PK из джвух колонок (user_id, message_id), но я не настоящий датаёб, а СУБД на помойке нашёл.
никакого дурацкого флоат и инт
. Язык для людей - тупо программируешь, наслаждаешься и течёшь. Поэтому я за "джаваскрипт".
Хочешь так:
-'22'+66
А хочешь так:
-22+66
Правда в «ПХП» ещё лучше зделали.
'-22'+'66'
Лучшая идея в луняшке это таблица
Мне кажется, там метатаблица и ./: - самое крутое.
В скриптушке не должно быть разницы между
foo.bar
и
foo["bar"]
Обколются своими типами, и начнут умничать: 8-бит, 16-бит, 32-бита.
Умничают, пока все эти биты не переполнятся.
А в 99% умники не пишут проверки на «инт машт оверфлоу».
> "PHP" и другие языки для белых прекрасно обходятся без этих условностей.
Да. И числа там не переполняются.
>«PHP» и другие языки для белых
https://ideone.com/24Q3OC
Вообще, главное - не длина числа, а умение им пользоваться. Компиляторы JS умеют не скатываться в плавтухов как только увидят деление. Круг задач, в которых компилятор не угадал, и надо пердолить нумерованные инты, существенно сужается.
А вот какой-нибудь наполовину статически типизированный родственник - JScript.NET - может на всех делениях целых сливать пирфоманс, тут даже идиома (x / y | 0) не поможет, вычисления всё равно зашкварятся плавтушнёй.
Что даёт этот искусственно раздутый выбор типов?
кто так умеет? форт?
И всякие "двойные целые" на джве ячейки есть.
Сёмантически это таки тип, структура из джвух полей можно сказать. В некоторых инструкциях (lgbt кажется) даже про правильное выравнивание говорится.
mov al, 42
от
mov byte ptr [ax], 42
или от lea
там байт, а там указатель на байт
> слова для работы с ним не упоминаются
C@ и C! как минимум. Ну и CHAR+ и CHARS для продвижения указателя на нужный размер.
Именно поэтому я за «Си»
> Что даёт этот искусственно раздутый выбор целочисленных типов?
А ещё наплодили своих char, varchar, xml, json. У некоторых ещё nchar, nvarchar.
А то пишут, пишут… Схема, типы какие-то… Голова пухнет.
Взять всё, да и в поле TEXT!
Там есть массив, скаляр и хеш. Всё
Хеш - х.з., тоже массив, если на пхп перевести
error_reporting(E_ALL);
А у некоторых поле TEXT это мать его CLOB, а клоб - ебаный багор, который даже через dblink крайне анально просачивается (эпический костыль приходится городить блять).
Стоит ли упоминать, что клоб не может быть уником, ПК, да даже джойнить по нему хуйцов только