Comments 18
Хотя... черт, у меня нет никакого телеграмм канала...
А мы все равно заведем и подпишемся :)
Да ну, не, лично я настолько нынче далек от MS SQL. У нас в процессе его замещение на постгрес, так что 2024 по плану будет последним годом эксплуатации всех экземпляров.
Все замещают на постгрес. Так чувствую закончу свои дни под мостом
Знакомый до боли интерфейс. И сейчас даже будет работать как часы...
Мне очень нравился query analyzer. Легкий, быстрый, удобный.
Ууу, какие преданья старины глубокой. Впрочем, работа с MS SQL (правда, помню только с версии 7.0, так я ж и помладше буду) оставила только положительные впечатления - очень стабильная, устойчивая, хорошо спроектированная, масштабируемая СУБД, при этом там имелся и весь нужный тулинг - от bcp для импорта какого угодно количества CSV-файлов в базу, до Enterprise manager, где можно было с помощью графического интерфейса перетащить первичный ключ на внешний и оно создавало констрэйнт типа FOREIGN KEY (что, как я представляю сейчас, скорее навредило в долгосрочной перспективе). Transact SQL был вполне себе на уровне, работал очень быстро, а то, что оно понимало различие между UNION и UNION ALL прямо на уровне движка, позволило мне еще тогда спроектировать хоть и примитивное, но работающее "партиционирование". В общем, уж не знаю, сколько там в этой инженерии было от Sybase (скорее всего, ядро и прочее низкоуровневое), а сколько от Microsoft (скорее всего, тулинг, GUI-инструменты и маркетинг), но софт был очень впечатляющий для своего времени, да и сейчас вроде еще в энтерпрайзах вполне продолжает работать.
Я больше скажу: MS SQL Server оптимизирован так хорошо, что прощает многие ошибки написания запросов. Настолько, что откровенно фиговый по производительности SQL-код для среднего инхаус энтерпрайза работает "just fine", чем сильно "размягчает" разработчиков. В итоге с него непросто куда-то переходить (типичный MS, но в этом случае как будто в плюс).
На это можно посмотреть с другой стороны. SQL - декларативный язык, то есть, запрос буквально описывает "что должно быть в результате", а не "как получить результат". Ответ на вопрос "как" - задача SQL движка. Соответственно, в запросе не может быть никаких ошибок, кроме синтаксических (запрос не выполняется в принципе) и логических (запрос возвращает не то, что задумывалось).
В реальности же есть и "откровенно фиговые по производительности" запросы, и хорошо оптимизированные запросы. Но оптимизация производительности запросов - это, по сути, плата за неоптимизированность движка, за то, что концепция декларативного языка не реализована в полной мере.
Я не рассматриваю тут императивные возможности диалектов SQL, там пользователь сам себе злобный буратино.
На мой взгляд, одной из причин, способствующих широкому распространению данной платформы была хорошая интерактиваня справка (Books On Line) в формате автономного приложения. Мне, точно, очень помогла.
Работал на нем с конца 90х. Система разработанная в 2000 году прожила 9 лет и умерла только потому что мне стало влом её сопровождать, хотя особых проблем не было. Просто занялся другим делом. Повторно вернулся к нему в 2018 году. Уже пять корпоративных приложений разработано, из них одно описал в своей публикации на хабре. Фантастическая стабильность и скорость.
Хотя... черт, у меня нет никакого телеграмм канала...
Но есть доска на BBS и поинт в Fidonet, качайте оттуда. :))) если что - стучите в аську
Самый старый код в MSSQL