На правильность не претендует, но облегчает жизнь во время постоянного редактирования запроса.
За несколько лет работы с SQL скриптами я пришел к похожему форматированию, особенно после того как пришлось разбираться со скриптами уволившихся коллег
-- в SELECT разбиваем 100500 выводимых колонок на логические группы,
-- каждая из которых начинается с новой строки
SELECT e.first_name, e.last_name
,e.salary
-- любое изменение будь то введение alias'a, формула и тд
-- пишем с новой строки, один столбец - ода строка
,d.name AS departament_name
,j.name AS job_name
-- также одна строка отступа перед FROM и перед каждым очередным JOIN
-- это визуально разделяет запрос на группы
FROM employee e
JOIN departments d
-- магическая строка 1 = 1 всегда равна TRUE и потому игнорируется
-- но позволяет в КАЖДОЙ строке условия писать AND в начале строки
-- по той же причине по которой мы пишем "," в начале строки в SELECT
ON 1 = 1
AND d.id = e.dept_id
JOIN (
-- в простых запросах скорее всего нет смысла делать отступы перед FROM или WHERE
-- это усложнит чтение
SELECT *
FROM jobs
WHERE 1 = 1
AND REGEXP_LIKE(name, '([^=,]+)', 1, 4) = 'WTF'
) j
ON 1 = 1
AND j.id = e.job_id
WHERE 1 = 1
AND d.name = 'IT'
-- AND e.last_name <> 'Ivanov'
AND j.name = 'Engineer'
AND e.salary > 100
Так же с недавнего времени пришел к выводу, что если мы не придерживаемся синтаксиса полного именования
а пользуемся псевдонимами для таблиц, то это очень быстро родит путаницу с названиями полей. Поэтому на мой взгляд, несмотря на лаконичность названий id, name, description и других "общих" названий и зарезервированных ключевых слов, стоит называть их как departament_id, departament_name, departament_description и тд.
Ну так уровень статьи граничит с инфоциганством. Много гипертрофированных взаимоисключающих параграфов, большинство из которых можно свести к старому-доброму "только ситхи все возводят в абсолют".. на этом фоне Дарт Вейдер в заголовке статьи весьма доставляет )
Не такой плохой вопрос, не понятно по чему влепили минус. Если вы владеете opensource проектом со всеми вытекающими, то какая разница? Если надо просто хранить код в публичном репозитории и не нужны модные CI/CD, то почему нет? Чем больше зеркал тем лучше. Думаю многие не согласятся, но по моему мнению, код - это не бизнес, можно и тут хранить.
Но помните, нет ничего постыдного в том, чтобы использовать для рендеринга готовые библиотеки типа Ogre3D
Эх, где мои 17 лет? Я иногда скучаю по тому ламповому времени, всем этим танцам с бубном по соединению Ogre, Physix, OpenAL, MyGui и Lua.. а все чтобы увидеть зеленого нинзю бегающего по полигону.
Бред не бред, а использование только GET/POST запросов с контейнером вместо CRUD like GET/PUT/POST/DELETE - это общепринятая практика. Потому что стандарта на REST нет и каждый пишет как хочет.
Да и сервер фактически отработал. Потому что неуспешность, как и отсутствие ответа - это тоже ответ. Если у вас есть решение как более корректно уведомить сторону клиента в публином api и не сломать его, то прошу к коллайдеру )
Первый вопрос, а зачем вообще нужен брокер сообщений? Я давно делаю приложения на ASP.NET (классика ASP + EF + WebApi / Razor), но не понимаю в каком случае брокера нужно использовать. Было бы классно увидеть это в начале статьи.
Самое чудесное тут это не игра, а то что она разрабатывается совместно, и не с кем-то а с женой. По хорошему так завидую, я так ни разу и не смог заинтересовать своими проектами других разработчиков, да и жены у меня нет :D
В устаревшем методе надо возвращать код ошибки HTTP (например 500) и или кастомный код (в 200 OK). В одном из проектов спечциально для этого, я делаю обьект { success, message, payload } контейнером для всех своих ответов по операциям, и в случае ошибки пишу success=false, message='error_i_am_your_father'. Так как REST фактически не регламентирован, то вокруг того какой подход верен идут ожесточенные споры)
Суть не в частоте использования, а потенциальных проблемах которые могут появится при подобной потребности.
Говорил что ему сильно проще получается.
Как вы наверно знаете, в ASPMVC есть особые ограничение на тип передаваемых аргументов между экшнами. Мой бывший коллега (привет Сергей) чтобы передать коллекцию целочисленных элементов, делал конкатенацию в строку, передавал ее в целевой экшн, а потом делил по разделителю и переводил обратно в int. Правильно ли это было? Нет, для этого в MVC были свои инструменты.. с моей точки зрения это индусский говнокод, который накладывал ограничения еще и на клиентскую часть, но ему так было удобно и "сильно проще".
Использую в работе только второй способ IEntityTypeConfiguration<> это решение оказалось максимально гибким. И вот почему.
Аннотационное описание, хорошо тем что она вещь "сама в себе". Но мы жестко привязываем описание к модели, и если хотим передать ту же модель в клиентскую другую часть приложения, то передаем и сведения о полях базы их граничениях.
Fluent описание в OnModelCreating привязано к конкретному dbContext
В IEntityTypeConfiguration<> мы достаточно свободны, чтобы теоретически вынести все компоненты: модель, контекст, и описание в разные библиотеки, и потом свободно их комбинировать, и повышает переиспользование кода.
Ну и из очевидного - мы легко можем заменить реализацию интерфейса, а в других случаях это вызовет небольшие сложности.
MTS практикует. Каждое внешнее обучение стоимость которого превышает определенную цифру, сопровождается договором, в котором ты обязан в увольнения течении двух лет после обучения вернуть деньги за обучение.
Игнорирование CASE
Иногда игнорирование CASE и тупое UNION запросов с разными фильтрами WHERE способно существенно ускорить время выполнения
Я сравнивал планы запроса и что-то не заметил разницы. Может быть были неподходящие примеры..
Где тут можно ошибиться когда методы так и называются "пропустить" и "взять", и передать только целоцисленное значение
https://referencesource.microsoft.com/#system.core/system/linq/Enumerable.cs,591
Имхо половина аргументов в статье высосона из пальца
На правах ИМХО
На правильность не претендует, но облегчает жизнь во время постоянного редактирования запроса.
За несколько лет работы с SQL скриптами я пришел к похожему форматированию, особенно после того как пришлось разбираться со скриптами уволившихся коллег
Так же с недавнего времени пришел к выводу, что если мы не придерживаемся синтаксиса полного именования
а пользуемся псевдонимами для таблиц, то это очень быстро родит путаницу с названиями полей. Поэтому на мой взгляд, несмотря на лаконичность названий id, name, description и других "общих" названий и зарезервированных ключевых слов, стоит называть их как departament_id, departament_name, departament_description и тд.
Ну так уровень статьи граничит с инфоциганством. Много гипертрофированных взаимоисключающих параграфов, большинство из которых можно свести к старому-доброму "только ситхи все возводят в абсолют".. на этом фоне Дарт Вейдер в заголовке статьи весьма доставляет )
Не такой плохой вопрос, не понятно по чему влепили минус. Если вы владеете opensource проектом со всеми вытекающими, то какая разница? Если надо просто хранить код в публичном репозитории и не нужны модные CI/CD, то почему нет? Чем больше зеркал тем лучше. Думаю многие не согласятся, но по моему мнению, код - это не бизнес, можно и тут хранить.
Эх, где мои 17 лет? Я иногда скучаю по тому ламповому времени, всем этим танцам с бубном по соединению Ogre, Physix, OpenAL, MyGui и Lua.. а все чтобы увидеть зеленого нинзю бегающего по полигону.
Опять кликбейт в заголовке.
Бред не бред, а использование только GET/POST запросов с контейнером вместо CRUD like GET/PUT/POST/DELETE - это общепринятая практика. Потому что стандарта на REST нет и каждый пишет как хочет.
Да и сервер фактически отработал. Потому что неуспешность, как и отсутствие ответа - это тоже ответ. Если у вас есть решение как более корректно уведомить сторону клиента в публином api и не сломать его, то прошу к коллайдеру )
Первый вопрос, а зачем вообще нужен брокер сообщений? Я давно делаю приложения на ASP.NET (классика ASP + EF + WebApi / Razor), но не понимаю в каком случае брокера нужно использовать. Было бы классно увидеть это в начале статьи.
О чем статья то? После прочтения создается впечатление, что это поток сознания на тему "как я стал фанбоем js", но даже эта тема не раскрыта
Вы хоть немного за контекстом следите, я ни слова не говорил о генерации.
Самое чудесное тут это не игра, а то что она разрабатывается совместно, и не с кем-то а с женой. По хорошему так завидую, я так ни разу и не смог заинтересовать своими проектами других разработчиков, да и жены у меня нет :D
В устаревшем методе надо возвращать код ошибки HTTP (например 500) и или кастомный код (в 200 OK). В одном из проектов спечциально для этого, я делаю обьект { success, message, payload } контейнером для всех своих ответов по операциям, и в случае ошибки пишу success=false, message='error_i_am_your_father'. Так как REST фактически не регламентирован, то вокруг того какой подход верен идут ожесточенные споры)
Суть не в частоте использования, а потенциальных проблемах которые могут появится при подобной потребности.
Как вы наверно знаете, в ASPMVC есть особые ограничение на тип передаваемых аргументов между экшнами. Мой бывший коллега (привет Сергей) чтобы передать коллекцию целочисленных элементов, делал конкатенацию в строку, передавал ее в целевой экшн, а потом делил по разделителю и переводил обратно в int. Правильно ли это было? Нет, для этого в MVC были свои инструменты.. с моей точки зрения это индусский говнокод, который накладывал ограничения еще и на клиентскую часть, но ему так было удобно и "сильно проще".
Использую в работе только второй способ IEntityTypeConfiguration<> это решение оказалось максимально гибким. И вот почему.
Аннотационное описание, хорошо тем что она вещь "сама в себе". Но мы жестко привязываем описание к модели, и если хотим передать ту же модель в
клиентскуюдругую часть приложения, то передаем и сведения о полях базы их граничениях.Fluent описание в OnModelCreating привязано к конкретному dbContext
В IEntityTypeConfiguration<> мы достаточно свободны, чтобы теоретически вынести все компоненты: модель, контекст, и описание в разные библиотеки, и потом свободно их комбинировать, и повышает переиспользование кода.
Ну и из очевидного - мы легко можем заменить реализацию интерфейса, а в других случаях это вызовет небольшие сложности.
До боли напоминает массу сущиствующих туторов, в том числе из msdn. В чем новизна конкретно этого howto?
>Не единственный плюс, но поддерживает как никакая другая симуляция — работу с указателями в языке c++
Я давно не интересовался, а что, simulavr не умеет в указатели ?
MTS практикует. Каждое внешнее обучение стоимость которого превышает определенную цифру, сопровождается договором, в котором ты обязан в увольнения течении двух лет после обучения вернуть деньги за обучение.
Честно говоря душу бы продал сейчас за толковый мануал по аутентификации на ресурсах с авторизацией через microsoftonline.com )