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

валидация должна быть и там и там

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

некоторые так дошли до всяких монг и хуярят реляционные базы внутрь документа и сосут член при попытках обновить хоть что-то

открою тебе секрет, смена варчар(128) на варчар(255) нихуя не делает с данными, ведь варчар и так имеет размер равный данным

а раз данные не менялись, ничего перестраиваться и не будет

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

Алсо, теперь по поводу менеджинга индексов.  Мне всегда казалось индексы нужно менеджить отдельно от SQL бизнес-логики.

Т.к наличие/осутствие индекса никак не влияет на результат, они используются неявно и удаление индекса повлияет только на скорость.

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

Пусть DBA голову ломает как ему индекс заюзать. 

А то может быть обратная ситуация, разработчик насоздает индексов а потом база задыхается от них.

 

ну если ты в душе не ебешь что такое индексы и как они работают, то да, лучше пусть за тебя это дба делает

тк ты похоже не понимаешь

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

валидация должна быть и там и там

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

некоторые так дошли до всяких монг и хуярят реляционные базы внутрь документа и сосут член при попытках обновить хоть что-то

 

открою тебе секрет, смена варчар(128) на варчар(255) нихуя не делает с данными, ведь варчар и так имеет размер равный данным

а раз данные не менялись, ничего перестраиваться и не будет

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

Kant написал 2 минуты назад:

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

Алсо, теперь по поводу менеджинга индексов.  Мне всегда казалось индексы нужно менеджить отдельно от SQL бизнес-логики.

Т.к наличие/осутствие индекса никак не влияет на результат, они используются неявно и удаление индекса повлияет только на скорость.

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

Пусть DBA голову ломает как ему индекс заюзать. 

А то может быть обратная ситуация, разработчик насоздает индексов а потом база задыхается от них.

 

ну если ты в душе не ебешь что такое индексы и как они работают, то да, лучше пусть за тебя это дба делает

тк ты похоже не понимаешь

зачем мне чужой хлеб отбирать? У нас ДБА под Киевом сидит, а я получается косвенно финансирую ВСУ. 

Index написал 11 минут назад:

Чисто для интереса, какой размер варчара предлагаешь на email? 

две секунды в гугле

https://stackoverflow.com/questions/386294/what-is-the-maximum-length-of-a-valid-email-address

у гмейла вон вообще 30 символов лимит на часть до @

Index написал 2 минуты назад:

Kant написал 6 минут назад:

валидация должна быть и там и там

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

некоторые так дошли до всяких монг и хуярят реляционные базы внутрь документа и сосут член при попытках обновить хоть что-то

 

открою тебе секрет, смена варчар(128) на варчар(255) нихуя не делает с данными, ведь варчар и так имеет размер равный данным

а раз данные не менялись, ничего перестраиваться и не будет

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

какой нахуй констрейнт блять, варчар с длиной сам себе констрейнт

хуярят колонку неограниченной длины, вешают на неё чек констрейнт на длину и ябутся в жопы что они БЕЗЛИМИТНЫЙ ТЕКСТ ИСПОЛЬЗУЮТ

пиздос

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

и если в случае изменения размера варчара эта фича точно работает, то в случае чек констрейнта я хз достаточно ли база для этого умна

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

Index написал 14 минут назад:

Чисто для интереса, какой размер варчара предлагаешь на email? 

две секунды в гугле

https://stackoverflow.com/questions/386294/what-is-the-maximum-length-of-a-valid-email-address

 

у гмейла вон вообще 30 символов лимит на часть до @

Чисто пацаны со стековерфлоу сами стандары цитируемые не читают. Щас бы octets с character путать. 

Я бы сделал

  email TEXT NOT NULL
        CHECK ( OCTET_LENGTH(name) <= 256 )

Index написал 3 минуты назад:

Kant написал 8 минут назад:

Index написал 10 минут назад:

Алсо, теперь по поводу менеджинга индексов.  Мне всегда казалось индексы нужно менеджить отдельно от SQL бизнес-логики.

Т.к наличие/осутствие индекса никак не влияет на результат, они используются неявно и удаление индекса повлияет только на скорость.

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

Пусть DBA голову ломает как ему индекс заюзать. 

А то может быть обратная ситуация, разработчик насоздает индексов а потом база задыхается от них.

 

ну если ты в душе не ебешь что такое индексы и как они работают, то да, лучше пусть за тебя это дба делает

тк ты похоже не понимаешь

зачем мне чужой хлеб отбирать? У нас ДБА под Киевом сидит, а я получается косвенно финансирую ВСУ. 

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

но я сильно сомневаюсь, что это так

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

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

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

Kant написал 5 минут назад:

Index написал 19 минут назад:

Чисто для интереса, какой размер варчара предлагаешь на email? 

две секунды в гугле

https://stackoverflow.com/questions/386294/what-is-the-maximum-length-of-a-valid-email-address

 

у гмейла вон вообще 30 символов лимит на часть до @

Чисто пацаны со стековерфлоу сами стандары цитируемые не читают. Щас бы octets с character путать. 

Я бы сделал

  email TEXT NOT NULL
        CHECK ( OCTET_LENGTH(name) <= 256 )

 

That limit is a maximum of 64 characters (octets) in the "local part" (before the "@") and a maximum of 255 characters (octets) in the domain part (after the "@") for a total length of 320 characters. However, there is a restriction in RFC 2821 on the length of an address in MAIL and RCPT commands of 254 characters. Since addresses that do not fit in those fields are not normally useful, the upper limit on address lengths should normally be considered to be 254.

ну и поздравляю, вместо того, чтобы написать email varchar(256) ты написал целый ебаный чек констрейнт чтобы сделать то же самое

Kant написал 32 минуты назад:

чем раньше и точнее ошибка вылетит, тем лучше

Дык, с чего ты взял что она раньше вылетит?

Милости прошу если ты хочешь емеил ограничить 30ю символами. Но вот там где-то недалеко еще табличка чисто служебная, со список поддерживаемых языков (Rus, En, Kz), в ней ты зачем размер поля до символа подбирал?

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

Kant написал 14 минут назад:

какой нахуй констрейнт блять, варчар с длиной сам себе констрейнт

 

я про primary key если что 

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

Kant написал 41 минуту назад:

чем раньше и точнее ошибка вылетит, тем лучше

Дык, с чего ты взял что она раньше вылетит?

 

Милости прошу если ты хочешь емеил ограничить 30ю символами. Но вот там где-то недалеко еще табличка чисто служебная, со список поддерживаемых языков (Rus, En, Kz), в ней ты зачем размер поля до символа подбирал?

 

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

раньше, потому что ты можешь индекс не сразу повесить

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

я не хочу ограничивать емейл 30 символами, я пишу что емейл НЕ БЫВАЕТ неограниченной длины, как и 99% любых других атрибутов, и они будут в любом случае ограничены либо в коде либо в интерфейсе

нахуя в базе делать еблет, что можно всё?

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

и офк, тебе надо ограничивать сумму полей

сделав поле типа текст ты лишь ХУЖЕ себе делаешь в этом плане, тк у тебя нет ни шанса понять, какой набор колонок превысит порог, а какой нет

это классический пример строгой типизации

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

Index написал 9 минут назад:

Kant написал 24 минуты назад:

какой нахуй констрейнт блять, варчар с длиной сам себе констрейнт

 

я про primary key если что 

причем пк к чек констрейнтам вообще?

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

я уже молчу про производительность такого ключа при джоинах

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

Index написал 10 минут назад:

Kant написал 25 минут назад:

какой нахуй констрейнт блять, варчар с длиной сам себе констрейнт

 

я про primary key если что 

причем пк к чек констрейнтам вообще?

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

 

я уже молчу про производительность такого ключа при джоинах

Я про то что в некоторых базах альтерить поля которые завязаны на констрейнтах (пк это тоже констрейнт) не так просто.

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

Kant написал 2 минуты назад:

Index написал 11 минут назад:

Kant написал 26 минут назад:

какой нахуй констрейнт блять, варчар с длиной сам себе констрейнт

 

я про primary key если что 

причем пк к чек констрейнтам вообще?

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

 

я уже молчу про производительность такого ключа при джоинах

Я про то что в некоторых базах альтерить поля которые завязаны на констрейнтах (пк это тоже констрейнт) не так просто.

а я про то, что расширение размера варчара никак не влияет на байтики лежащие на диске и значит это никак не влияет на индексы

Что-то у вас душно стало, пойду в политтопик лучше

Расслабляемся под fastapi + mongodb + openai gpt3 api

да потому что вы хуйню какую-то в базах делаете и потом кричите, что реляционки говно

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

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

в итоге эта залупа по часу ебашит батчи на 500 эмплоев на гигантском сервере, когда на моей прошлой работе схожий объем вычислений выполнялся на всех 2 миллионах клиентов за 10 минут на моем бомже компе с 8 гб оперативки, после того как я пофиксил проблему с хуевым кэшированием планов из-за параметр сниффинга

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

а потом такие разработчики и идут в носкл, тк там нихуя нет кроме 1 ключа и дальше джсона

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

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

НЕ БЫВАЕТ неограниченной длины, как и 99% любых других атрибутов, и они будут в любом случае ограничены либо в коде либо в интерфейсе

Из-за таких как ты стандарты и являются говном в большинстве случаев. Потому что у вас какая-то физическая потребность 99.9999% служебных атрибутов ограничить, а потом выпускать 193485 дополнения в течении 30 лет где они расширяются костылями. Хотя казалось бы, просто текстовое поле с нул терминатором, но нет у нас будет в этой версии строго 6 символов (включая нулл), и не больше! А ты потом еби мозги с версионностью.

Цитата

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

Это видимо боль веберов или где-то там.

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

ну пойди на любой более менее популярный сайт и попробуй там зарегаться с неограниченной длины именем/емейлом/паролем/бог знает чем

а потом приходи и показывай, сколько ты таких мест нашел

я уже скидывал выше гмейл, самый популярный емейл провайдер в мире (наверное, мб сосет у аутлука, который по факту везде), имеет ограничение на ник в 30 ебаных символов

не 64, как положено по стандарту, а 30 блять