Тут на книгу наберется ) Кое что из этого уже в процессе. Следующими будут локи и атомики. Дальше посмотрим, но некоторые темы вообще не планировал. Спасибо, постараюсь затронуть по максимуму.
Тут острая тема, мое мнение — не глупый. На мой взгляд, именно непонимание, какие задачи решает многопоточность (компьютеры, авиация, композиция, паттерны, нормализация, денормализация, ваш вариант) рождает неправильное, неоправданное или вообще бездумное их применение.
Личное мнение (возможно очень субьективное): чем больше человек понимает суть вещей с которыми работает — тем более он для меня синьор и тем более он для меня авторитет, потому что он потратил время и силы чтобы разобраться и способен обосновать принятое решение.
В конце концов есть задачи, только одним из вариантов решения которых есть рименение цифровой вычислительной техники, в то время как другие решения (например, аналоговые устройства) будут дешевле и эффективнее.
Как то так получилось многослов. В свое оправдание замечу что многие известные мне так называемые синьоры при вопросе «Зачем нужна многопоточность» падают в осадок
Если рубрикатор, то Google вы не сможете разбить на G и oogle, бо второе не имеет смысла. Хотя случай интересный, это как раз случай когда нормализация не имеет смысла. Хранить и поддерживать связь Буква — Сайт будет намного дороже, чем вычислять эту связь из списка сайтов.
Тут надо задать вопрос можете ли вы использовать части по отдельности? Если да — значение неатомарно и нужно его разделить (разнести либо по разным колонкам либо по строкам).
Например буквы из значения 'Ваня' не несут никакой смысловой нагрузки, они по отдельности вам не нужны, поэтому Ваня — неделим.
«Аня, Саша» можно разбить на «Аня» и «Саша», каждая часть которого имеет смысл для вас или приложения, поэтому это неатомарное значение.
Критерием отбора служит не часть слова, а истинность выражения kids LIKE 'С%', то есть 'С%' в запросе — это не значение, это просто параметр оператору.
Вообще вопрос упирается чисто в здравый смысл. Если по смыслу у вас тип колонки — координаты, то бессмысленно их разбивать если вы их всегда будете трактовать только вместе. З другой стороны, если вы будете оперировать координатами по отдельности, для приложения и для вас отдельная координата будет иметь смысл и следует их разбить.
Если у вас по смыслу в поле строка, то на буквы естественно делить ее не нужно, потому что для большинства задач, буквы не несут смысловой нагрузки.
Очень интересно в плане, что уже начал гуглить на тему. Вопрос фанатизма в применении таких штук (номализация, паттерны) тоже довольно остро стоит. Поверьте, мне интересно. Статью пока не обещаю, но кто знает.
На самом деле, то что многие понимают интуитивно, они на самом деле понимают так как им обьяснили другие. Это как испорченный телефон, который через умыи и слова других передал все в чей то мозг, то есть по сути человек принял чтото на веру.
Он может угадать в своей интуиции, а может и не угадать, тут как повезет. Мне, если честно, непонятно как человек будет проводить декомпозицию доменной области, если он не понимает понятий функциональной зависимости, потенциальных ключей и возможных последствий своих действий.
Замечательно, а что если данные в записи будут разнородные, а что если вам нужно отсортировать всех деток по именам, а что если…?
В каждом случае приходится применять какие то решения выходящие за рамки обычного SQL — либо функцию использовать, либо запрос усложнить, либо упростить таблицу.
Кроме того, вы еще можете пожелать построить связи между таблицами, например заставить каждого ребенка ходить в детсад и хранить эту информацию в другой таблице. А связать как?
Он мощный еще и потому что авторы так тщательно продумывают спеку, создают прочный и надежный фундамент. Иначе был бы через лет 5 такой хаос, что Гослинг бы застрелился
Если честно меня не особо радуют многие изменения, AutoCloseable явно плюс, switch по строкам красота, а вот несколько ексепшенов в блоке try выглядят ужасно, учитывая что в уме еще надо найти общий потомок и влепить уже третий класс в такой крошечный кусочек кода. Остальное, не более чем синтаксический сахар без особой пользы. но неоправданно нагружающий мозг как новичка при обучении, так и опытного, который предвкушает чтение такого кода
На современный широкоформатных мониторах комбинация fullscreen и Ctrl+M приведет к особо тяжелому случаю нерационально использованного пространства. Мне даже удобно, что код находится по одну сторону монитора, а все панели как бы вне поля зрения, но легко обозримы.
Как по мне если монитор уж не совсем крохотных то текста там вполне достаточно помещается (если что Ctrl+M решает), а панельки и рюшечки не для неудобства сделаны, в конце концов в IDE вы не тольео код набираете, а еще делаете кучу разноплановых вещей.
Личное мнение (возможно очень субьективное): чем больше человек понимает суть вещей с которыми работает — тем более он для меня синьор и тем более он для меня авторитет, потому что он потратил время и силы чтобы разобраться и способен обосновать принятое решение.
В конце концов есть задачи, только одним из вариантов решения которых есть рименение цифровой вычислительной техники, в то время как другие решения (например, аналоговые устройства) будут дешевле и эффективнее.
Например буквы из значения 'Ваня' не несут никакой смысловой нагрузки, они по отдельности вам не нужны, поэтому Ваня — неделим.
«Аня, Саша» можно разбить на «Аня» и «Саша», каждая часть которого имеет смысл для вас или приложения, поэтому это неатомарное значение.
Критерием отбора служит не часть слова, а истинность выражения kids LIKE 'С%', то есть 'С%' в запросе — это не значение, это просто параметр оператору.
Вообще вопрос упирается чисто в здравый смысл. Если по смыслу у вас тип колонки — координаты, то бессмысленно их разбивать если вы их всегда будете трактовать только вместе. З другой стороны, если вы будете оперировать координатами по отдельности, для приложения и для вас отдельная координата будет иметь смысл и следует их разбить.
Если у вас по смыслу в поле строка, то на буквы естественно делить ее не нужно, потому что для большинства задач, буквы не несут смысловой нагрузки.
Он может угадать в своей интуиции, а может и не угадать, тут как повезет. Мне, если честно, непонятно как человек будет проводить декомпозицию доменной области, если он не понимает понятий функциональной зависимости, потенциальных ключей и возможных последствий своих действий.
В каждом случае приходится применять какие то решения выходящие за рамки обычного SQL — либо функцию использовать, либо запрос усложнить, либо упростить таблицу.
Кроме того, вы еще можете пожелать построить связи между таблицами, например заставить каждого ребенка ходить в детсад и хранить эту информацию в другой таблице. А связать как?
А выпускникам ЦПШ все равно не понять, так что вы на них не обижайтесь :)
Если честно меня не особо радуют многие изменения, AutoCloseable явно плюс, switch по строкам красота, а вот несколько ексепшенов в блоке try выглядят ужасно, учитывая что в уме еще надо найти общий потомок и влепить уже третий класс в такой крошечный кусочек кода. Остальное, не более чем синтаксический сахар без особой пользы. но неоправданно нагружающий мозг как новичка при обучении, так и опытного, который предвкушает чтение такого кода
Как по мне если монитор уж не совсем крохотных то текста там вполне достаточно помещается (если что Ctrl+M решает), а панельки и рюшечки не для неудобства сделаны, в конце концов в IDE вы не тольео код набираете, а еще делаете кучу разноплановых вещей.
А вообще на вкус и цвет колбаса разная