Я упорядочиваю столбцы по их функционалу для того, чтобы снизить когнитивную нагрузку при работе с данными, а вы предлагаете насоздавать вьюшек на каждую большую таблицу, чтобы потом следить за соответствием этих вьюшек таблицам. Я не враг себе, мне такие костыли не нужны.
Плюс к этой процедуре надо написать интерфейс для удобного редактирования структуры таблицы, чтобы можно было драгдропом поменять местами колонки. Потом механизм сопоставления версий структур данных для генерации миграций. Ну и сразу удобный data management, чтобы можно было в одном месте и данные в таблице поменять )
Хорошая идея. Я этим как раз и занимаюсь. Но это дорого и долго.
Очень странный аргумент. Почему базу данных должен беспокоить простой бизнеса? Это вообще не её, базаданново дело. Она понятия не имеет, используются эти таблицы или нет. Насколько критичен простой именно сейчас, и вообще может быть сейчас выходной.
БД - инструмент разработчика. Разработчик делает инструмент для бизнеса. И позвольте разработчику самому решать, какая должна быть структура данных.
Я часто работаю с "сырыми" данными в sql, когда надо быстро посмотреть, в каком состоянии находятся объекты. Иногда таблицы довольно большие, 20, 30 и иногда 100+ столбцов. Мне УДОБНО, когда столбцы, относящиеся к одному функционалу находятся рядом, тогда не приходится скроллить таблицу или изобретать вьюшки на каждый случай. А на каждый случай вьюшек не напасёшься.
О, как. MySql оказывается несерьёзная. И в каком месте она несерьёзная?
Если стоит задача хранить реляционные данные и получать к ним доступ, то чем плоха MySql? Я вот по наивности считал, что именно хранение данных - это первейшая задача СУБД.
Тот же оракл не имеет интовых типов данных. Да, там есть INTEGER, для совместимости с SQL'92, но это тот же самый number(0, 38). То есть число с переменной длиной, которое не запихнёшь с гарантией ни в один из типов современных бэкенд-языков. Это признак серьёзности?
Да, ни оракл, ни постгрес, ни mssql не умеют в add column after. У всех отмазка "ну это чтобы не пересоздавать таблицу". Мне пофиг на пересоздание, у меня там три записи (или вообще нет ни одной). Почему я не могу встроенным синтаксисом вставить столбец куда мне надо? Да, мне это важно, потому что я сортирую столбцы по их назначению. Мне потом их проще искать.
Почему у оракла 30к символов ограничение в nvarchar (при флаге extended, без него 12к)? Это из серии "640кб хватит всем"? Не, я понимаю, что можно пихать текст в блобы, никто вроде не запрещает. Но у того же мускуля 64к символов в TEXT и 4ккк символов в LONGTEXT. Неужели сложно?
20+ лет назад там был myisam, так что неудивительно. Да, был был быстрый инсерт, но в ущерб надёжности, транзакционности и прочим "ненужным" вещам. Сейчас с InnoDb всё примерно как у всех. Зависит от сценария, ключей, индексов, хранилища, памяти.
По своему опыту ормостроения я понял, что для разных случаев нужны разные уровни доступа к данным. От SQL всё равно не уйти, но это не значит, что ORM не нужен.
задача "Object-Relational Mapping" решения не имеет
Небольшая поправка: не имеет решения для общего случая. Как и задача сжатия данных. Но алгоритмами сжатия пользуются
Невозможно найти единственно правильный баланс между eager- и lazy-загрузкой
Вот меня удивляет, что в гибернейте eager/lazy прибиты гвоздями в описании структуры данных. А EF тем временем позволяет явно подключать джойном данные в рантайме с помощью .Include() для каждого запроса индивидуально.
Спасибо за статью, это мотивирует самого что-то написать. Давно хотел рассказать про свою ORM, где "базы данных не существует".
Ещё как зависит. Если датчик замыкает контакты, то при матричном расположении ты хоть что делай, будет эффект ложного нажатия. Но при той же матрице в оптомеханике такой проблемы нет. Почему? Потому что ряды сканируются последовательно. Датчик активный. То же самое и с холлом.
Вообще-то это много. Очень много. Это 1/8 секунды или 8 кадров при 60 fps.
Я давно хочу клавиатуру на магнитных свичах и герконах, такая была у меня в 90х годах. Это беспрецедентная надёжность, тишина хода и мягкость нажатия. Но мир свернул не туда, популярными стали именно механические клавиатуры.
Да, тут не герконы, а датчики холла. Действительно интереснее, можно регистрировать скорость нажатия (как на миди-клавиатурах). Правда зачем - вопрос открытый. Может чтобы капсом кричать.
Датчики холла должны (при грамотной реализации) ещё одно преимущество иметь. Возможность поочерёдного скана блоков клавиш. Что исключает фантомные срабатывания "AS" + "W" = "Q". Как на оптомеханике.
Я бы взял... Но исполнение... Всратый дизайн, полное отсутствие F блока, эскейп на "Ё", нет ни стрелок, ни нампада. Ни. Че. Го.
Хороший разработчик в первую очередь должен уметь писать хороший код.
Очень хороший разработчик должен уметь писать плохой код. С полным пониманием того, какие углы срезал и какой ценой. Собственно, чтобы осмысленно писать плохой код, надо сначала научиться писать хороший. А чтобы научиться писать хороший код, надо написать много плохого. Собственно, Programming, Motherf*cker
Сама идея добавлять аннотации выглядит как костыль для непродуманной технологии. Сами анализаторы могут поменяться, в них могут внедрить AI или что там модно будет. А аннотации останутся в исходниках. И в привычках мейнтейнеров (которые ещё поменять надо будет).
Моё мнение - тут надо искать zero cost решение. Всё по той же причине, про которую говорил Торвальдс - не надо дополнительной когнитивной нагрузки на мейнтейнеров. Им и так тяжело.
Плюс психологический такой фактор. Ты профи, работаешь двадцать лет с кодом, а тебя какой-то санитайзер заставляет расписаться, что ты точно знаешь, что тут может быть переполнение. Серьёзно?
Торвальдс и не должен предлагать решение. Представьте, что в вашу работу постоянно лезут с идиотскими "оптимизациями", не зная, как это всё работает. А на ваши аргументы предлагают вам самим решить проблему.
Вообще-то Торвальдс прав и вполне внятно обосновал свою точку зрения. Если делаете инструмент, то от него должно быть больше пользы, чем вреда. Он даже расписал, в каких конкретных случаях переполнение используется осмысленно.
Существуют всяческие анализаторы кода, которые становятся умнее и умнее. Я не вижу какой-то принципиальной проблемы, чтобы научить анализатор правильно обрабатывать намеренные переполнения, имея перед собой паттерны их применения.
В таких разработках, как разработка компилятора, в первую очередь заботятся об обратной совместимости, потому что никому не надо переписывать то, на что потрачены тысячи человеко-лет. Я так понял, что Кис предлагает сломать совместимость. Вот только за это я бы его подальше ещё послал.
Может быть действительно, не стоит трогать компилятор и добавить статический анализатор в воркфлоу.
Вот удивляюсь с людей, которые ноут приравнивают к компьютеру. Я вот привык к десктопу, к его полноценным мониторам, клавиатурам, мышам. Можно, конечно, это всё подключить и к ноуту. Но он же будет выть как зараза, сводя на нет все преимущества бесшумности.
Ну и плоская клавиатура на мой вкус фу. Я такое не ем.
А зачем тогда корпус переделывать? Просто отпиливаем дисплей и получаем готовый системный блок. Жёсткость уже за нас инженеры рассчитали и применили нужные материалы. Бонусом имеем встроенный бесперебойник, встроенную клавиатуру и тачпад.
Был бы экран, вообще можно было бы пользоваться автономно...
Лень ещё как существует. Мы миллионами лет были рептилиями и каких-то 10 тыс лет назад у нас появилась перфронтальная кора головного мозга, что по меркам эволюции - секунды. Именно она отвечает за долгосрочное планирование жизни и дела, которые помогут в будущем. Если она рептилию победит, конечно. Рептилия хочет жрат и спат.
Вот когда побеждает рептилия, это и называется лень. Мы делаем то, что делают рептилии - экономим силы и запасаем жиры и делаем это в ущерб своему будущему, прекрасно об этом зная.
При рассмотрении приложения в комплексе, внезапно оказывается, что функционально неполная абстракция - это именно что SQL. Именно SQL ограничен декларативной парадигмой, а сверхсложную логику пишут на языках общего назначения.
ORM в следствии своей парадигмы, толкает на написание работы с данными внутри кода, что приводит цельности логики и его дальнейшему рефакторингу.
Про безопасность - это вообще не к орм. Просто потому что орм - маппер. То, что он умеет генерировать sql, не накладывает на него обязанность следить за уязвимостями протоколов. И вообще обычно канал orm-db защищён по умолчанию.
ролевые модели в БД умеют генерировать
Кхм. С этого места пожалуйста поподробнее. Мне кажется, что мне вас есть чем приятно удивить.
Я упорядочиваю столбцы по их функционалу для того, чтобы снизить когнитивную нагрузку при работе с данными, а вы предлагаете насоздавать вьюшек на каждую большую таблицу, чтобы потом следить за соответствием этих вьюшек таблицам. Я не враг себе, мне такие костыли не нужны.
Плюс к этой процедуре надо написать интерфейс для удобного редактирования структуры таблицы, чтобы можно было драгдропом поменять местами колонки. Потом механизм сопоставления версий структур данных для генерации миграций. Ну и сразу удобный data management, чтобы можно было в одном месте и данные в таблице поменять )
Хорошая идея. Я этим как раз и занимаюсь. Но это дорого и долго.
Очень странный аргумент. Почему базу данных должен беспокоить простой бизнеса? Это вообще не её, базаданново дело. Она понятия не имеет, используются эти таблицы или нет. Насколько критичен простой именно сейчас, и вообще может быть сейчас выходной.
БД - инструмент разработчика. Разработчик делает инструмент для бизнеса. И позвольте разработчику самому решать, какая должна быть структура данных.
Я часто работаю с "сырыми" данными в sql, когда надо быстро посмотреть, в каком состоянии находятся объекты. Иногда таблицы довольно большие, 20, 30 и иногда 100+ столбцов. Мне УДОБНО, когда столбцы, относящиеся к одному функционалу находятся рядом, тогда не приходится скроллить таблицу или изобретать вьюшки на каждый случай. А на каждый случай вьюшек не напасёшься.
MySql делает это ТОЧНО через пересоздание таблицы. Что я прекрасно знаю и это меня ничуть не волнует.
О, как. MySql оказывается несерьёзная. И в каком месте она несерьёзная?
Если стоит задача хранить реляционные данные и получать к ним доступ, то чем плоха MySql? Я вот по наивности считал, что именно хранение данных - это первейшая задача СУБД.
Тот же оракл не имеет интовых типов данных. Да, там есть INTEGER, для совместимости с SQL'92, но это тот же самый number(0, 38). То есть число с переменной длиной, которое не запихнёшь с гарантией ни в один из типов современных бэкенд-языков. Это признак серьёзности?
Да, ни оракл, ни постгрес, ни mssql не умеют в add column after. У всех отмазка "ну это чтобы не пересоздавать таблицу". Мне пофиг на пересоздание, у меня там три записи (или вообще нет ни одной). Почему я не могу встроенным синтаксисом вставить столбец куда мне надо? Да, мне это важно, потому что я сортирую столбцы по их назначению. Мне потом их проще искать.
Почему у оракла 30к символов ограничение в nvarchar (при флаге extended, без него 12к)? Это из серии "640кб хватит всем"? Не, я понимаю, что можно пихать текст в блобы, никто вроде не запрещает. Но у того же мускуля 64к символов в TEXT и 4ккк символов в LONGTEXT. Неужели сложно?
20+ лет назад там был myisam, так что неудивительно. Да, был был быстрый инсерт, но в ущерб надёжности, транзакционности и прочим "ненужным" вещам. Сейчас с InnoDb всё примерно как у всех. Зависит от сценария, ключей, индексов, хранилища, памяти.
По своему опыту ормостроения я понял, что для разных случаев нужны разные уровни доступа к данным. От SQL всё равно не уйти, но это не значит, что ORM не нужен.
Небольшая поправка: не имеет решения для общего случая. Как и задача сжатия данных. Но алгоритмами сжатия пользуются
Вот меня удивляет, что в гибернейте eager/lazy прибиты гвоздями в описании структуры данных. А EF тем временем позволяет явно подключать джойном данные в рантайме с помощью .Include() для каждого запроса индивидуально.
Спасибо за статью, это мотивирует самого что-то написать. Давно хотел рассказать про свою ORM, где "базы данных не существует".
Теперь российские ютуберы с рекламы не получают денег. Вы в этом ничего плохого не видите?
Так быстрее или не быстрее?
Ещё как зависит. Если датчик замыкает контакты, то при матричном расположении ты хоть что делай, будет эффект ложного нажатия. Но при той же матрице в оптомеханике такой проблемы нет. Почему? Потому что ряды сканируются последовательно. Датчик активный. То же самое и с холлом.
Да, извиняюсь, не заметил порядок
Вообще-то это много. Очень много. Это 1/8 секунды или 8 кадров при 60 fps.
Я давно хочу клавиатуру на магнитных свичах и герконах, такая была у меня в 90х годах. Это беспрецедентная надёжность, тишина хода и мягкость нажатия. Но мир свернул не туда, популярными стали именно механические клавиатуры.
Да, тут не герконы, а датчики холла. Действительно интереснее, можно регистрировать скорость нажатия (как на миди-клавиатурах). Правда зачем - вопрос открытый. Может чтобы капсом кричать.
Датчики холла должны (при грамотной реализации) ещё одно преимущество иметь. Возможность поочерёдного скана блоков клавиш. Что исключает фантомные срабатывания "AS" + "W" = "Q". Как на оптомеханике.
Я бы взял... Но исполнение... Всратый дизайн, полное отсутствие F блока, эскейп на "Ё", нет ни стрелок, ни нампада. Ни. Че. Го.
Очень хороший разработчик должен уметь писать плохой код. С полным пониманием того, какие углы срезал и какой ценой. Собственно, чтобы осмысленно писать плохой код, надо сначала научиться писать хороший. А чтобы научиться писать хороший код, надо написать много плохого. Собственно, Programming, Motherf*cker
Сама идея добавлять аннотации выглядит как костыль для непродуманной технологии. Сами анализаторы могут поменяться, в них могут внедрить AI или что там модно будет. А аннотации останутся в исходниках. И в привычках мейнтейнеров (которые ещё поменять надо будет).
Моё мнение - тут надо искать zero cost решение. Всё по той же причине, про которую говорил Торвальдс - не надо дополнительной когнитивной нагрузки на мейнтейнеров. Им и так тяжело.
Плюс психологический такой фактор. Ты профи, работаешь двадцать лет с кодом, а тебя какой-то санитайзер заставляет расписаться, что ты точно знаешь, что тут может быть переполнение. Серьёзно?
Торвальдс и не должен предлагать решение. Представьте, что в вашу работу постоянно лезут с идиотскими "оптимизациями", не зная, как это всё работает. А на ваши аргументы предлагают вам самим решить проблему.
Вообще-то Торвальдс прав и вполне внятно обосновал свою точку зрения. Если делаете инструмент, то от него должно быть больше пользы, чем вреда. Он даже расписал, в каких конкретных случаях переполнение используется осмысленно.
Существуют всяческие анализаторы кода, которые становятся умнее и умнее. Я не вижу какой-то принципиальной проблемы, чтобы научить анализатор правильно обрабатывать намеренные переполнения, имея перед собой паттерны их применения.
В таких разработках, как разработка компилятора, в первую очередь заботятся об обратной совместимости, потому что никому не надо переписывать то, на что потрачены тысячи человеко-лет. Я так понял, что Кис предлагает сломать совместимость. Вот только за это я бы его подальше ещё послал.
Может быть действительно, не стоит трогать компилятор и добавить статический анализатор в воркфлоу.
Вот удивляюсь с людей, которые ноут приравнивают к компьютеру. Я вот привык к десктопу, к его полноценным мониторам, клавиатурам, мышам. Можно, конечно, это всё подключить и к ноуту. Но он же будет выть как зараза, сводя на нет все преимущества бесшумности.
Ну и плоская клавиатура на мой вкус фу. Я такое не ем.
Главное, чтобы Nvidia не поставила пробел куда не надо )
А зачем тогда корпус переделывать? Просто отпиливаем дисплей и получаем готовый системный блок. Жёсткость уже за нас инженеры рассчитали и применили нужные материалы. Бонусом имеем встроенный бесперебойник, встроенную клавиатуру и тачпад.
Был бы экран, вообще можно было бы пользоваться автономно...
Лень ещё как существует. Мы миллионами лет были рептилиями и каких-то 10 тыс лет назад у нас появилась перфронтальная кора головного мозга, что по меркам эволюции - секунды. Именно она отвечает за долгосрочное планирование жизни и дела, которые помогут в будущем. Если она рептилию победит, конечно. Рептилия хочет жрат и спат.
Вот когда побеждает рептилия, это и называется лень. Мы делаем то, что делают рептилии - экономим силы и запасаем жиры и делаем это в ущерб своему будущему, прекрасно об этом зная.
Вот это вот лень, а не то, что у вас в статье.
При рассмотрении приложения в комплексе, внезапно оказывается, что функционально неполная абстракция - это именно что SQL. Именно SQL ограничен декларативной парадигмой, а сверхсложную логику пишут на языках общего назначения.
ORM в следствии своей парадигмы, толкает на написание работы с данными внутри кода, что приводит цельности логики и его дальнейшему рефакторингу.
Про безопасность - это вообще не к орм. Просто потому что орм - маппер. То, что он умеет генерировать sql, не накладывает на него обязанность следить за уязвимостями протоколов. И вообще обычно канал orm-db защищён по умолчанию.
Кхм. С этого места пожалуйста поподробнее. Мне кажется, что мне вас есть чем приятно удивить.