Блог

Решение задачи на алгоритм с помощью LINQ

У нас на работе при найме есть тест на соображалку типа дано два массива символов и нужно найти все совпадения больше двух раз. Задание конечно же не это, но надеюсь смысл понятен. Главное тут понимать возможные проблемы производительности и уметь находить оптимальные решения. 

На прошлой работе у меня в команде работал хороший программист и я решил его посоветовать. Он пришёл на тест, и как он мне сказал, решил его с помощью LINQ выражения. 

Я то знаю, что он хороший программист, но не уверен, что LINQ - это правильное решение. Если бы я принимал тест, я бы заставил переделать все без использования LINQ.

Что ты думаешь по этому поводу? Правильно ли принимать решения задачи, если она решена с помощью LINQ? Может ли это показать профессионализм программиста?

Почему я не пишу логику на Transact-SQL

Совсем недавно я написал о задании для программиста, которое мне прислали, где нужно было найти натуральные числа на Transact-SQL (читаем заметку здесь). Там было ещё два задания, которые я точно не помню, но смысл в том, что они легко решаемы, но нужно писать процедуру или какой-то другой код на стороне Transact-SQL. 

В той заметке я так же спросил, что говорит такое задание. Для меня это говорит то, что компания очень много использует хранимых на сервере базы данных процедур и/или функций, а я такое не люблю, поэтому в такой компании не очень горю желанием работать. И объясню почему. 

Если переносить логику на базу данных, то на неё увеличивается нагрузка. Хранимые процедуры с курсорами, циклами и так далее обходятся серверу не дёшево, да и в любом случае, даже дешёвые операции лучше лишний раз не кидать на сервер. Базу данных очень тяжело масштабировать горизонтально. Можно наращивать мощность процессора, увеличивать размер оперативной памяти, но ставить два сервера одновременно не так уж и легко. 

Поиск натуральных чисел на SQL

Недавно мне написал рекрутер и сказал, что его клиент ищет программиста с моими навыками, но для получения работы мне нужно написать тест. Я говорю - ну ладно, без проблем напишу. Мне присылают тест из трёх заданий. Я все их точно не помню но одно кажется было - найти все натуральные числа в диапазоне. Казалось бы, вполне классическая задача, решение которой можно найти в интернете без проблем, но тут же приписано, что я должен это сделать на Transact-SQL. 

Я даже не стал заморачиваться и писать этот тест, просто подобного я даже не встречал. Но задание вполне интересное и если кто-то хочет решить, то интересно было бы увидеть, как бы ты это сделал?

Интересно еще твое мнение, что ты думаешь о таком задании и что оно говорит о том программисте, которого тестируют.

Преимущество знания SQL

Вчера получил e-mail от консультантов, которых я консультирую, в котором показана ошибка сохранения данных в базу и там четко сказано, что строка будет обрезана. Из SQL я увидел только одну колонку, которая может быть не достаточно большой и ответил на письмо, мол увеличьте размер колонки и будет счастье. 

Через минут 10 падает еще одно письмо с ошибкой SQL Management Studio. Программист явно пытался увеличить колонку с помощью SQL Management Studio, а я уже не раз замечал, что с модификацией колонок эта студия часто тупит и явно генерирует не очень хороший SQL для обновления. Я только видел это, сам давно не встречался, потому что сам всегда все делаю с помощью SQL. 

Web мышление

Сейчас работаю над приложением для iOS и я постоянно стал замечать, что мыслю, как будто я программирую для Web. Появляются такие мысли, а как я сохраню состояние переменных между отрисовками. Блин, состояние никуда не денется, это же не Web. 

С другой стороны, это достаточно правильное мышление даже на мобильной платформе, ведь пользователь может в любое время нажать кнопку Домой на iPhone и выйти из приложения, а потом ОС может убить программу и если есть какое-то состояние, требующее сохранения, то лучше его сохранить раньше. 

Мы найдём OpenSource проект и будем его использовать

Недавно был на встрече с новым клиентом и обсуждали вопрос строительства сайта. Ребята явно хорошо разбираются в HTML, в фронтенде, но вот на заднем плане у них явные проблемы. Вместо того, чтобы сказать - "мы напишем для вас все, что угодно", их ответ был - "Мы не пишем проекты, мы найдём готовый OpenSource проект и прикрутим его к вашему сайту". Причем за свою работу они просят достаточно большие деньги. 

Сразу же ясно, что ребята совершенно не Dev шоп. Возможно они хорошие дизайнеры и умеют резать картинки на HTML, но вполне понятно, зачем им понадобились мои услуги. 

Но в целом мне такой ответ напоминает комара, который как паразит кровь сосёт у других. Программисты стараются, работают за булочки и пишут открытый код, а вот такие паразиты берут открытый проект и прикручивают его к себе и зарабатывают лимон баксов с сайта. 

Размер строки влияет на производительность SQL Server

В MS SQL Server ты можешь создавать поля типа varchar(max) и с точки зрения производительности это чуть лучше, чем text. Если размер текста в поле меньше 8k, то сервер будет пытаться сохранить его вместе с остальными данным в той же странице. Если больше 8 кило, то данные точно уйдут в отдельное хранилище, что отрицательно скажется на производительности, если массово выбирать данные. 

Обычно для запросов, которые возвращают данные для сеток или списков данных,  не нужно возвращать текстовые поля. Трудно представить себе сетку, где будет большой текст. Разве что блоги. Например, у меня запись блога состоит из двух текстовых полей - первое показывается в списке, а второе, когда вы открываете саму статью. Не знаю как MySQL, но в MS SQL Server эти текстовые поля притормаживали бы запросы. 

За счёт того, что я показываю на блоге записи постранично, максимум 10 записей на странице, то потри не смертельны, но на нагрузке на сервер это все же сказывается. Для сайтов с большим трафиком я бы все же сделал поле Intro, которое у меня отображается в списке не текстовым, а varchar. 1000 символов должно хватить с головой. Главное не выполнять запросов типа SELECT *, но к сожалению этим грешат многие программисты. Да и я сам такой же.

LINQ и производительность

Не знаю, насколько это вина LINQ, но я достаточно часто вижу код, когда программисты используют возможности LINQ далеко неэффективно. Хотя подобное я встречал в коде и без этой технологии. Даже те программисты, которые хорошо знают проблемы производительности, совершают подобные ошибки. 

Очень распространённая задача - работа с двумя массивами, просто нюансы бывают разные. Допустим, что есть два массива данных - пользователей сайта и их адреса. У вас есть все данные, просто нужно взять, и добавить адреса всем пользователям. Возможно помимо этого нужно выполнить что-то еще и в таких случаях я уже не раз видел код в виде: 

Community Edition не может работать с SQL Server CE?

Сейчас пытался подключиться к SQL Server Compact Edition из Visual Studio Community Edition и с удивлением узнал, что это невозможно. Сначала я решил, что проблема в отсутствующем драйвере. Я пошёл и скачал последнюю версию SQL Server CE, но программа установщик сообщила, что у меня уже все установлено. 

Я погуглил и гугля сообщил, что можно установить драйвер через NuGet. Я попробовал установить этот пакет, но и после этого в VS не появилось возможности подключаться к CE версии базы данных. 

Как повлиять на план выполнения запроса базы данных?

Очередной праздник для твоего мозга - вторая заметка про программирование. Хот эта была написана до статьи, которую я опубликовал недавно, но именно такой порядок чтения и публикации имеет больше смысла. 

Я как-то писал про существование подсказок компилятору в виде loop join, merge join или hash join, которые позволяют заставить SQL Server выбрать определённый план выполнения, об этом здесь - Подсказки оптимизатору MS SQL Serever. Я заметил, что не так уж и много народа знает о существовании этих подсказок, оно и к лучшему. В рабочем приложении нужно доверяться SQL Server ведь план выполнения может зависеть от количества данных, для малого количества лучше выполнить loop, а для большого merge. 

Допустим, что у тебя связывается две таблицы: 

Select *

From Table1 t1

 left join Table2 t2 on t1.key =t2.key

Where …..

О блоге

Программист, автор нескольких книг серии глазами хакера и просто блогер. Интересуюсь безопасностью, хотя хакером себя не считаю

Обратная связь

Без проблем вступаю в неразборчивые разговоры по e-mail. Стараюсь отвечать на письма всех читателей вне зависимости от страны проживания, вероисповедания, на русском или английском языке.

Пишите мне