Есть списки неизменные, например, биологический пол: есть всего два варианта. А если изменяющиеся, например, гендер. И enum'ы, конечно, нужно использовать только для неизменных.
Vim использует одни и те же клавиши для управления и (очевидно) для ввода текста. Значит, между этими режимами нужно как минимум переключаться. Я вот пока набирал это сообщение, много раз попадал не туда пальцем, пользовался стрелками, удалял и вводил заново. Это же сколько раз нужно было бы переключаться туда-сюда... а если учесть что я и в командном режиме мог много раз опечатываться, то в итоге я вообще бы ничего не ввел. Стрелки прекрасны тем что они стоят отдельно, по ним очень сложно промазать, в отличие от буквенных клавиш.
Ваша ключевая ошибка в слове "нужно", из этого и неверные выводы. Не "нужно", а "можно". Вы можете перейти в режим ввода один раз и пользоваться только им, со стрелками и delete/backspace'ами. Даже ctrl-c/ctrl-v для этого режима можно настроить.
А разделение режимов в виме нужно для удобства. Он даёт больше, чем просто ввод. То есть им необязательно пользоваться, но если начать, то втягиваешься.
целочисленный PK не стоит использовать для сортировки
Сортировка по первичному ключу - занятие бессмысленное, абсолютно согласен, но какое это имеет отношение к обсуждаемым enum'ам?
Даже если отставить PK в сторону, то дело не в сортировке. В предложенном варианте с последовательными интами в базе невозможно добавить новое значение в середину списка, ибо оно должно будет переиспользовать существующий индекс, а значит, нужна миграция, которая сдвинет все индексы ниже. Это бесполезная, никому не нужная работа.
В реальном мире проблемы сквозной нумерации могут решаться увеличением порядка, пример: аудитории в учебных заведениях, типа 1xx на первом этаже, 2xx на втором и т.д. Т.е. сознательное создание дырок. Здесь можно применить тот же подход, но зачем, если можно просто не использовать инты?
Может возникнуть "для чего вставлять новое значение именно в середину". Ответ: потому что это требуется для решения задачи.
Конечно, не надо. Я бы и сам использовал енам. Но мой комментарий был не о поле, а о значении "не выбрано". Которое как раз и означает отсутствие значение, т.е. то, для чего в соседнем треде сделан костыль:
-- before
gender ENUM('man', 'woman')
-- after
gender ENUM('man', 'woman', 'other')
Вот этот other избыточен, если мы следуем формулировке "мужской/женский/не выбран". Причём "не выбран" - это вовсе не то же самое, что "предпочитаю не говорить" или "другой", ибо первое - это отсутствие значения, а второе - сознательный выбор пользователя.
Статья называется "Почему тип поля enum на уровне базы — зло", а на самом деле она о "Почему тип поля enum на уровне базы (*в Mysql* при использовании *PHP*) — зло"
Таким образом, тип полей enum в базе - это лютое зло.
Это инструмент. Как и любым инструментом, им нужно уметь пользоваться.
Также можно ответить на вопрос "почему integer, а не string": дело в том, что поля типа string подвержены грамматическим ошибкам и всё что они дают - лишь удобство чтения таких данных в одной конкретной таблице без использования SQL запросов. Но если в слове будет допущена ошибка или
Вообще непонятно. Как можно читать данные в таблице *без использования SQL запросов*? SELECT - это не SQL?
слово нужно будет заменить на другое - придётся отправлять запрос в базу, чего не нужно делать при использовании целочисленных значений.
Если что-то лежит, то налицо другая проблема, не связанная с архитектурой. Отказоустойчивость, высокая доступность, балансировка нагрузки - это отдельная дисциплина, в которую умеют сисадмины, но часто, увы, не умеют разработчики (хотя концепция DevOps и стремится обучить разработчиков самих поддерживать свои продукты)
Вдобавок, пользователи обычно привередливы, им не нужен продукт, работающий на 99%. Им нужен продукт, просто работающий. Если работает 9 микросервисов из 10, но лежит отвечающий за аутентификацию - продукт бесполезен, ибо пользователь просто не залогинится. Если лежит отвечающий за кеширование - продукт бесполезен, ибо пользователю надоест долго ждать ответа от сервиса, он плюнет и уйдёт. И т.д.
Продукт - это система, она должна работать вся целиком, чтобы приносить пользу.
За RoR ничего не скажу, потому как вопрос "микросервисы или монолит" к веб-фреймворку как-то слабо применим.
Фреймворк часто диктует архитектуру. Для PoC или MVP монолиты идеальны. Да, потом их можно разобрать на кусочки или даже в рамках того же монолита всё переделать так, что от изначального стиля фреймворка ничего не останется. Но изначально рельсы поощряют именно монолит.
Basecamp is a small team. As I mentioned, we have just 12 programmers
Хороший пример того, чего можно добиться, когда люди занимаются делом, а не жонглируют микросервисами в kubernetes :)
Basecamp действительно не показатель. Есть другие примеры рельсовых монолитов: github, spree, shopify. Кто-то потом ушёл в SOA, кто-то вообще в другие языки, а кто-то остался на рельсах и монолите. Яркий пример сейчас - gitlab: https://about.gitlab.com/company/history/.
Количество разрабов не говорит ни о чём. Они же не один продукт делают все вместе. Вполне может быть так, что есть какой-нибудь большой монолит на десятки или сотни человек, а рядом команды по два-три человека, которые делают крохотные приложения со специфичными задачами. Вот это хорошее приложение для микросервисов. В конце концов, микросервисы - это скорее про организацию работы, а не про архитектуру. Т.е. это в большей степени административная вещь.
Так и не понял, в чем беда микросервисов и выгода монолита?
В статье не рассматриваются плюсы и минусы микросервисов. Её мысль: хватит пихать микросервисы куда ни попадя, где надо и где не надо. Это не панацея, это инструмент для решения специфичных проблем в специфичных условиях. Как и любой другой инструмент.
Беда не в микросервисах как таковых, а в хайпе вокруг них. Так происходит с каждой технологией, до которой добираются маркетологи и начинают её продавать с пеной у рта, обещая решить все проблемы бизнеса, а заодно накормить голодающих в Африке и вылечить рак. Так было с микросервисами, так было с GraphQL, с NoSQL, с Elixir и так далее.
Как видели микросервисы опытные люди ещё в самом начале хайпа, можно почитать вот здесь, например: https://martinfowler.com/articles/microservices.html. Разумеется, прошедшие 10 лет дали больше пищи для размышления, но выводы верны до сих пор:
One reasonable argument we've heard is that you shouldn't start with a microservices architecture. Instead begin with a monolith, keep it modular, and split it into microservices once the monolith becomes a problem.
иихо самое глупое - это обвинять в ошибках проектирования архитектурный паттерн.
Если разработчик (а ещё лучше - тот, кто ставит ему задачи, вплоть до владельца бизнеса) понимает, что продукт нужно проектировать, то такой проблемы и не возникнет.
Прям вот ни капли не сомневаюсь, что у автора есть опыт поддержания монолитного сервиса, скажем так, с 60 разработчиками и 3кк строками кода в состоянии "согласованной команды и приложения".
Правильно делаете, ведь автор - создатель Ruby on Rails, basecamp.com и hey.com. Опыта работы с монолитами и командами для их создания у него больше, чем чуть менее чем у всех комментаторов на хабре
Тогда и Маяковского читать незачем, ведь у него словотворчество сплошь и рядом. А здесь безобиднее, автор ничего не выдумывал, а использовал широко известные мемы.
Олбанский тем и хорош, что он демонстративно искорёжен, так что его легко отличить от безграмотности. Например, "ниасилил" или "превед". Но никогда "подскажыте" или "в крации". Это - просто безграмотность.
Нет, совсем без даунтайма не обязательно. 5-10 минут может быть допустимо, часы - вряд ли. Речь о том, что обкатанные, проверенные временем быстрые способы типа `pg_upgrade --link` легко и просто работают на машинах. Но в контейнерах (а ещё лучше в кубе) это превращается в упражнения, без которых лучше бы обойтись. При этом проблема даже не в контейнерах как таковых: если данные хранятся локально, то контейнеры бесплатны с т.з. производительности (но не когнитивной нагрузки). Проблема в докере и его PID 1. С тем же LXC сложностей нет.
Поэтому я бы десять раз подумал, прежде чем применять докер для stateful нагрузок вообще и баз в частности.
Обновить версию докеризированной субд становится в разы проще.
Вы пробовали? Хотя бы постгрес. Хотя бы между соседними версиями. Допустим, 11 -> 12. Можно даже не слишком большую, гиг на 300. Просто чтобы pg_dump/pg_restore стал слишком долгим для использования в продакшене, где даунтайм имеет значение.
Следование этому пути делает традиционные CI-системы ненужными в рамках процесса разработки. Промежуточные звенья, такие как коммиты в удаленные Git-репозитории, сборочные машины, хранилище контейнеров (container registry) и так далее, больше не требуются
Следующий шаг - убрать лишние сущности типа Kubernetes и Syncthing и загружать код прямо на машины. Например, по FTP. Это делает традиционные CI-системы ненужными и обеспечивает просто феноменальную скорость работы. А в веб-разработке можно пойти и дальше и встраивать исполняемый код прямо в HTML страницы. Исключительно для удобства.
Есть списки неизменные, например, биологический пол: есть всего два варианта. А если изменяющиеся, например, гендер. И enum'ы, конечно, нужно использовать только для неизменных.
Ваша ключевая ошибка в слове "нужно", из этого и неверные выводы. Не "нужно", а "можно". Вы можете перейти в режим ввода один раз и пользоваться только им, со стрелками и delete/backspace'ами. Даже ctrl-c/ctrl-v для этого режима можно настроить.
А разделение режимов в виме нужно для удобства. Он даёт больше, чем просто ввод. То есть им необязательно пользоваться, но если начать, то втягиваешься.
Сортировка по первичному ключу - занятие бессмысленное, абсолютно согласен, но какое это имеет отношение к обсуждаемым enum'ам?
Даже если отставить PK в сторону, то дело не в сортировке. В предложенном варианте с последовательными интами в базе невозможно добавить новое значение в середину списка, ибо оно должно будет переиспользовать существующий индекс, а значит, нужна миграция, которая сдвинет все индексы ниже. Это бесполезная, никому не нужная работа.
В реальном мире проблемы сквозной нумерации могут решаться увеличением порядка, пример: аудитории в учебных заведениях, типа 1xx на первом этаже, 2xx на втором и т.д. Т.е. сознательное создание дырок. Здесь можно применить тот же подход, но зачем, если можно просто не использовать инты?
Может возникнуть "для чего вставлять новое значение именно в середину". Ответ: потому что это требуется для решения задачи.
Конечно, не надо. Я бы и сам использовал енам. Но мой комментарий был не о поле, а о значении "не выбрано". Которое как раз и означает отсутствие значение, т.е. то, для чего в соседнем треде сделан костыль:
Вот этот
otherизбыточен, если мы следуем формулировке "мужской/женский/не выбран". Причём "не выбран" - это вовсе не то же самое, что "предпочитаю не говорить" или "другой", ибо первое - это отсутствие значения, а второе - сознательный выбор пользователя.Статья называется "Почему тип поля enum на уровне базы — зло", а на самом деле она о "Почему тип поля enum на уровне базы (*в Mysql* при использовании *PHP*) — зло"
Это инструмент. Как и любым инструментом, им нужно уметь пользоваться.
Вообще непонятно. Как можно читать данные в таблице *без использования SQL запросов*? SELECT - это не SQL?
Удачи в изменении порядка значений.
true, false, NULL. Или false, true, NULL, кому как больше нравится.
awk - это не текстовый редактор. `man gawk` говорит нам, что это `pattern scanning and processing language`.
А текстовый редактор - это vim или emacs (или даже vim+emacs, как в doom emacs). И их пользователи редактируют через них очень часто.
Если что-то лежит, то налицо другая проблема, не связанная с архитектурой. Отказоустойчивость, высокая доступность, балансировка нагрузки - это отдельная дисциплина, в которую умеют сисадмины, но часто, увы, не умеют разработчики (хотя концепция DevOps и стремится обучить разработчиков самих поддерживать свои продукты)
Вдобавок, пользователи обычно привередливы, им не нужен продукт, работающий на 99%. Им нужен продукт, просто работающий. Если работает 9 микросервисов из 10, но лежит отвечающий за аутентификацию - продукт бесполезен, ибо пользователь просто не залогинится. Если лежит отвечающий за кеширование - продукт бесполезен, ибо пользователю надоест долго ждать ответа от сервиса, он плюнет и уйдёт. И т.д.
Продукт - это система, она должна работать вся целиком, чтобы приносить пользу.
Вам известно, а кому-то нужно повторять снова и снова. Что автор и делает. По моему мнению, больше даже не для инженеров, а для бизнесменов.
Фреймворк часто диктует архитектуру. Для PoC или MVP монолиты идеальны. Да, потом их можно разобрать на кусочки или даже в рамках того же монолита всё переделать так, что от изначального стиля фреймворка ничего не останется. Но изначально рельсы поощряют именно монолит.
Хороший пример того, чего можно добиться, когда люди занимаются делом, а не жонглируют микросервисами в kubernetes :)
Basecamp действительно не показатель. Есть другие примеры рельсовых монолитов: github, spree, shopify. Кто-то потом ушёл в SOA, кто-то вообще в другие языки, а кто-то остался на рельсах и монолите. Яркий пример сейчас - gitlab: https://about.gitlab.com/company/history/.
Количество разрабов не говорит ни о чём. Они же не один продукт делают все вместе. Вполне может быть так, что есть какой-нибудь большой монолит на десятки или сотни человек, а рядом команды по два-три человека, которые делают крохотные приложения со специфичными задачами. Вот это хорошее приложение для микросервисов. В конце концов, микросервисы - это скорее про организацию работы, а не про архитектуру. Т.е. это в большей степени административная вещь.
В статье не рассматриваются плюсы и минусы микросервисов. Её мысль: хватит пихать микросервисы куда ни попадя, где надо и где не надо. Это не панацея, это инструмент для решения специфичных проблем в специфичных условиях. Как и любой другой инструмент.
Беда не в микросервисах как таковых, а в хайпе вокруг них. Так происходит с каждой технологией, до которой добираются маркетологи и начинают её продавать с пеной у рта, обещая решить все проблемы бизнеса, а заодно накормить голодающих в Африке и вылечить рак. Так было с микросервисами, так было с GraphQL, с NoSQL, с Elixir и так далее.
Как видели микросервисы опытные люди ещё в самом начале хайпа, можно почитать вот здесь, например: https://martinfowler.com/articles/microservices.html. Разумеется, прошедшие 10 лет дали больше пищи для размышления, но выводы верны до сих пор:
Если разработчик (а ещё лучше - тот, кто ставит ему задачи, вплоть до владельца бизнеса) понимает, что продукт нужно проектировать, то такой проблемы и не возникнет.
Правильно делаете, ведь автор - создатель Ruby on Rails, basecamp.com и hey.com. Опыта работы с монолитами и командами для их создания у него больше, чем чуть менее чем у всех комментаторов на хабре
Удивительное совпадение https://www.eia.gov/dnav/ng/hist/n9133us2M.htm
Тогда и Маяковского читать незачем, ведь у него словотворчество сплошь и рядом. А здесь безобиднее, автор ничего не выдумывал, а использовал широко известные мемы.
Олбанский тем и хорош, что он демонстративно искорёжен, так что его легко отличить от безграмотности. Например, "ниасилил" или "превед". Но никогда "подскажыте" или "в крации". Это - просто безграмотность.
Но причём тут NEOvim? Всё это есть в Vim из 1991 года, а многое - в Vi из 1976. Собственно,
vimtutorНет, совсем без даунтайма не обязательно. 5-10 минут может быть допустимо, часы - вряд ли. Речь о том, что обкатанные, проверенные временем быстрые способы типа `pg_upgrade --link` легко и просто работают на машинах. Но в контейнерах (а ещё лучше в кубе) это превращается в упражнения, без которых лучше бы обойтись. При этом проблема даже не в контейнерах как таковых: если данные хранятся локально, то контейнеры бесплатны с т.з. производительности (но не когнитивной нагрузки). Проблема в докере и его PID 1. С тем же LXC сложностей нет.
Поэтому я бы десять раз подумал, прежде чем применять докер для stateful нагрузок вообще и баз в частности.
Вы пробовали? Хотя бы постгрес. Хотя бы между соседними версиями. Допустим, 11 -> 12. Можно даже не слишком большую, гиг на 300. Просто чтобы pg_dump/pg_restore стал слишком долгим для использования в продакшене, где даунтайм имеет значение.
Следующий шаг - убрать лишние сущности типа Kubernetes и Syncthing и загружать код прямо на машины. Например, по FTP. Это делает традиционные CI-системы ненужными и обеспечивает просто феноменальную скорость работы. А в веб-разработке можно пойти и дальше и встраивать исполняемый код прямо в HTML страницы. Исключительно для удобства.