Douglas Purdy

On SQL Server Modeling

with 15 comments

A good amount of traffic on “Oslo” moving into SQL Server…

First, based on conversations that I am having on email and Twitter, one of the things we need to do is explain how we think the DSL capabilities of “M” manifest in SQL Server.  My previous post was all about the macro move of “Oslo”, not specific features.

I’ll post something on that topic this week (PDC is pounding me into fine dust right now).

Second, it is important to bear in mind that SQL Server is a big tent, likely bigger than you have thought, including things like operating over heterogeneous data, Office integration, etc.

Third, putting these technologies in SQL Server makes it more likely for any aspirations we had to come to fruition; as almost every single enterprise product that Microsoft produces leverages SQL Server – and this adoption is only getting greater.

Lastly, I think the PDC bits and sessions are going to make it very clear how this is going to help mainstream developers be successful and more productive writing applications.

Watch the sessions, use the bits, and decide.

November 10th, 2009 at 10:17 pm

Posted in Microsoft, Oslo, SQL Server Modeling, Software Development

« From “Oslo” to SQL Server Modeling
SQL Server as the Data/Information Platform »

15 Responses to 'On SQL Server Modeling'

Subscribe to comments with RSS or TrackBack to 'On SQL Server Modeling'.

  1. If ever you were fighting a loosing battle! The ‘SQL Server is a big tent’ argument makes no sense to the majority who have spent the last decade and a half thinking of SQL Server as a licensed database product rather than a huge and powerful Microsoft product group. Their perspective is not going to change. To them, the ‘move to SQL Server’ translates as a hopeless loss of vision for Oslo, and generally for modeling and DSLs on the Microsoft platform. Instead of a tool set that will empower development, configuration and management across the entire platform, they now see it as some poxy toolkit sidelined under the SQL Server branding that no one will ever use for anything and which will eventually be quietly dropped in SQL Server 2014 R2. You will have your work cut out to recover from this. You guys just don’t understand your own user base.

    jedR

    11 Nov 09 at 01:15

  2. This more and more looks like a solution in search for a problem.

    Right now this just looks like something that is trying to solve exactly the same thing that entity framework was supposed to solve.

    Do you remember all the promisis made about entity framework? How analysis services, reporting services and all the other SQL Server roles would operate off it? Now we are promised that Sharepoint, ActiveDirectory and SQL can make use of Oslo. Given the SQL track record, I’m willing to bet quite a bit that we will never see any of this.

    You’ll have to make sure to answer the following question: Why use Oslo now and not just entity framework? Why would SQL Server integrate M but not Entity Framework properly?

    I see two paths right now: 1) this goes deep into SQL server, i.e. SQL server becomes a M database. This sounds WinFS all over the place and I’ll start believing that this might happen when I have RTM bits on my machine. 2) this becomes another twist in the ADO.NET story, where you now want developers to model their data in M instead of entity models. But why? Entity models now have a nice UI designer etc. Do you really believe I’ll learn a new language just to model a database?!? This is going to end up as a niche project, if that is the path.

    The real second question is: does MS have any story left for DSLs in the .Net Framework? Without DB access? No? Given up on that? That seems the much bigger (hidden) news, that with this move you don’t have a simple, straight forward DSL story anymore at all.

    davidacoder

    11 Nov 09 at 08:52

  3. Blogged: “M” and Oslo’s Future – http://blog.jordanterrell.com/post/m-and-oslos-future.aspx

    Jordan Terrell

    11 Nov 09 at 17:39

  4. @davidacoder the promises were not about EF, they were about EDM and we are deliverying on that. take a look at the intergration of EDM in Sharepoint, for example.

    In terms of the direction with M, I think you have to take a step back and think about logical/conceptual modeling and how developers want to do that (graphically and textually) Based on what you say here, it is not clear that you have thought too deeply about it or talked to the number of customers that we get feedback from.

    In terms of DSLs, I’ll post something later this week, but the short short is that we still have these capabilities in the language and we have some new features that folks will be interested in.

    douglasp

    11 Nov 09 at 21:14

  5. I love it when the reaction to feedback is “I think you have thought less deeply about this than I have”.

    I’ve seen this attitude a lot at MS (this was the core of the WinFS team’s mantra!), and most of the time those teams never shipped anything, and those teams that were in sync with the community did.

    davidacoder

    12 Nov 09 at 09:14

  6. @davidacoder

    You made statement “Entity models now have a nice UI designer etc. Do you really believe I’ll learn a new language just to model a database?!?” that I was reacting to.

    I did respond with a Microsoft-ism (my apology if you took offense), in response to what seemed like a fairly off the cuff remark.

    I do encourage you to actually consider the possibility that you haven’t thought about all the angles here.

    If you look at the scenario that you describe, you already have a bunch of new languages.

    You have a data model (EDM). you a visual designer (a vDSL) over the data model. You have an XML format over the data model (a tDSL). You have a set of classes over that data model (another tDSL).

    My point was that customers have told us time and time again that the designer approach is not enough for them — they need a great text rep — and XML is not it.

    As it turns out the C/VB classes are not a great text rep either — as the set of semantics in the model is much greater than what you can express in a reasonable way on CLR classes (we have some experience extending the CLR type system through the magic of attributes and other conventions — not pretty).

    The net of it is that _a lot_ of people tell us to make M the text language for EDM/EF/DS/SQL.

    We are listening to customers that use our data stack and that is what they are telling us.

    douglasp

    12 Nov 09 at 09:34

  7. So the XML format for EDM will be replaced with an M syntax going forward? But EF is part of .Net Framework, how does this work if M now is part of SQL Server?

    I think what would be very helpful is if you could clarify whether any parts of Oslo will be usable without buying SQL. Like the DSL, M etc part. I see the point that the repository and Quadrant move to SQL, but I think most people got the impression that really the whole languate (M)/DSL part could be highly useful entirely independent of SQL and therefore don’t understand why this would move to SQL land.

    davidacoder

    12 Nov 09 at 09:59

  8. @davidcoder Why don’t you think that we can ship parts of the .NET Framework (or the whole thing) with SQL Server? As for purchasing SQL Server, there are lots of pieces of SQL Server that we do not charge for. We are still working through those aspects of the plan.

    douglasp

    12 Nov 09 at 10:12

  9. Uh, I’m sure you can ship the .Net Framework with SQL Server. But so far you shipped EF without SQL Server in dotnet (I’ll use as shortcut for .Net Framework). If EF now replaces its text DSL with an M grammar, M would have to be part of dotnet, or not? I think everyone interpreted your post as saying that M will NOT be part of dotnet but part of SQL, so I’m confused.

    davidacoder

    12 Nov 09 at 12:01

  10. @davidacoder

    I understand the confusion.

    What I am saying is a bit nuanced, but I think that it is important, since more and more of the .NET Framework is appearing “out of band”.

    We ship parts of the .NET Framework all the time with various products.

    The idea that this is some monolithic .NET Framework is a fiction.

    If you look at the Web Platform Installer, this is really clear.

    How much of that is in the .NET Framework 3.5 installer?

    But it is still part of the overall .NET Framework.

    douglasp

    12 Nov 09 at 12:35

  11. EF is in the .NET Framework 3.5 installer. If EF gets a dependency on M, how does that work if M is not in .NET Framework 3.5 installer?

    I find your definition highly confusing. To me, what is in the .Net Framework installer is in the .Net Framework. Then there are other products that build on that. Those are other products. Stuff that is in the Web Platform installer but not in the .Net Framework installer builds on .Net but clearly is not in the .Net Framework. Why make things complicated when they are really simple?!? Also, I can find not a single place where it says that the Web Platform Installer is part of .Net Framework.

    davidacoder

    12 Nov 09 at 13:11

  12. @davidacoder

    Do you think that ASP.NET MVC is part of the .NET Framework?

    I have a clean Win7 box with .NET FX 3.5 installed on it.

    I have no assemblies for ASP.NET MVC on my machine.

    If I run the Web Platform Installer and select MVC, I get some new assemblies that give me MVC.

    Note how we talk about it at http://www.microsoft.com/web/platform/framework.aspx.

    MVC is part of the .NET Framework, but it does not ship in the .NET FX 3.5 installer.

    This is a _good_ thing.

    We need the programmability aspects of our products (in this case the Windows Web Server) to be able to rev when the product does, so that developers can use the latest product features as soon as possible.

    As for the particular question, we have the M -> EF working today (which we will show at PDC) and there is no dependency between EF and M at the assembly level.

    Again, we are going to have great .NET and VS support for this, regardless of what we call it.

    douglasp

    12 Nov 09 at 13:42

  13. MVC is the perfect example of how it should be done. v1 was a small download that did not bring anything with it but MVC. v2 is part of .Net FX 4.0 installer.

    If this is the model you have in mind for M, kudos. Just the right thing to do. Have a small download with M that brings with it the DSL stuff and VS integration, and then once it is mature put it into .Net FX 5.0 and VS 2015. At the same time, run and write a post to clarify this, I’m sure everyone would love this and all the negative comments would go at once.

    But that is not how I understand the future of Oslo. I understood this such that M will be part of SQL Server. The MVC analog would have been if they said MVC will be available as part of Sharepoint (just an example). People would have run amok, I promise you.

    I also don’t understand why you would be able to rev more often if you bundle with SQL.

    I think all the negative comments boil down to one very simple point: people want M and the DSL stuff independtly of the product SQL Server. Everyone understood your post as this not being the case. If we misunderstood, this should be easy to clarify.

    Why are we not happy to have M as part of SQL Server? Simply because it implies that other products/technologies that have nothing to do with SQL Server will not use M, because they would get a dependency on SQL Server by using M. There are a gazillion use cases where I can think M and DSL stuff could be incredibly useful without ANY database server/repository/quadrant stuff.

    davidacoder

    13 Nov 09 at 13:16

  14. davidacoder summarizes it nicely.

    A point to make about the MVC analogy. MVC is part of ASP.NET because that is the platform that you’re writing software for. The dependency on ASP.NET is valid.
    If EF uses ‘M’ for its model – then great ! But surely you cannot mandate a dependency on SQL Server to enable this? This means to use the Entity Frameowkr you need SQL Server on your developer environment.

    Some organizations do not even allow the installation of SQL Server on developers machines because of the added security footprint. Data stores need to be managed centrally and patched by DBAs.

    It sounds like ‘M’ needs a delivery platform to make it a real product. It chose one of its biggest customers – which is fine. But delivery politics should not guide product architecture. ‘M’ should be part of the framework and used by BizTalk, SQL Server, SharePoint etc.

    Joe Wood

    17 Nov 09 at 22:33

  15. [...] specifically DSL development. I wonder what Microsoft have in stall for us with F# and the “M” modeling [...]

    F#: DSL Development « Tales from a Trading Desk

    1 Apr 10 at 16:24

Leave a Reply