Разделение суток на часы вошло в употребление со времени появления в Риме солнечных часов (лат. horologium solarium) в 291 году до н. э.; в 164 году до н. э. в Риме ввели водяные часы (лат. solarium ex aqua). День, как и ночь, был разделён на 12 часов. В разное время года продолжительность одного часа дня и одного часа ночи менялась. День — это время от восхода до захода солнца, ночь — от захода до восхода солнца. В равноденствие день считался с 6 часов утра до 6 часов вечера, ночь — с 6 часов вечера до 6 часов утра.
enum? С какой стати? enum - это тип данных, допускающий установку одного из нескольких предопределённых значений. Например, [active, inactive]. Или [cart, address, deliver, payment]. Или [monday, tuesday, ..., sunday]. А записей в таблице может быть столько, сколько поддерживает СУБД. И у вас будут сотни миллионов active и миллиарды inactive. Ничто тут ничего уникально не идентифицирует.
Не улавливаю связи. Речь шла об использовании уникальных значений. Автору не нравятся строки, он предлагает использовать инты. Также, с разной эффективностью, можно было бы использовать float, decimal, uuid, да хоть битовые маски. То, что инты также могут использоваться в качестве первичных ключей - просто совпадение.
Следите за контекстом. Тред начался с формулировки
Например для колонки Пол (мужской, женский, не выбран).
И указанный код опубликован в этом треде. В этом контексте нет "другого", а в этом коде не указано, что поле с этим енамом может быть NULL. Из чего очевидный вывод: в этом коде other используется ВМЕСТО NULL.
Только тред начался с колонки "пол". Не социальный "гендер". Не грамматический "род". Обычный биологический "пол". Их у человеков всего два. И NULL для "неизвестно".
Есть списки неизменные, например, биологический пол: есть всего два варианта. А если изменяющиеся, например, гендер. И 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/.
Идея гораздо древнее японцев:
enum? С какой стати? enum - это тип данных, допускающий установку одного из нескольких предопределённых значений. Например, [active, inactive]. Или [cart, address, deliver, payment]. Или [monday, tuesday, ..., sunday]. А записей в таблице может быть столько, сколько поддерживает СУБД. И у вас будут сотни миллионов active и миллиарды inactive. Ничто тут ничего уникально не идентифицирует.
Не улавливаю связи. Речь шла об использовании уникальных значений. Автору не нравятся строки, он предлагает использовать инты. Также, с разной эффективностью, можно было бы использовать float, decimal, uuid, да хоть битовые маски. То, что инты также могут использоваться в качестве первичных ключей - просто совпадение.
Это очень хороший вопрос, но лучше задать его автору. Лично я догадался по обратным кавычкам в примерах запросов.
Следите за контекстом. Тред начался с формулировки
И указанный код опубликован в этом треде. В этом контексте нет "другого", а в этом коде не указано, что поле с этим енамом может быть NULL. Из чего очевидный вывод: в этом коде other используется ВМЕСТО NULL.
Используете postgres, а у автора mysql.
Только тред начался с колонки "пол". Не социальный "гендер". Не грамматический "род". Обычный биологический "пол". Их у человеков всего два. И NULL для "неизвестно".
Трудно представить ситуацию, в которой у вас найдётся 800 неизменяемых списков.
Да, в atlassian тоже так думают. А потом смотришь на список таблиц jira, а там
Но откуда вообще взялся PK? О нём в посте речи не шло.
Есть списки неизменные, например, биологический пол: есть всего два варианта. А если изменяющиеся, например, гендер. И 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/.