Программирование[11]

Kant said 6 hours ago:

варчармакс для имени и емейла, которые в 100% случев должны будут быть индексированы, а тот же емейл еще и скорее всего уникальным индексом помазан

только индексы по варчармаксам не работают

 

молчу уже про то, что эти поля чисто логически никогда не должны быть варчармаксами, как и 99.99% любых полей в системе

Слышь ты, варчармакс, иди отсюда, самый умный чтоли?

Ну и говно ваша Mysql если даже проиндексировать текстовые поля переменной длины не может.

Imagine в 2023 описывать текстовые поля не как TEXT и париться о том какое число символов в нем должно быть. 

При том что из трех нормальных промышленных субд только в одной нормальным считается использование типа text. 

text это та хуйня, что была задепрекейчена 20 лет назад везде?

В pg оставили за каким-то хуем.

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

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

ArzanisAncient написал 1 минуту назад:

Да продолжайте хуярить максы и тексты в базу.

Ты дето на редите вычитал что стринга это плохо, но не понял о чем речь и почему?

Или почему тогда ты не можешь сформировать причину своего полыхания?

Ну, тут 2 вопроса.
Почему text говно и его выпилили отовсюду, кроме pg:
1) Он подразумевает хранение блобом, а не в самой строке.

2) Он избыточен относительно стандартных типов
3) Он вне стандарта

4) Разработчики очень любили подход "ну бля эта же страка" и хуярить туда всё подряд, несмотря на то что это блоб ебаный, который должен быть определению исключен из всего стандартного поведения RDBMS баз (обычное индексирование, ключи, ограничения и т.д.) и просто лежать на чтение. После чего, очевидно, возникали разнообразные проблемы с производительностью, которые не всегда легко пофиксить в базе.

Почему varchar(max) стоит использовать аккуратно и там где надо:
1) Он вызывает непредсказуемые проблемы с производительностью в зависимости от субд. Например, в скуль сервере при превышении размера страницы (8кб) он улетает в блоб и всё из п.4 в первом вопросе идет по пизде.
2) Стандартные битри индексы очевидно хуево работают с таким говном. Поэтому собственно в скуль просто нельзя поставить дефолтный индекс на такое поле. В пг тоже будет хуево, но там выбор типов индексов пошире.
3) Соответственно, из-за этого невозможно гарантировать стабильное и надежное поведение запросов с этим полем и нормальную оптимизацию. А стабильность и надежность это как бэ альфа и омега RDBMS.

TLDR: в стандартных RDBMS поведение полей до 8кб и после сильно отличается, поэтому их нужно четко разделять при проектировании базы.

Вот поэтому не хотел писать. Хуйня неструктурированная, а не ответ получился. Это из-за того что в базовой теории плыву и на ходу вспоминаю/догугливаю. Ну да ладно, не буду удалять.
Но я тебя на карандаш по коммуникации взял, ГР.

ArzanisAncient написал 48 минут назад:

Он подразумевает хранение блобом, а не в самой строке.

Не подразумевает. Все понимают что это просто шорткат до varchar'а.

ArzanisAncient написал 48 минут назад:

Разработчики очень любили подход "ну бля эта же страка" и хуярить туда всё подряд, несмотря на то что это блоб ебаный

Причем тут сам text? Для блобов есть отдельные типы данных. Если написано text, значит там блять текст.

ArzanisAncient написал 48 минут назад:

который должен быть определению исключен из всего стандартного поведения RDBMS баз (обычное индексирование, ключи, ограничения и т.д.) и просто лежать на чтение

Индексы, ключи, ограничения, ты формируешь сам, тут нет "стандартного" поведения. Индекс, ключи, ограничения, то о чем ты говоришь, не должны зависеть от ТИПА данных, их навешивание зависит от логического назначения. Ты должен вешать индексы туда, где они нужны, а не херачить их по дефолту на все поля попутно индексируя колонку в которой джсоны на десятки кб лежат.

ArzanisAncient написал 48 минут назад:

TLDR: в стандартных RDBMS поведение полей до 8кб и после сильно отличается, поэтому их нужно четко разделять при проектировании базы.

После таких берешь базу, а там varchar(3) на колонке name в словарике в которой хранится (on, off).

Понятно, поначитаются редитов и начинают себя богами мнить. Нехуй заниматься дрочем ради дроча. Если ты занимаешься проектированием базы, то и занимайся вопросами проектирования, в том числе вопросами ограничения размера колонки в которую залетают пользовательские данные, если такое необходимо, прописывая varchar.

Я думал давно вымерли любители varchar(255), ан нет. Прописываю тебе живительного постреса для лечения.

Ясн, кроме pg ничего не существует и не может существовать.
Но pg молодцы, конечн, что ебнули свою фичу для 8кб+. Видимо заебали вы их.

Хотелось бы конечно почитать что там по оверхедам и ограничениям этой хуйни, но похуй на пг пока.
 

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

Пошел нахуй крч. 

ArzanisAncient написал 1 час назад:

Он вне стандарта

Чел, на дворе 2023 год, какой блять стандарт? Изобретенный 50 лет назад?

Каждый день выходит новый *QL где общего стандарта только SELECT и FROM

Как правильно написано выше, text просто шорткат для varchar. Мне похуй что там скрывалось за text в 1974 году как и в стандартах SQL (который обновился в 2016 последний раз) один хуй даже тот же MySQL уверен не поддерживает его на 100%. 

Покажите мне ебало того, кто учит стандарт,а не документацию к конкретной базе.

ArzanisAncient написал 1 час назад:

Да продолжайте хуярить максы и тексты в базу. Не забудьте еще денормализацию по полной.

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

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

Ну и само собой шардировать данные с помощью того же citus. что даже кликхаус не нужон  

Сейчас даже использование H2 для тестов/разработки считается моветоном когда есть test/devContainers где ты можешь поднять и потушить себе нормальный инстанс постгреса и ровно как использовать различные постгресовские штучки в бизнесе, а не жить стандартом.

ArzanisAncient said 1 hour ago:

Ну, тут 2 вопроса.
Почему text говно и его выпилили отовсюду, кроме pg:
1) Он подразумевает хранение блобом, а не в самой строке.

2) Он избыточен относительно стандартных типов
3) Он вне стандарта

4) Разработчики очень любили подход "ну бля эта же страка" и хуярить туда всё подряд, несмотря на то что это блоб ебаный, который должен быть определению исключен из всего стандартного поведения RDBMS баз (обычное индексирование, ключи, ограничения и т.д.) и просто лежать на чтение. После чего, очевидно, возникали разнообразные проблемы с производительностью, которые не всегда легко пофиксить в базе.

Почему varchar(max) стоит использовать аккуратно и там где надо:
1) Он вызывает непредсказуемые проблемы с производительностью в зависимости от субд. Например, в скуль сервере при превышении размера страницы (8кб) он улетает в блоб и всё из п.4 в первом вопросе идет по пизде.
2) Стандартные битри индексы очевидно хуево работают с таким говном. Поэтому собственно в скуль просто нельзя поставить дефолтный индекс на такое поле. В пг тоже будет хуево, но там выбор типов индексов пошире.
3) Соответственно, из-за этого невозможно гарантировать стабильное и надежное поведение запросов с этим полем и нормальную оптимизацию. А стабильность и надежность это как бэ альфа и омега RDBMS.

TLDR: в стандартных RDBMS поведение полей до 8кб и после сильно отличается, поэтому их нужно четко разделять при проектировании базы.

 

 

Вот поэтому не хотел писать. Хуйня неструктурированная, а не ответ получился. Это из-за того что в базовой теории плыву и на ходу вспоминаю/догугливаю. Ну да ладно, не буду удалять.
Но я тебя на карандаш по коммуникации взял, ГР.

 

не согласен по некоторым пунктам

Index said 22 minutes ago:

Покажите мне ебало того, кто учит стандарт,а не документацию к конкретной базе.

 

ArzanisAncient написал 43 минуты назад:

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

Ты так нихуя и не понял. Нужно описывать граничные кейсы и оптимизировать там где оно нужно, и когда нужно. Поэтому text является полем стандартным, и использоваться должно всегда, если не требуется обратного. Я не должен сидеть, читать твой код в которой явно описана длина на каждом пуке, и ебать себе мозг, пытаясь выяснить что ты хотел этим выразить.

Странно что мне, плюсисту, приходится такие прописные истины программирования объяснять.

GoldRobot написал 4 минуты назад:

ArzanisAncient написал 59 минут назад:

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

Ты так нихуя и не понял. Нужно описывать граничные кейсы и оптимизировать там где оно нужно, и когда нужно. Поэтому text является полем стандартным, и использоваться должно всегда, если не требуется обратного. Я не должен сидеть, читать твой код в которой явно описана длина на каждом пуке, и ебать себе мозг, пытаясь выяснить что ты хотел этим выразить.

Странно что мне, плюсисту, приходится такие прописные истины программирования объяснять.

Это ты нихуя не понял. Всё что выше размера страницы для RDBMS - это и есть всегда нестандарт с нестандартной реализацией, который прострелит тебе колено рано или поздно. Хочешь стандарт бери всегда VARCHAR(8000).

 

ArzanisAncient said 2 minutes ago:

GoldRobot said 6 minutes ago:

ArzanisAncient said 1 hour ago:

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

Ты так нихуя и не понял. Нужно описывать граничные кейсы и оптимизировать там где оно нужно, и когда нужно. Поэтому text является полем стандартным, и использоваться должно всегда, если не требуется обратного. Я не должен сидеть, читать твой код в которой явно описана длина на каждом пуке, и ебать себе мозг, пытаясь выяснить что ты хотел этим выразить.

Странно что мне, плюсисту, приходится такие прописные истины программирования объяснять.

Это ты нихуя не понял. Всё что выше размера страницы для RDBMS - это и есть всегда нестандарт с нестандартной реализацией, который прострелит тебе колено рано или поздно. Хочешь стандарт бери всегда VARCHAR(8000).

 

 

А что насчет сиквела VARCHAR(8000) 2? От создателей VARCHAR(8000). Хуже оригинала?

Zellar написал Только что:

ArzanisAncient написал 4 минуты назад:

GoldRobot написал 7 минут назад:

ArzanisAncient написал 1 час назад:

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

Ты так нихуя и не понял. Нужно описывать граничные кейсы и оптимизировать там где оно нужно, и когда нужно. Поэтому text является полем стандартным, и использоваться должно всегда, если не требуется обратного. Я не должен сидеть, читать твой код в которой явно описана длина на каждом пуке, и ебать себе мозг, пытаясь выяснить что ты хотел этим выразить.

Странно что мне, плюсисту, приходится такие прописные истины программирования объяснять.

Это ты нихуя не понял. Всё что выше размера страницы для RDBMS - это и есть всегда нестандарт с нестандартной реализацией, который прострелит тебе колено рано или поздно. Хочешь стандарт бери всегда VARCHAR(8000).

 

 

А что насчет сиквела VARCHAR(8000) 2? От создателей VARCHAR(8000). Хуже оригинала?

А я хз это рофл или нет, потому что у оракл тип так и называется VARCHAR2 

ArzanisAncient написал 28 минут назад:

Это ты нихуя не понял. Всё что выше размера страницы для RDBMS - это и есть всегда нестандарт с нестандартной реализацией, который прострелит тебе колено рано или поздно. Хочешь стандарт бери всегда VARCHAR(8000).

Вот и указывай там где ожидаешь нестандарт varchar(8000)

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

GoldRobot написал Только что:

ArzanisAncient написал 30 минут назад:

Это ты нихуя не понял. Всё что выше размера страницы для RDBMS - это и есть всегда нестандарт с нестандартной реализацией, который прострелит тебе колено рано или поздно. Хочешь стандарт бери всегда VARCHAR(8000).

Вот и указывай там где ожидаешь нестандарт varchar(8000)

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

Блядь, ты наркоман? У тебя на пг за 8000+ отвечает отдельный механизм (TOAST) с кучей ограничений и потенциальных проблем. И ты предлагаешь его использовать по умолчанию. Пиздец, как ты с таким подходом в Илзе еще не превратился на своих крестах.