Comments 15
А зачем Вы в качестве перевода слова «constraint» используете новояз «констрейнт», если всегда со времен IBM 360/370 оно переводилось как «ограничение»?
Я согласен, что слово «констрейнт» звучит диковато, но оно очень часто фигурирует в разговорах разработчиков. Наверно потому, что слово «ограничение» — слишком общее. Например: «Ограничения postgresql». Приходится уточнять, что имеются в виду constraints, а не то, что база какая-то ограниченная, убогая. Так что я даже не знаю. Давайте считать, что статья написана в разговорном жанре :)
Хотя ваши аргументы мне совершенно понятны
Хотя ваши аргументы мне совершенно понятны
В посгресе, кстати, тоже так можно сделать, но вручную, командой CLUSTER. Но обычно в этом нет необходимостиМожно пояснить этот момент — в кластерном ключе нет необходимости?
Врать не буду, не знаю точно.
Но мы работаем в тандеме с несколькими профессиональными DBA на высоконагруженных базах. Ни разу они еще не советовали кластерные индексы. Видимо они нужны в каких-то особых случаях, или с ними возни больше, чем пользы.
Но мы работаем в тандеме с несколькими профессиональными DBA на высоконагруженных базах. Ни разу они еще не советовали кластерные индексы. Видимо они нужны в каких-то особых случаях, или с ними возни больше, чем пользы.
Говорят, что в основном это нужно на таблицах, которые редко меняются.
Например, можно использовать для партиционированных таблиц, либо таблиц с геоданными
Например, можно использовать для партиционированных таблиц, либо таблиц с геоданными
Нарисую пример при котором важен кластерный индекс: допустим у вас таблица Users, в нем есть поле LastLoginDate. Пользователей у которых LastLoginDate меньше месяца назад — всего 10%, поэтому они разбросаны по таблице. но ДБ не загружает конкретные строки, она загружает данные блоками, тоесть вам понадобилась одна строчка из блока — а загрузиться весь блок, и в нем 90% не нужных вам пользователей. При помощи кластера вы можете отстортировать таких пользователей по LastLoginDate и тогда ДБ будет работать эффективнее.
Антон, статья неплохая и судя по теме предназначена для начинающих программистов. Однако русский язык, используемый в описании примеров, только путает.
Английское слово «constraint» имеет аналог в русском языке «ограничитель» и уместно в заголовке написать «Ограничители(constraints) PostgreSQL», а затем после двоеточия их перечислить и поставить точку.
Кастомные логично поменять на «свои подтипы», тем более, что «свои» используете в объяснении.
2. Check (особенно актуально для проверки jsonb и hstore)
«Проверка оператором Сheck(актуально для jsonb и hstore)» звучит лучше.
Бывает важно обвешать чеками универсальные типы данных,…
«Не забывайте проверять универсальные типы данных, как jsonb и hstore,… » понятнее.
При вставке опять же есть некоторый оверхед, потому что при каждой вставке СУБД вынуждена лочить довольно много вещей.
«При каждой вставке СУБД вынуждена делать много избыточных операций» — проще и яснее.
Или в таблице с товарами можно поставить check (price > 0), тогда вы не будете продавать ноуты по 0 рублей. логично заменить на
«Или в таблице с товарами поставьте check (price > 0), чтобы не продать дорогой товар по 0 рублей.»
В статье нет смысла постоянно повторять название СУБД по-английски, а затем в русской фонетической транскрипции. Ясно по названию статьи о какой СУБД идет речь.
Успехов.
Английское слово «constraint» имеет аналог в русском языке «ограничитель» и уместно в заголовке написать «Ограничители(constraints) PostgreSQL», а затем после двоеточия их перечислить и поставить точку.
Кастомные логично поменять на «свои подтипы», тем более, что «свои» используете в объяснении.
2. Check (особенно актуально для проверки jsonb и hstore)
«Проверка оператором Сheck(актуально для jsonb и hstore)» звучит лучше.
Бывает важно обвешать чеками универсальные типы данных,…
«Не забывайте проверять универсальные типы данных, как jsonb и hstore,… » понятнее.
При вставке опять же есть некоторый оверхед, потому что при каждой вставке СУБД вынуждена лочить довольно много вещей.
«При каждой вставке СУБД вынуждена делать много избыточных операций» — проще и яснее.
Или в таблице с товарами можно поставить check (price > 0), тогда вы не будете продавать ноуты по 0 рублей. логично заменить на
«Или в таблице с товарами поставьте check (price > 0), чтобы не продать дорогой товар по 0 рублей.»
В статье нет смысла постоянно повторять название СУБД по-английски, а затем в русской фонетической транскрипции. Ясно по названию статьи о какой СУБД идет речь.
Успехов.
Спасибо. Я подумаю над этим (правда, чуть позже, сейчас нет времени совсем). Меня самого немного раздражает смесь русских и английских слов. Я бы использовал только русский язык, но боюсь, что с нетоторой вероятностью меня поймут хуже. Взять то же слово «ограничитель». Оно действиетльно отражает суть. Но спросите какого-нибудь разработчика: «ты тут поставил ограничитель»? Он будет дольше соображать, чем после вопроса «ты поставил constraint»?
Впрочем, постараюсь хотя бы немного улучшить ситуацию, если не в этой статье, то в следующей. По крайней мере, наверно не стоит писать constraint русскими буквами. Тогда это сойдет за оператор, к которому не придерешься
Впрочем, постараюсь хотя бы немного улучшить ситуацию, если не в этой статье, то в следующей. По крайней мере, наверно не стоит писать constraint русскими буквами. Тогда это сойдет за оператор, к которому не придерешься
О. это извечная проблема. Особенно при переводе статей. Назовешь по-русски — теряется смысл, по-английски — выбивается из текста. Получается замкнутый круг из мучений и компромиссов с самим собой.
Это точно) Поэтому я в своих переводах, для случаев возможной потери смысла, рядом с русским переводом в скобках указываю английский оригинал, а иногда и ссылку на Вики например. Получается что-то типа: "1. Хорошая совместимость с мультиарендностью (multi-tenancy)"
Взять то же слово «ограничитель». Оно действиетльно отражает суть. Но спросите какого-нибудь разработчика: «ты тут поставил ограничитель»? Он будет дольше соображать, чем после вопроса «ты поставил constraint»?
Вы правильно делаете, написав термин на русском и дав в круглых скобках его название на английском языке. После этого вправе употреблять термин на русском без ограничений в статье. Это хороший стиль.
Постоянно используете в деятельности профессиональный сленг и переход на простой язык закономерно вызывает торможение у специалиста. Однако профессионал всегда должен уметь объяснить простым и доступным языком сложные вещи.
Для меня был примером преподаватель по теоретической механике, который приводил аналогии, что вбивал основы на всю жизнь простыми примерами. Например, даже иностранцы запоминали надолго, что такое момент кручения, когда он сказал: «Была бы пара — момент найдется» :-)
Успехов.
Вы правильно делаете, написав термин на русском и дав в круглых скобках его название на английском языке. После этого вправе употреблять термин на русском без ограничений в статье. Это хороший стиль.
Постоянно используете в деятельности профессиональный сленг и переход на простой язык закономерно вызывает торможение у специалиста. Однако профессионал всегда должен уметь объяснить простым и доступным языком сложные вещи.
Для меня был примером преподаватель по теоретической механике, который приводил аналогии, что вбивал основы на всю жизнь простыми примерами. Например, даже иностранцы запоминали надолго, что такое момент кручения, когда он сказал: «Была бы пара — момент найдется» :-)
Успехов.
Посмотрел на теги внизу и нашёл родственную душу — я всегда делаю такую же ошибку в написании слова deferrable ;) и только написав вспоминаю, что где-то был капкан.
Sign up to leave a comment.
Ограничения (сonstraints) PostgreSQL: exclude, частичный unique, отложенные ограничения и др