🙊 Прохожу значит я курс по SQL в своей магистратуре и тут вижу интересный кейс, решил поделиться с вами. Если честно, ни разу не видел в продовых решениях ни в аналитических таблицах CHAR, ни в хранении логов с различных сервисов, но возможно пригодиться или кто-то использовал (делитесь в комментах) 🔽 `DROP TABLE IF EXISTS zasql_python_table;

create table zasql_python_table ( value1 CHAR(5), value2 VARCHAR(5) );

INSERT INTO zasql_python_table VALUES ('abcd', 'abcd');

SELECT CONCAT(value1, value2) as result_1_2, CONCAT(value2, value1) as result_2_1 from zasql_python_table;

🗣 Результат будет следующий 🙃

| result_1_2 | result_2_1 | |-------------|-----------| | abcd abcd | abcdabcd |

Видите пробел между abcd и abcd? Это как раз CHAR, который дополнил строку до фиксированной длины.

Ну или после этого сообщения начнуть кошмарить на собесах по SQL... 👩‍💻

Вроде бы БАЗА, о которой говорят в самом начале любого курса, но внимания на этом акцентируется мало (мной или курсом). Вот, у вас есть типы данных, один делает то, другой это.

🐸 Если очень грубо:

🥳 CHAR(n) используется для хранения строк фиксированной длины. Если строка короче, чем n, она автоматически дополняется пробелами до нужной длины. При выводе эти пробелы обычно сохраняются (зависит от СУБД). Подходит, когда все значения примерно одинаковой длины (например, коды, индексы).

🥳 VARCHAR(n) хранит строки переменной длины. Если строка короче n, то пустоты не добавляются, сохраняются только фактические символы. Если строка длиннее n, она будет обрезана до заданного размера. Подходит, когда длина строк сильно варьируется.

Например, в одной статье говорится следующее:

For instance, CHAR often outperforms VARCHAR in scenarios with consistently sized data due to its fixed length, resulting in faster index lookups—up to 20% quicker on average. Conversely, VARCHAR excels in space efficiency for variable-length data, making it an ideal choice for dynamic datasets. The decision between CHAR vs VARCHAR is not just about storage but also about optimizing your database’s speed and efficiency.

⬆️ CHAR часто превосходит VARCHAR в сценариях с данными одинакового размера благодаря фиксированной длине, что приводит к ускорению поиска по индексу — в среднем на 20 %.

Или в другой:

The amount of work the database engine has to perform to store and retrieve VARCHAR columns is more than it takes for a CHAR column. Every time a VARCHAR column is retrieved, the Database engine has to use the length information stored with the data to retrieve a VARCHAR column value. Using this length information takes extra CPU cycles. Whereas a CHAR column and its fixed length allow SQL Server to more easily chunk through CHAR column based on their fixed-length column definitions.

⬆️ Для хранения и извлечения VARCHAR столбцов ядру базы данных требуется больше ресурсов, чем для CHAR столбцов. При каждом извлечении VARCHAR столбца ядру базы данных приходится использовать информацию о длине, хранящуюся вместе с данными, чтобы извлечь значение столбца VARCHAR. Использование этой информации о длине требует дополнительных вычислительных ресурсов.

Авторы предлагают использовать CHAR для фиксированной длины и в этом случае скорость будет выше, но я опять скажу, что пока что ни разу не видел такие витрины, где бы использовался этот тип данных. Может вы сможете привести РЕАЛЬНЫЙ кейс, где бы это использовали. Понравился пост? Ставьте 🐳****, если понравился пост, пишите комментарии! Может вы использовали CHAR и это помогло? Нужны кейсы!

@zasql_python`