Блог

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

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

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

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

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

Сейчас пытался подключиться к 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: 

Хотел бы узнать твое мнение по поводу следующего вопроса: как ты видишь свою профессиональную деятельность спустя 5-10 лет? На сколько мне известно тебе скоро будет 40 лет. Дело в том, что я со своими коллегами иногда в шутку обсуждаем, чем мы (программисты) будем заниматься после 40-ка. Многие утверждают, что к этому возрасту мозг уже не сможет работать так же эффективно, как в 25 лет, поэтому все думают что нужно либо уходить в менеджмент, либо открывать свое дело. 

Ну мне 40 уже в этом году. Блин, как я старею. Ну пока что при своих 40 я вроде бы ещё работаю достаточно эффективно. Уходить в менеджмент? В принципе я не против, здесь в Канаде мне очень сильно пока мешает далеко не идеальное знание английского языка и неумение обсуждать финансовые вопросы с работодателем.

У нас сейчас на работе очень много используют nolock опции при выполнении SELECT запросов. Эту опцию можно использовать только в самых крайних случаях и настоятельно рекомендую избежать её использование. 

Когда выполняется долгий SELECT запрос, то база данных может блокировать данные, что сильно замедляет производительность сервера. Если какой-то зарос выполняется слишком часто, но с блокировкой, то на сервере может выстраиваться очередь на выполнение запроса и пользователь будет видеть задержки загрузки данных, пока его запрос ожидает в очереди, или даже таймауты. Чтобы не было ни того ни другого, начинают использовать опцию NOLOCK. Это выглядит примерно так:

SELECT * FROM Employee WITH (NOLOCK)

Даже если Employee таблица сейчас заблокирована кем-то, сервер все равно выполнит этот запрос и вернёт данные. 

Очередной раз появился слух, что Google может перейти с Java на Swift на своей мобильной платформе Android. Походу Oracle из окончательно заебали судебными издержками и возможным штрафом и проще стало перейти на другой язык.

Если Google действительно выберет Swift, то это будет серьёзный пинок в развитии и в светлом будущем для этого языка. Уверен, что программисты воспримут эту новость положительно, потому что их код из коробки будет компилироваться под две самые популярные платформы. 

Если выбрать какой-то язык типа Go или что-то новое, то понадобиться время, когда пользователи перейдут на новый язык. Даже в случае с Apple до сих пор очень много программ продолжают использовать Objective-C. К тому же, потребуется время, пока программисты выучат язык и неизвестно, понравится ли он им. 

Microsoft выпустила халявный Xamarin, который позволяет писать код, который потом без проблем должен компилироваться на любой платформе. Сегодня я услышал мнение, что Майкрософт сделали это, чтобы больше программистов писали код с использованием технологий этой компании и таким образом им проще будет выпускать версии для Windows Phone. 

Логично, ведь если программист может скомпилировать в Xamarin приложение для Андроид, то почему бы не выпустить тут же вариант и для Windows Phone? Отсутствие хороших приложений называют как раз самой главной проблемой, почему платформа от последователей Билла Гейтса никак не выстрелит. 

Если к Майкрософт действительно думали так, то мне кажется это опять маркетинговый просчёт. Мне кажется, что большинство программистов все же будет продолжать писать код в своих средах разработки и приложения для iOS продолжат создавать в Xcode. Это лично моё мнение. 

Сейчас с семьёй едем в Орландо в Disney World, а пока жена сидит за рулём, я решил сравнить Swift и C#. 

Меня как-то уже спрашивали несколько раз об этом сравнении, последний раз, когда я сравнил Java и .NET. В случае с Java и .NET - это целые платформы с большим количеством возможностей. При сравнении Swift и C# мы сравниваем всего лишь языки и тут можно сравнить только синтаксис. Возможности в основном зависят от того, под какую платформу пишется код. 

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

Когда-то давным давно мне в журнале Хакер дали задание написать про SOAP. Я начал исследование и меня поразило, как же сложно все описывают эту тему. Большое количество заумных слов, особенно в статьях от IBM. Я попытался максимально упростить тогда свою статью про Web сервисы и SOAP, но сейчас я решил ещё раз вернуться к этой теме и ещё раз попробовать описать Web сервисы, так сказать много лет спустя. 

Что такое SOAP? Это сокращение расшифровывается как Simple Object Access Protocol, что на великий и могучий язык можно повести как Простой Протокол Доступа к Объектам. И он действительно простой. 

Если читать документацию IBM по сервисам, то там обязательно будут заумные вещи типа общей шины, какая-то ещё херня, но все это просто заумные слова, потому что на самом деле Web сервисы очень простые в использовании. 

Запрос к Web сервису в самом простом случае поставляет из себя банальный HTTP запрос, с таким же заголовком и с такими же параметрами, как и у любого другого запроса к любым другим страницам сайта. У Microsoft сервисы могут работать по TCP для увеличения скорости, но это отдельная история, потому что сейчас мы затрагиваем SOAP – классику, с которой кажется и начинались все эти веб сервисы.