Как стать автором
Обновить
3
0
Владимир @KislyFan

Программист dotnet

Отправить сообщение

Игнорирование CASE

Иногда игнорирование CASE и тупое UNION запросов с разными фильтрами WHERE способно существенно ускорить время выполнения

Я сравнивал планы запроса и что-то не заметил разницы. Может быть были неподходящие примеры..

Можно ошибиться при передаче параметров в методы Skip и  Take (относится к начинающим программистам). 

Где тут можно ошибиться когда методы так и называются "пропустить" и "взять", и передать только целоцисленное значение

https://referencesource.microsoft.com/#system.core/system/linq/Enumerable.cs,591

public static IEnumerable<TSource> Take<TSource>(this IEnumerable<TSource> source, int count) {
    if (source == null) throw Error.ArgumentNull("source");
    return TakeIterator<TSource>(source, count);
}

Имхо половина аргументов в статье высосона из пальца

На правах ИМХО

На правильность не претендует, но облегчает жизнь во время постоянного редактирования запроса.

За несколько лет работы с 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

Так же с недавнего времени пришел к выводу, что если мы не придерживаемся синтаксиса полного именования

schema.departament.name = schema.wfttable.departament

а пользуемся псевдонимами для таблиц, то это очень быстро родит путаницу с названиями полей. Поэтому на мой взгляд, несмотря на лаконичность названий 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), но не понимаю в каком случае брокера нужно использовать. Было бы классно увидеть это в начале статьи.

О чем статья то? После прочтения создается впечатление, что это поток сознания на тему "как я стал фанбоем 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 )

Информация

В рейтинге
Не участвует
Откуда
Краснодар, Краснодарский край, Россия
Дата рождения
Зарегистрирован
Активность

Специализация

Backend Developer
SQL
.NET
.NET Core
Entity Framework
ASP.Net
MSSQL