Комментарии 13
А что там за версия Visual Studio?
DROP IF EXISTSА я всегда просто игнорировал возможную ошибку при выполнении DROP. Чем это хуже?
BEGIN TRY
BEGIN TRANSACTION
--IF OBJECT_ID('tempdb.dbo.##temp') IS NOT NULL
-- DROP TABLE ##temp
SELECT *
INTO ##temp
FROM sys.objects
SELECT *
FROM ##temp
COMMIT TRANSACTION
END TRY
BEGIN CATCH
--PRINT ERROR_MESSAGE()
IF XACT_STATE() <> 0
ROLLBACK TRANSACTION
END CATCH
хоть пример и натянутый… но все же… ошибки игнорировать не комильфо. А чтобы ошибок не было… нужно писать код с учетом проверок к которым DROP IF EXISTS и относится.
Разве ошибка при выполнении DROP может быть только по поводу отсутствующего объекта? Вы все ошибки при выполнении DROP игнорировали?
Поддержка JSON — это очень круто, как мне кажется. Теперь же есть возможность отказаться от прослойки в виде, например веб-сервера, для общения SQL сервера с внешним миром в этом формате.
с внешним миромЭто с кем — с веб-клиентами что ли? :)
Но с Node.js будет удобнее работать, да.
Как у Oracle? Если кратко: в свое время была разработана технология, позволяющая минимально использовать посредников между базой данных и браузером. Не особо взлетело, однако идея интересная.
А по факту: добавление JSON является очередным давлением на конкурентов: как на хранилища без схемы, так и на PosrgeSQL, который всё это уже умеет.
А по факту: добавление JSON является очередным давлением на конкурентов: как на хранилища без схемы, так и на PosrgeSQL, который всё это уже умеет.
Там, насколько я понял по NVarChar — тупо преобразование в JSON и обратно. О таком масштабе поддержки как в Postgre — с BSON, индексами, и всяким таким — речь не идет.
Вы, конечно, правы. В текущей реализации нельзя говорить о прямой конкуренции с JSON функционалом реализованным в PostgreSQL.
Хотя мне кажется данная ситуация повторит судьбу с Columnstore Indexes. В них была куча ограничений, когда они появились в 2012 версии. В 2014 часть этих ограничений сняли (например, теперь индексы стали обновляемыми) и повысили производительность при их использовании. В 2016 версии для Columnstore Indexes еще больше фишек добавили… Надеюсь тоже ждет и JSON на SQL Server :)
Хотя мне кажется данная ситуация повторит судьбу с Columnstore Indexes. В них была куча ограничений, когда они появились в 2012 версии. В 2014 часть этих ограничений сняли (например, теперь индексы стали обновляемыми) и повысили производительность при их использовании. В 2016 версии для Columnstore Indexes еще больше фишек добавили… Надеюсь тоже ждет и JSON на SQL Server :)
Шардинга мы так и не увидим, походу, никогда
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
SQL Server 2016 CTP3.1 — что нового для разработчика?