Comments 32
Хороший список нововведений. С пейджингом только перемудрили, столько слов запоминать:
Почему бы не просто LIMIT 10,10
OFFSET 10 ROWS
FETCH NEXT 10 ROWS ONLY;
Почему бы не просто LIMIT 10,10
Упростили использование, чтобы меньше кода городить, а сами слова старые, курсор еще в SQL 2000 открыть можно было, если не раньше.
Не очень понятно, насколько правильно из-за каждых 10 строчек сервер дергать, лежат они у него в кеше или каждый раз запрос исполняется.
msdn.microsoft.com/en-us/library/ms180152
Не очень понятно, насколько правильно из-за каждых 10 строчек сервер дергать, лежат они у него в кеше или каждый раз запрос исполняется.
msdn.microsoft.com/en-us/library/ms180152
Каждый запрос выполняется независимо и никаким образом не связан с другими запросами.
Это означает, что в отличие от использования курсора, где запрос выполняется всего один раз, а текущее состояние хранится на сервере, за отслеживание состояния отвечает клиентское приложение.С курсорами не все так радужно в веб-приложениях. Поэтому проще лишний раз сервер дернуть, чем выбирать сразу несколько тысяч записей.
также в новой версии SQL Server оптимизирована работа с Geo типами geography и geometry — вычисления по ним стали гораздо быстрее
А есть с них существенный толк, неужели настолько всем нужны?
И почему нельзя просто хранить данные, а вычисления вести соответствующими библиотеками?
Код на .Net вполне можно вставить в процедуры SQL сервера, если так уж нужно нагрузить хранилище еще и вычислениями.
И почему нельзя просто хранить данные, а вычисления вести соответствующими библиотеками?
Код на .Net вполне можно вставить в процедуры SQL сервера, если так уж нужно нагрузить хранилище еще и вычислениями.
>>неужели настолько всем нужны?
за всех отвечать не буду
>>И почему нельзя просто хранить данные, а вычисления вести соответствующими библиотеками?
гео-типы и работа с ними реализованы в библиотеке SqlGeography.dll, которая входит в состав Sql Server. Хотите — вычисляйте на сервере. Хотите — подключайте библиотеку к проекту.
Библиотека часто нужна если например необходимо посчитать площадь полигона, заданного координатами. Или вычислить расстояние между двумя полигонами, заданными множеством координат.
за всех отвечать не буду
>>И почему нельзя просто хранить данные, а вычисления вести соответствующими библиотеками?
гео-типы и работа с ними реализованы в библиотеке SqlGeography.dll, которая входит в состав Sql Server. Хотите — вычисляйте на сервере. Хотите — подключайте библиотеку к проекту.
Библиотека часто нужна если например необходимо посчитать площадь полигона, заданного координатами. Или вычислить расстояние между двумя полигонами, заданными множеством координат.
Вот вам это все часто надо?
SQL Server всегда шел как решение общего профиля, поэтому было странно когда в него запилили географические функции.
Есть один знакомый, который реально работает с гео-данными, но у них MS SQL никогда даже не рассматривался к использованию.
Это точно так же выглядит, как если бы в MS SQL реализовали например функции для работы с почтовыми адресами, и потом в каждой версии победно рапортовали бы о добавлении новых фич, которые изначально никому кроме DHL не нужны.
Был бы никому не нужный стандартный тип данных address с полями типа .index, .street, .house и т.д.
А еще для химиков много чего в SQL можно запилить…
SQL Server всегда шел как решение общего профиля, поэтому было странно когда в него запилили географические функции.
Есть один знакомый, который реально работает с гео-данными, но у них MS SQL никогда даже не рассматривался к использованию.
Это точно так же выглядит, как если бы в MS SQL реализовали например функции для работы с почтовыми адресами, и потом в каждой версии победно рапортовали бы о добавлении новых фич, которые изначально никому кроме DHL не нужны.
Был бы никому не нужный стандартный тип данных address с полями типа .index, .street, .house и т.д.
А еще для химиков много чего в SQL можно запилить…
Очевидно что MS SQL Server будет развиваться, в него будут добавляться новые фичи. Одни со временем будут отмирать, другие будут развиваться дальше.
Одним людям подойдёт MSSQL, другим нет. Существует очень много факторов которые опеределяют использование одного или иного инструмента в работе. Одним людям хватит функциональности, реализованной в MSSQL, другим — нет.
В любом случае, я написал о новшестве, которое Майкрософт внёс в SQL Server. Нужно оно людям или нет — совершенно другая тема, и в этом треде её не следует обсуждать.
Одним людям подойдёт MSSQL, другим нет. Существует очень много факторов которые опеределяют использование одного или иного инструмента в работе. Одним людям хватит функциональности, реализованной в MSSQL, другим — нет.
В любом случае, я написал о новшестве, которое Майкрософт внёс в SQL Server. Нужно оно людям или нет — совершенно другая тема, и в этом треде её не следует обсуждать.
Название статьи вполне соответствует, почему бы и не обсудить?
Может кто из пользующихся фичами что полезное подскажет.
А голый список новых фичей можно на сайте прочитать.
Может кто из пользующихся фичами что полезное подскажет.
А голый список новых фичей можно на сайте прочитать.
Список фич действительно намного больше. Все сразу не охватить.
С геоданными в своей практике мне втречаться не доводилось, а теорию я думаю каждый сможет прочитать и сам.
ИМХО фича интересная, поскольку объемы геоданных очень большие и вполне было бы логично их хранить в БД. Соответственно перед БД должна стоять задачи по обработке геоданных.
С геоданными в своей практике мне втречаться не доводилось, а теорию я думаю каждый сможет прочитать и сам.
ИМХО фича интересная, поскольку объемы геоданных очень большие и вполне было бы логично их хранить в БД. Соответственно перед БД должна стоять задачи по обработке геоданных.
Есть еще люди, которым по работе приходится «дружить» клиента с несколькими СУБД. По личному опыту скажу, что адаптировать приложение к MSSQL стоило дороже, чем к Firebird, SQLite и Postgre вместе взятым.
Самое банальное что приходит в голову, это поиск каких-то точек(магазины, кафе, терминалы) в определенном радиусе. Удобно и быстро.
Поиск списка точек, входящих в полигон, заданный списком координат? Неплохая была бы фича.
Может еще и поиск кратчайшего пути в графе у них есть?
Кластеризация облака точек на несколько облаков тоже хорошая штука была бы — но если у них только координаты на плоскости, то многомерный анализ не провести.
Сделал бы кто обзор нормальный, что оттуда можно использовать в обычной жизни.
Может еще и поиск кратчайшего пути в графе у них есть?
Кластеризация облака точек на несколько облаков тоже хорошая штука была бы — но если у них только координаты на плоскости, то многомерный анализ не провести.
Сделал бы кто обзор нормальный, что оттуда можно использовать в обычной жизни.
Поиск кратчайшего пути (NEAREST NEIGHBOR) есть на основе функции Distance, вообще поддерживается много различных функций.
У меня в продукте (http://www.zetuniverse.com) пространственные данные используются очень широко, и это довольно удобно. Самое главное преимущество — это расчеты типа «Intersects», «Touches», «Contains», «Distance», и т.д., которые выполняются очень быстро за счет пространственного индекса.
Координаты у них X,Y,Z, т.е., три измерения.
У меня в продукте (http://www.zetuniverse.com) пространственные данные используются очень широко, и это довольно удобно. Самое главное преимущество — это расчеты типа «Intersects», «Touches», «Contains», «Distance», и т.д., которые выполняются очень быстро за счет пространственного индекса.
Координаты у них X,Y,Z, т.е., три измерения.
Мы, к примеру, PostgreSQL активно пользуем отчасти из-за наличия PostGIS расширения для работы с географическими данными, и это очень полезно, когда с картами работаешь.
Семантический поиск — это интересно, хотелось бы увидеть какой-то более подробный (нежели msdn) обзор данной фичи, с тестами по релевантности, производительности и тд.
UFO just landed and posted this here
Нововведение с пейджингом — хорошо. Остальное лично я бы променял на select for update, который никак не сделают в sql server-e. И вообще уже давно пока привести систему блокировок в нормальный вид
Было же TOP уже, добавили бы OFFSET(SKIP) и всё
выглядит слишком развесисто.
FETCH NEXT 10 ROWS ONLYвыглядит слишком развесисто.
> 7. Таблицы FileTable
Вот это, действительно, интересно. Неужели извечный спор, где хранить файлы – в БД или FS, – будет разрешён?
Вот это, действительно, интересно. Неужели извечный спор, где хранить файлы – в БД или FS, – будет разрешён?
Я бы сказал иначе: теперь нет повода для этого спора.
Поскольку доступ к этим файлам прозрачен как для БД так и для приложений.
БД работает с этими файлами как будто они хранятся в БД, а, например, Office, как будто они хранятся в FS.
В принципе эта возможность появилась еще в SQL 2008 (FILESTREAM). Но не было поддержки API-интерфейсов Windows.
Поскольку доступ к этим файлам прозрачен как для БД так и для приложений.
БД работает с этими файлами как будто они хранятся в БД, а, например, Office, как будто они хранятся в FS.
В принципе эта возможность появилась еще в SQL 2008 (FILESTREAM). Но не было поддержки API-интерфейсов Windows.
Правда, я так понимаю, один минус всё-таки остаётся — размер БД. Вы не разбирались с этим моментом?
SQL Server хранит файлы как объекты BLOB.
Есть два варианта хранения BLOB: стандартно в таблицах или в объектах FILESTREAM.
Данные объектов FILESTREAM это файл в определенном каталоге файловой системы.
Размеры объектов FILESTREAM ограничены только размером тома файловой системы.
Стандартное ограничение типа varbinary(max), согласно которому размер файла не должен превышать 2 ГБ, не применяется к объектам BLOB, сохраняемым в файловой системе.
В SQL Server Express предусмотрена поддержка FILESTREAM. Ограничение размера базы данных в 10 ГБ не включает контейнер данных FILESTREAM.
Есть два варианта хранения BLOB: стандартно в таблицах или в объектах FILESTREAM.
Данные объектов FILESTREAM это файл в определенном каталоге файловой системы.
Размеры объектов FILESTREAM ограничены только размером тома файловой системы.
Стандартное ограничение типа varbinary(max), согласно которому размер файла не должен превышать 2 ГБ, не применяется к объектам BLOB, сохраняемым в файловой системе.
В SQL Server Express предусмотрена поддержка FILESTREAM. Ограничение размера базы данных в 10 ГБ не включает контейнер данных FILESTREAM.
Sign up to leave a comment.
SQL Server 2012 — что нового для разработчика?