Slashdot Mirror

← Back to Stories (view on slashdot.org)

Microsoft Will Support Python In SQL Server 2017 (infoworld.com)

Posted by EditorDavid on from the winning-through-whitespace dept.

There was a surprise in the latest Community Technology Preview release of SQL Server 2017. An anonymous reader quotes InfoWorld: Python can now be used within SQL Server to perform analytics, run machine learning models, or handle most any kind of data-powered work. This integration isn't limited to enterprise editions of SQL Server 2017, either -- it'll also be available in the free-to-use Express edition... Microsoft has also made it possible to embed Python code directly in SQL Server databases by including the code as a T-SQL stored procedure. This allows Python code to be deployed in production along with the data it'll be processing. These behaviors, and the RevoScalePy package, are essentially Python versions of features Microsoft built for SQL Server back when it integrated the R language into the database...

An existing Python installation isn't required. During the setup process, SQL Server 2017 can pull down and install its own edition of CPython 3.5, the stock Python interpreter available from the Python.org website. Users can install their own Python packages as well or use Cython to generate C code from Python modules for additional speed.
Except it's not yet available for Linux users, according to the article. "Microsoft has previously announced SQL Server would be available for Linux, but right now, only the Windows version of SQL Server 2017 supports Python."

11 of 98 comments (clear)

  1. Always catching up to PostgreSQL! by Anonymous Coward · · Score: 4, Informative

    PostgreSQL has had Python support for years. It also has R support.

    But to be fair to SQL Server, it is a very good RDBMS. Both SQL Server and PostgreSQL make MySQL look really, really, really bad. Even SQLite is making MySQL look pathetic these days!

  2. a little late to the party by ooloorie · · Score: 3, Informative

    You've been able to use Python for a while in Postgres, MySQL, SQLite, and even DB2.

    I can't quite figure out why anybody would want to use Microsoft SQL Server.

    1. Re:a little late to the party by DogDude · · Score: 2, Informative

      I can't quite figure out why anybody would want to use Microsoft SQL Server.

      Easy to use. Works well. Tons of features. Free to a point. After that, inexpensive.

      --
      I don't respond to AC's.
    2. Re:a little late to the party by tomhath · · Score: 2, Insightful

      As opposed to Postgresql - which is easy to use, works well, has tons of features, and is free in every sense of the word.

      Although I will concede that if you're already locked into being a MS shop and use .net for your applications then SqlServer might make sense.

    3. Re:a little late to the party by djbckr · · Score: 2

      ...but the cost is negligible.

      3 grand for 10 seats? That's negligible? PostgreSQL is $0 for unlimited seats.

    4. Re:a little late to the party by tomhath · · Score: 2

      The time it would take to learn and migrate to a new system would quickly eat up any cost savings

      Yes, that's what I said: if you're already locked in to MS and have already paid for the licenses you may as well stay locked in. I developed on SQLServer for several years and liked it. But if I was starting a new project today I'd definitely go with Postgresql.

    5. Re:a little late to the party by laffer1 · · Score: 2

      Our solution to this problem was to get a Jetbrains license for their suite. We already were buying Intellij (Java/web) and Resharper for .NET projects and this gave us data grip. While data grip is a relatively new product, it does all the basics with a much better UI, syntax highlighting and supports all of the databases we use including PostgreSQL, SQL Server, MySQL and Oracle. We now have one tool for all the databases we use instead of multiple. In our case, we have one enterprise app that uses SQL Server, we're phasing out Oracle and it's only used for our intranet at this point, we have one mysql database for a wordpress site and that's going away. All new projects are in PostgreSQL. Major cost savings.

      --
      MidnightBSD: The BSD for Everyone
    6. Re:a little late to the party by countach74 · · Score: 4, Interesting

      Postgres has always supported transactions, as far as I'm aware. And in fact, what you can do with transactions is pretty incredible and beyond what most databases offer. For instance, you can actually put most database migrations in a transaction. Something not go as expected? Roll back and your schema's all as it was. I'm wondering if perhaps you are thinking of MySQL?

  3. Microsoft got one thing right... by __aaclcg7560 · · Score: 2

    They're using Python 3 and not Python 2. I switched my codebase to Python 3 and uninstalled Python 2 a few years ago from my Windows PCs.

  4. Re:Just because you can doesn't mean you should by tomhath · · Score: 2

    You will get hit with all of the downsides of ignoring separation dogma

    Write your business logic in the language which is most appropriate and run it where it's most convenient. The "separation dogma" was a fad that has passed.

  5. Re:Just because you can doesn't mean you should by tomhath · · Score: 2

    somehow you think throwing in random code blocks in some other language where optimization for the data set is just about impossible and you don't think you're going to get serious performance hits?

    You're missing the point. Data access uses sql no matter what language your business logic is written in and no matter where the application code runs.

    The advantage of having that logic reside inside the DB server versus in a container or separate app server is that you save all the network traffic moving data back and forth; the app code is the same in either place and is just as modular either way. All that changes is where it's deployed.