1. Куча / Говнокод #26979

    +1

    1. 1
    2. 2
    3. 3
    4. 4
    Зачем в базах данных нужны несколько вариаций одного и того же типа?
    Например, "tinyint", "mediumint", "smallint" и "bigint". Зачем они нужны, если
    можно было бы просто сделать один "int", причём равнозначный нынешнему
    "bigint"? Что даёт этот искусственно раздутый выбор целочисленных типов?

    Запостил: rotoeb, 25 Сентября 2020

    Комментарии (64) RSS

    • Если у тебя будут миллиарды записей, и ты грамотно применишь тип, например smallint вместо int, когда это допустимо, то сможешь сэкономить много места.
      Ведь под хранение smallint нужно меньше байт, чем для int. Умножь разницу в размерах на количество записей и получишь количество сэкономленной памяти.
      Ответить
      • Хороший ответ. Но не проще ли сразу арендовать сервер подороже, чем считать байты? А то в спешке выставишь тип "tinyint" для поля с автоинкрементом, и охуеешь, когда база перестанет вставлять новые записи.
        Ответить
        • Я так и не услышал оправданий, почему нельзя арендовать сервер подороже.

          ?
          Ответить
        • Ну например запись не может быть больше 8060 байт в mssql из-за ограничения размера страниц в 8кб. Серверная память не то чтобы дешевое удовольствие. Сравнение bigint и int наверное по процессору одинаково (пусть @bormand меня поправит), но опять же лишний меморитраффик. Не забывай, что колонки иногда индексируются и это опять же отражается на размере требуемой памяти.

          Можешь швырять деньги в сервер, но всё равно проиграешь по скорости работы.
          Ответить
          • Меня давно кое-что интересует. Вот в ВК, например, да и в других социальных сетях, у каждого сообщения есть что-то типа id.

            И я не понимаю: 40 тысяч обезьян пишут 24/7 сообщения типа "прив", "ок", "че дел", ")". Что в этом случае делает программист, который работает с базой? Ставит Long_Long_very_Big_int для поля с айдишником, чтобы побольше сообщений вместилось? А не боится, что айдишник переполнится и будет багор?
            Ответить
            • 64 бит хватит всем.

              Ну или PK из джвух колонок (user_id, message_id), но я не настоящий датаёб, а СУБД на помойке нашёл.
              Ответить
              • 128 бит uuid v4 хватит всем
                Ответить
                • Да, UUID уж точно не переполнится, даже если сорок миллиардов обезьян будут отправлять по скобочке раз в микросекунду.
                  Ответить
            • Композитный ключ (senderId int32/64, messageId int32)?
              Ответить
    • Зачем в языках программирования нужны несколько вореций одного и того же типа?
      Например, "Byte", "Shortint", "Smallint" и "Longint". Зачем они нужны, если
      можно было бы просто сделать один "int", причём равнозначный нынешнему
      "Int64"? Что даёт этот искусственно раздутый выбор целочисленных типов?
      Ответить
      • Именно поэтому я за питон с его единственным целым типом int.
        Ответить
        • +
          Ответить
        • Я бы тоже был за него, если бы не долбоёбские отступы и уёбищные импорты вместо включений (как в "PHP").
          Ответить
      • А теперь возьмём "PHP". Один "int" и один "float". Всё. Никакого скрупулёзного подсчитывания каждого байтика. Язык для людей - тупо программируешь, наслаждаешься и течёшь. Поэтому я за "PHP".
        Ответить
        • В «JavaScript» всё ещё лучше, там нету даже явной разницы между «int» и «float».
          Ответить
          • +1

            никакого дурацкого флоат и инт
            . Язык для людей - тупо программируешь, наслаждаешься и течёшь. Поэтому я за "джаваскрипт".
            Ответить
            • "Яваскрипт".
              Ответить
            • Там даже между строкой содержащей число и числом нет значительной разницы.

              Хочешь так:
              -'22'+66
              А хочешь так:
              -22+66

              Правда в «ПХП» ещё лучше зделали.
              Ответить
              • А в луа можно так:
                '-22'+'66'
                Ответить
                • В луняшке много полезных идей. Хотя, к сожалению, она не является местом концентрации их всех.
                  Ответить
                  • А кто является?

                    Лучшая идея в луняшке это таблица
                    Ответить
                    • Пока таких не знаю. У каждого есть что-то интересное, а всё сразу не видел.
                      Мне кажется, там метатаблица и ./: - самое крутое.
                      Ответить
                      • Мне вообще в скриптовых именно языках нравится одна структура данных для всей нескалярных (или как правильно сказать?) типов: массив, объект, ассоц.массив(мап/дикт/хеш) и декларативный синтаксис для описания и единый для обращения. Внезапно, джаваскриптячьи объекты в этом вопросе похожи.

                        В скриптушке не должно быть разницы между
                        foo.bar
                        и
                        foo["bar"]
                        Ответить
          • Согласен. Поэтому именно "PHP" и "JavaScript" - самые популярные языки программирования в мире.
            Ответить
          • И любопытно, что, в итоге, за всё время существования "JavaScript" никто так и не заметил минусов от выбора, ограниченного одним типом "Number". Спрашивается: нахуй дебилы пердолились и продолжают пердолиться с типами в своих маргинальных языках вроде "Java", "C#" и "Go"? В последнем каждый числовой тип разбит зачем-то на тридцатидвух- и шестидесятичетырёхбитный варианты. Нахуй? "PHP" и другие языки для белых прекрасно обходятся без этих условностей.
            Ответить
            • > каждый числовой тип разбит зачем-то на тридцатидвух- и шестидесятичетырёхбитный варианты

              Обколются своими типами, и начнут умничать: 8-бит, 16-бит, 32-бита.
              Умничают, пока все эти биты не переполнятся.

              А в 99% умники не пишут проверки на «инт машт оверфлоу».

              > "PHP" и другие языки для белых прекрасно обходятся без этих условностей.

              Да. И числа там не переполняются.
              Ответить
          • И это хорошо.

            Вообще, главное - не длина числа, а умение им пользоваться. Компиляторы JS умеют не скатываться в плавтухов как только увидят деление. Круг задач, в которых компилятор не угадал, и надо пердолить нумерованные инты, существенно сужается.

            А вот какой-нибудь наполовину статически типизированный родственник - JScript.NET - может на всех делениях целых сливать пирфоманс, тут даже идиома (x / y | 0) не поможет, вычисления всё равно зашкварятся плавтушнёй.
            Ответить
      • Зачем в языках программирования нужны несколько типов?
        Что даёт этот искусственно раздутый выбор типов?
        Ответить
        • Предлагаешь указатели и индексы массивов в даблах хранить?
          Ответить
          • указатели и индексы это тоже типы ведь, а я предлагаю вовсе без типов

            кто так умеет? форт?
            Ответить
            • В спеке форта всё равно немного типов упоминается (адреса, числа, байты и т.п.). В общем-то как и в ассемблерных инструкциях. Они никак не проверяются, конечно. Но как без них?
              Ответить
              • в асермлербе много типов: байт, ворд, дабл ворд.. всё?
                Ответить
                • Ну в форте например есть тип "адрес ячейки". Это просто число, но оно должно быть кратно размеру ячейки.

                  И всякие "двойные целые" на джве ячейки есть.
                  Ответить
                • Байт, ворд, даблворд, квадворд, флоат, дабл, экстендед, 64, 128 и 256 битные векторы из этой хуйни, far указатели. Всё наверное?
                  Ответить
                  • фар указатели не тип, это просто два целых
                    Ответить
                    • Дабл не тип, а просто 64 бита.

                      Сёмантически это таки тип, структура из джвух полей можно сказать. В некоторых инструкциях (lgbt кажется) даже про правильное выравнивание говорится.
                      Ответить
                      • если мы поинторы считаем за отдельный тип, то нужно отличать

                        mov al, 42
                        от
                        mov byte ptr [ax], 42
                        или от lea

                        там байт, а там указатель на байт
                        Ответить
              • ЕМНИП в спеке форта (во всяком случае ANS'94) байты не упоминаются, есть некий "минимальный адресуемый элемент", но ни его диапазон значений, ни слова для работы с ним не упоминаются. Часто в системах символ соответствует байту, но это не обязательно должно быть так.
                Ответить
                • А, ну да. Перечитал спеку, короче как в сишке -- минимум 8 бит, но может быть и больше.

                  > слова для работы с ним не упоминаются

                  C@ и C! как минимум. Ну и CHAR+ и CHARS для продвижения указателя на нужный размер.
                  Ответить
                  • Да, как в сишке, символ >= 1 бата, т.е. C@ извлекёт 1 бат только на системе где sizeof(char)==1, и больше если больше. Если было бы строго равно 1, слова CHAR+ и CHARS были бы нинужны. Переносимый способ работать с батами в мапяти — MOVE'ать.
                    Ответить
            • Наверно так умеет нетипизированное лямбда-исчисление. Может быть, к нему стоит добавить к нему паттерн матчинг, именование функций и АТД для удобства, чтобы получился нормальный язык.
              Ответить
          • Вай нот? Один хер на том же х86 только 52 бита рабочие. Как раз под размер мантиссы в дабле.
            Ответить
            • Это уже архитектурно-специфичная питушня. В каком-то ином 64-битном процессоре могут быть все адреса нужны.
              Ответить
    • В «СБи» можно не писать типы, они автоматически определяются как единый «int».

      Именно поэтому я за «Си»
      Ответить
    • > Зачем они нужны, если можно было бы просто сделать один "int", причём равнозначный нынешнему "bigint"?
      > Что даёт этот искусственно раздутый выбор целочисленных типов?

      А ещё наплодили своих char, varchar, xml, json. У некоторых ещё nchar, nvarchar.

      А то пишут, пишут… Схема, типы какие-то… Голова пухнет.
      Взять всё, да и в поле TEXT!
      Ответить
      • Какой sqlite )))
        Ответить
      • Именно по этому я за Perl.

        Там есть массив, скаляр и хеш. Всё
        Ответить
        • Поясни насчёт двух последних.
          Ответить
          • Скаляр - число или строка
            Хеш - х.з., тоже массив, если на пхп перевести
            Ответить
          • Что именно?
            use warnings FATAL => 'all';
            use strict;
            
            my $name = 'Joe'; # Это скаляр
            my $age = 90; # И это скаляр
            
            my @govno = q/PHP JavaScript/; # Это массив
            my %languages = ( # А это хеш: ассоциативный массив
                php  => 'parasha',
                perl => 'rulez'
            );
            
            my $govnoRef = \@govno; # Ссылка на массив или хеш это так же скаляр
            Ответить
            • А ну да, я про ссылки забыл. Перл лет 5 не открывал уже.
              Ответить
            • use warnings FATAL => 'all';

              error_reporting(E_ALL);
              Ответить
              • Я придерживаюсь иной идеологии:
                error_reporting(0);
                ini_set('display_errors', '0');
                Ответить
      • Для небольших данных вроде названий или адресов электронной почты я использую "varchar" длиной в 128 знаков. Для текстов помасштабнее - тупо "mediumtext".
        Ответить
      • Это в нормальной базе данных так. И зожатие тебе, и хранение не хуже варчара.
        А у некоторых поле TEXT это мать его CLOB, а клоб - ебаный багор, который даже через dblink крайне анально просачивается (эпический костыль приходится городить блять).
        Стоит ли упоминать, что клоб не может быть уником, ПК, да даже джойнить по нему хуйцов только
        Ответить

    Добавить комментарий