Paul Nielsen
SQL Down Under Show 16 - Guest: Paul Nielsen - Published: 21 May 2006
In this show SQL Server MVP Paul Nielsen discusses object relational mapping vs relational databases and his upcoming Nordic framework.
Details About Our Guest
Paul Nielsen is a hands-on database developer, Microsoft SQL Server MVP, author, and trainer specializing in data architecture and Microsoft SQL Server technologies. His next book, SQL Server 2005 Bible will be available in early 2006. He just started writing Nordic in Action for Manning Publications. Besides holding several certifications he was the design subject matter expert for the Microsoft mock course 2784 “Tuning and Optimizing Queries Using Microsoft SQL Server 2005.” Paul has been developing data-centric solutions since 1982 and was the Enterprise data architect for Compassion International. A SQL Server instructor with Learning Tree, the technical editor for a database magazine, and a U.S. Navy submarine and data systems tech. He serves on the PASS, or Professional Association of SQL Servers board of directors, and is active in the Colorado area SQL Server user groups. For recreation Paul enjoys scuba diving, playing guitar, and hiking in the back country of Colorado.
Show Notes And Links
Show Transcript
Greg Low: Introducing show number 16 with guest Paul Nielsen.
Greg Low: Our guest today is Paul Nielsen. Paul is a hands-on database developer, Microsoft SQL Server MVP, author, and trainer specializing in data architecture and Microsoft SQL Server technologies. His next book, SQL Server 2005 Bible will be available in early 2006. He just started writing Nordic in Action for Manning Publications. Besides holding several certifications he was the design subject matter expert for the Microsoft mock course 2784 “Tuning and Optimizing Queries Using Microsoft SQL Server 2005.” Paul has been developing data-centric solutions since 1982 and was the Enterprise data architect for Compassion International. A SQL Server instructor with Learning Tree, the technical editor for a database magazine, and a U.S. Navy submarine and data systems tech. He serves on the PASS, or Professional Association of SQL Servers board of directors, and is active in the Colorado area SQL Server user groups. For recreation Paul enjoys scuba diving, playing guitar, and hiking in the back country of Colorado. Welcome Paul.
Paul Nielsen: Well thank you. This is quite an honor.
Greg Low: Great! As I usually ask, how did you first become involved with SQL Server?
Paul Nielsen: I backed into it. First started playing with computers in college and the only way to get computer time was to take a programming course. I had no intention of getting into computers but I wanted to play DekTreck on the PVP11 so I took a few programming courses and loved it. That’s how I got into computers, by accident. Over my consulting time I had a tendency to work on database-centric applications. I really got into SQL Server heavily when I was working with Gary and Donny, and they were Visual Basic wizards back in the days when it was all Visual Basic. Rather than switching back and forth between SQL and Visual Basic I wanted to get deep into SQL. I love data modeling so that’s how I got into SQL Server.
Greg Low: That’s great. One of the primary interests of this session will be object relational mapping and how that fits with databases. It’s been a great divide recently trying to work out how much we need to do relationally. Alternatively, the object purists would see the database as an object persistence layer where the whole thing could be done with one table called “object.”
Paul Nielsen: I agree with you there is both a technical and cultural object relational impeded mismatch. Technically objects in relational databases don’t match up very well and it’s aggravated because culturally the object world and relational world don’t respect or listen to each other very well. That makes it harder to find a solution. I got into it because in my consulting career most of the projects I worked on were failing databases, not being able to go into production, so I tend to do a lot of turnaround projects. A company hired me to do a turnaround on an object relational database that they had tried to write in SQL 6.5. I tried my best but gave up and went back to doing it relationally. Years later I was playing around with this idea of taking the database and doing data as a story. So let’s just record that Greg interviewed Paul on Skype. Paul married Edie at the church. Let’s record all of these stories as noun, verb, object, predicate. Then I realized maybe we could generalize, that the predicate, object, and subject were all nouns. Let’s fold that together and make it a noun-verb and then bounce back and forth and do cool things with that kind of pattern. Then I realized that the nouns and verbs had very similar look-ups and paths. Let’s fold it together and just have word associated to word. Then the light bulb went off that this looked a lot like what we were doing years back with SQL 6.5 doing the object database, I wonder if I could do that better now? I played with it and solved some of the problems of inheritance and polymorphism, things like that.
Greg Low: One point, just playing the buzz word police. A lot of people working with SQL Server may not be familiar with polymorphism and inheritance. Could you define those?
Paul Nielsen: Sure. Inheritance is the idea that if you have a class and then subclasses under it, that the subclasses will inherit the properties of the super class unless there are abstract or private properties, there are always exceptions. So if you have an animal class that has an attribute of date of birth then the mammal class underneath it would inherit that date of birth attributed property. Polymorphism in the data world, instead of flowing down, it flows up. Most object programmers think of polymorphism as taking a method and then in a subclass you change how that method functions. For example if you had a class called vehicle and a method called accelerate then the motorcycle implementation of accelerate would be different from cruise ship, but both of which could be subclasses under vehicle. Both of those methods would be different. If you’re talking about data entity classes and persisting them then polymorphism takes on a different twist. The verb or the method of select takes on the meaning of if we select all humans then we’ll get all humans, if we select all mammals then you’ll also get all humans because a human is a mammal. If you select all animals you get everything in the animal kingdom. Basically it means when you select you include the objects of the class beneath it so objects flow up the class. That’s polymorphism in the object world.
Greg Low: Given the difficulty in the SQL Server 6.5 days of doing that and that you’ve got clearer ideas now, is it that the ideas are becoming clearer now or is the product enabling you in some way now that it wasn’t then?
Paul Nielsen: I think it’s both. Over time you think about the problems from different angles. Time and experience are aspects of it but the real key that unlocked it would be user defined functions. Having a table valued “user defined functions” that allows you to easily navigate up and down the hierarchy tree within the code of SQL. That’s what made it elegant and simple in SQL 2000. The object relational database attempts of the late 90’s were declared dead or a failure, but I think that what has happened is that the relational database platforms have matured enough, SQL Server has matured enough, that now we can go into the relational engines and design and model the object world.
Greg Low: Most issues I’ve seen over the last couple of years are in performance. It’s not that there isn’t some way to model these things, there’s always some way to model it given that the modeling isn’t that precise. People tend to get looser models, allowing for the fact that they’re dealing with objects that are differently shaped to those in a relational world. The big concern is I’ve seen a number of projects with prototyping and they’ve been really happy with what’s achieved but as soon as they load or stress test they’ve had significant performance problems. Talking to the object purists, they argue that performance is like an implementation detail but the reality is you can’t ignore it. Do you still feel we can get reasonable levels of performance?
Paul Nielsen: I believe so. Because it’s SQL Server, if you think of terms of being a database architect or a SQL developer, I think you can manipulate it within SQL so you get good performance. I know that’s talking around the issue. Specifically for the object table it’s not a very wide table, the association table is very narrow. There are lots of opportunities to tune and build covering indexes. In one of my iterations I was using GUID and I had terrible performance. That was one of the things I was finding in iteration 16 or 17, I’m on 20 now. So I made up a dozen connections, pumped objects into this system, and tuned the indexes and found some of the bottlenecks in the performance in the functions and stored procedures, and got it so that my transactions/second went from 300 to about 3500. It’s SQL so you can tune it. It’s great.
Greg Low: The object guys argue that in time it will be less and less of an issue. I saw one a little while ago who said if you think back we used to worry about controlling the paging of memory that was being used by programs and we don’t worry about that anymore. The argument is there’s a purity in what they’re doing and that performance will catch up but the reality in many situations is that you still need substantial tuning that is not part of the model.
Paul Nielsen: I understand the purists but I’m not a purist. I try to build things that are very practical and they have to work. A logical data model has never held any data or done any good except as a starting place to build a physical data model. That’s my view on it.
Greg Low: A simple example, if I had a stock table and there was a quantity that was there at the last stock take and we want to clear all the values. The difference between rehydrating all the objects and changing the value in the object and pushing it back down, compared to just saying to the database go into that table and zap the value in that column for every row…It’s complete chalk and cheese.
Paul Nielsen: That’s partly the benefit of a relational database that’s modeled in a relational manner. You can pull data out in a way that you have inheritance, polymorphism, complex collections…you can still query it, give it updates, create stored procedures, views, and functions to get to and search the data so you have an abstraction layer. So it isn’t just taking objects and hibernating them into the database or taking .net objects and storing those in the database. The table structures look very easy to play with relationally. I guess I deviate from the norm in that I do associations with one long list and that you have to see some diagrams to play with. I’m not going to say NORDIC is useful for every problem. There are some problems for which a relational database would be faster, easier, better. The object model is good when you have lots of inheritance you can take advantage of and you can then model associations with the super classes and then the subclasses can all take advantage of that.
Greg Low: Did you ever get a chance to try any of the object databases, the ones built to be object databases? I must admit I’ve never spent any great amount of time with any of them.
Paul Nielsen: I’ve done some reading about them and demos, not much hands-on production.
Greg Low: Wondering if it would be a good thing to add some sort of table inheritance into SQL Server, do you think?
Paul Nielsen: Regardless of how it’s worked in, inheritance allows you to do things as a data modeler that in relational data modeling you just can’t do. Or if you do it you’re really pushing the super/sub type model and forcing it. You end of designing things completely different with just relational ER diagrams.
Greg Low: I’ve seen it taken to way too far a degree. Modeling examples where people have spent amazing amounts of time modeling and they end up with something that might be pure but is unbelievably complex as well. As soon as you get a whole lot of deep hierarchies it can be really hard to follow what is going on.
Paul Nielsen: I agree. Some of the models I’ve done, here’s a person and the association is “attends an event.” Then person and event are both abstract classes. Under event you build concert, sales meeting … Under person you have employees, contacts, customers, major customers… Because you can associate at the top level of the classes, it’s very fluid.
Greg Low: Should actually define abstract class, on the lookout for developer buzz words.
Paul Nielsen: An abstract class is there only as a template for the subclasses beneath it. For example, going back to animals again, you can define an animal class then under it have a mammal class, bird class, insect class. You can add objects to the mammal, bird, and insect classes and animal then is only a template class to provide attributes for each one.
Greg Low: I think they usually describe it as “has no implementation.”
Paul Nielsen: Yes.
Greg Low: The other area whose boundaries might get pushed is probably even in T-SQL itself. For example the idea that we can build CLR type objects. Is it desirable in T-SQL to be able to build a stored proc that took animal and be able to cast cat type to it?
Paul Nielsen: Maybe. I still am enough of a relational guy that I want to see the data, query it, do joins. That’s why I’ve been trying to say within the relational world, how do I model some of these cool “00” concepts? I designed and built all this in SQL 2000 before 2005 was stable.
Greg Low: Let’s start talking specifics…NORDIC is the current name?
Paul Nielsen: We think so.
Greg Low: For the listeners we had a little discussion over the last few weeks as to good names for the framework. What are you trying to achieve with it and where are you heading with it?
Paul Nielsen: Good question. All I’m trying to say is here is an interesting model and throw it out to the community to see if it sparks more development or somebody can use it. I don’t think it’s going to overthrow the relational world. I’m trying to culturally bridge the object and relational worlds. I don’t want to start a software company and launch it as a product. Although open source is a strange word in the Microsoft community, it’s not completely open source but you can download the PowerPoint slides from my website and there’s going to be an article in the Microsoft architecture journal and I’ll be putting more white papers out there. The website is
Greg Low: In essence, what are the main pillars, main ideas that are in this?
Paul Nielsen: The goal is to emulate object orientation inside of a relational database. You get the benefits of the O world but you don’t have to give up the financial strength of Microsoft providing a database engine that is very scalable, has high performance, lots of known DBA techniques. If you don’t want to move to an object database you get the best of both worlds. As far as implementation it has classes and subclasses, inheritance, polymorphism, associations, complex associations, and complex collections. And because the association class is a list, you can bounce back and forth between the object and the association class. You can ask, “here is a contact show me every way our organization has touched this contact.” Just with one user defined function it will return back a listing of every association, regardless of the class. It will return back, for example, two tech support calls, we called him, two orders, one warranty claim. For a CRM implementation this is very cool. For straight accounting, it might not be so cool.
Greg Low: Give us an idea of the table structures you’re using. If you were modeling, what sort of tables would be there and what sort of entries would be in them?
Paul Nielsen: There are a set of meta-data tables that store the class, attributes, work flow state and the rules about the associations. So when you call the façade command, “Create Class” and give it information about the class, it stores the data in the class table as well as goes in and creates what I’m calling a custom cascading class table that stores those custom attributes under the object table. There are a few patterns for that and I chose the cascading class table as opposed to concrete class tables or the generic or diamond shaped pattern.
Greg Low: I might get you to define that as well, the idea of a cascading class table.
Paul Nielsen: It’s obvious if you look at the PowerPoint or class diagram. Basically, if you’re using concrete class tables you would have one table to store all the attributes for a class including the inherited attributes. You would create a mammal table that would have all the attributes from animal and mammal. Another one for the insect table that would have all the attributes from animal and insect. A cascading class table goes vertically where we have one table for all the animal attributes, one for all mammal attributes, another for all the insect attributes. If you want to store a new mammal you have to add to the object table, the animal table, the mammal table and you have to join between those. It’s a trade off if you want to do joins to select out all the attributes for the mammals and make it easy to do polymorphism or do you want to make it easy to get all the attributes for an animal without doing a join but you have to jump through hoops to do polymorphism with lots of unions where you’re faking up columns.
Greg Low: I’ve often seen the later version done. I came across one recently where someone had the base class and they just built one table for their base class and for every inherited one they just kept adding columns. If they had an animal class they would have all of the columns related to an animal but as soon as they added a cat they would add the cat columns to the animal table as well. If they had a dog they would add the dog specific things to the animal table. Eventually you ended up with an animal table that was unbelievably wide with a whole lot of nullable columns related to all the possible objects. If you’re doing that you then have to store something in the row that says what type it is. If you follow that out you would end up with an object table with just one table since even the animal is an instance of some sort of object.
Paul Nielsen: I do have an object table with the meta-data, the common data, for every object. Basically the object ID, what class it is, work flow state, columns for searching. The trick then is if you go to that table and you have a row for cat and you want to select all animals, you hit the cat. So you have to build that kind of polymorphism into it otherwise you don’t have a “00” implementation.
Greg Low: What you’re suggesting is if you have an insect table that just has the insect properties, by querying on the insect table and joining that to the animal table we’d get the things that we need to do with an insect, and we’d only get insects as well. Good time for a break.
Greg Low: Welcome back. I might get you to share about where you live, interests?
Paul Nielsen: I live in Colorado Springs. Widowed, I have two teenagers and just got remarried to a wonderful woman named Edie. Honeymooned in Hawaii and fell in love with Kauai which almost became the name of NORDIC. My son is into downhill biking and he collects stitches.
Greg Low: I noticed you’re into scuba diving. Kim Tripp just talked about scuba diving.
Paul Nielsen: I wish I could scuba dive more, but living in Colorado and traveling…Wish I lived closer to the ocean and had more vacations to get to scuba diving sites. I noticed that too listening to Kim Tripp--another diver!
Greg Low: Did you get involved in scuba diving while doing the submariner thing?
Paul Nielsen: No, just recently I got into it. There’s an active community in Colorado who train in pools then they take chartered flights to the Caribbean or to the Pacific. Diving is a very techie thing to do, lots of new things to learn. Really exciting.
Greg Low: I note an interest in guitar as well.
Paul Nielsen: Yeah, in college I was a music major and wanted to be a jazz musician until I heard the others and realized I would end up teaching high school music. Didn’t want to do that and then I discovered programming. But I had fun, recorded some mp3’s. I ought to post them on my web site or something like that. These days I don’t have much time.
Greg Low: Talked to Cal Franklin a couple of times about the relationship between people playing music and developers/IT workers. Often wondered what the relationship is.
Paul Nielsen: Music is essentially patterns and if you immerse yourself in patterns musically the brain that resonates with and enjoys patterns will find those same patterns in software, especially in software development. That’s what I love most about data modeling is I’m identifying patterns and creating patterns.
Greg Low: I’ve listened to a lot of Cal’s music and its stunning. I recall the one he recorded for his nephew called “The great crusade.” Absolutely magic. Not just ordinary quality, it’s really first class. Music is a whole different world. I spent a lot of time in bands, late 70’s/early 80’s. People who had straight jobs during the day and completely alternative when out playing in bands. Biggest legacy is my kids find it funny they’ve got vinyl albums that dad’s on.
Paul Nielsen: Another correlation between musicians and software people is musicians have to work together, create a musical space, and collaborate. In the software industry you have to do that these days.
Greg Low: That’s another amazing coincidence. Certainly playing music is very collaborative. You wouldn’t be doing it by yourself. Back to object relational things. Pablo Castro and the team posted video of what looks like 2.1 or 3.0, the next main version. What they had done was look at the data provider level, and they had provided a map provider that sat above that with the same interfaces so you could talk to the map provider and, say, ask for a data reader. It was a layer above the database that had been a series of XML configuration tables but what they were looking at was a configuration file-based mapping that sat above with very similar interfaces. They said this would shield application developers from changes in the underlying database and so on. I was left with the feeling that I could have done the same with stored procs and views. Any thought on having another layer at the application development layer which is a whole series of mapping files?
Paul Nielsen: The database as a component needs to have encapsulation and a good abstraction layer just like any other object out there. Some of these schemas that are mapping layers, link and de-link, but if all it does is build dynamic SQL into the database that won’t be very extensible for the database in the long term. It will be like the other databases that have lots of dynamic SQL, BTS packages, and reports so the database becomes brittle and you can’t make changes to the schema over time.
Greg Low: Immediate reaction I had was kind of negative. They said an advantage was it would shield the development applications from changes made by the DBA but I was left with the feeling that the mapping files would be managed by someone apart from the DBA. I didn’t like the idea that if the DBA wants to make changes, they then have to run around and find out which mapping files to update. At least if you have an abstraction layer like stored procs and views, as long as the interface stays the same then that’s the point of it--the person making the changes could then ensure that they’re OK.
Paul Nielsen: Right. Some other problems I have with the mapping solutions out there are nobody’s talking about taking the ETL packages, DTS, IS or reporting services queries and putting those through the mapping layer as well. You need some way to have a complete abstraction layer or the database isn’t going to be extensible. Another aspect, if you think about trends in application code, they’re very short. ADO.net1, ADO.net2, Link, … all of these technologies that sit around the database come and go very quickly whereas schemas that are designed often stick around for a couple decades. That’s another argument for having the abstraction layer physically part of the database, not sitting on some other box.
Greg Low: Interesting that the video was gone again later in the week so I’m hoping they’ll repost it back up on the Channel 9 site soon. The examples they had were saying if we have a contact under the covers but we want to expose employees then this was shielding it out. Struck me that there were already good database artifacts to do this. The only thing interesting was that it could be across database servers and types of servers so maybe it was a shield from that sort of thing. I admit I do like that it’s compatible over the versions, that’s good.
Paul Nielsen: It’s human nature to solve a problem with the tools and skills we’re most comfortable with. A database person will try to solve it within the database and the .net folks will try to use .net.
Greg Low: If any listeners get a chance to look at that on the Channel 9 site, it’s worth a look. It was the team posting it. What’s the next step in terms of the framework things you’re putting in place?
Paul Nielsen: I’ve got a book contract to write about it. I want to do a couple of white papers. Right now it’s all in T-SQL because I love T-SQL, it’s the romance language of data.
Greg Low: I saw you said that to Chuck the other day, “The romance language of data.”
Paul Nielsen: The best way to woo data from the database. It’s funny we’re saying that but it’s true. One of the problems I have with the purists is they want a relational database and they’re frustrated with the SQL language. I like SQL. I think it’s really cool. As far as NORDIC, I want to have webcasts that explain and demo it at the T-SQL level.
Greg Low: How complete is it?
Paul Nielsen: All the hard stuff is done. I need to do more polishing, the functions to do updates… and it really needs a GUI so we’ve designed out a class-builder interface as well as a generic object browser. I have a friend who is great with .net and is playing with that stuff now.
Greg Low: Struck me as that sort of thing that would need a configuration or admin tool.
Paul Nielsen: I’ve presented it to a number of user groups and conferences and you really have to understand a lot of concepts and understand T-SQL to watch me play with T-SQL code creating this stuff. It needs to have something else to it. I’ve got an information architecture principle I’m pushing to help us be a principle driven community. I’m working with this idea of optimization theory which says that there are dependencies between different optimization performance techniques. A good schema makes it easier to write set based queries. Good set base queries and a good schema make it easier to do good indexing. If all three of those are there then your concurrency problems will be solved and all of that leads to scalability. Breaking down the details of that helps to say this is a framework for performance.
Greg Low: Often in discussions on normalization, concepts like concurrency almost never come into the discussion. For anyone who works with it on a daily basis, often issues related to normalization are driven by concurrency issues. It’s almost never part of the pure design.
Paul Nielsen: I’ve encountered data base modelers who are not concerned if their designs are easy for set based queries, they don’t know how to write queries. They say “that’s the programmer’s problem; my job is to make sure there are no nulls in the database.” Those of us who are pragmatic and are hands on database developers and data modelers try to create a schema with more goals in mind than just being normalized.
Greg Low: On the topic of nullity, I was reading Joe Celko’s SQL Apprentice blog and he has very strong views on nullability of columns. Do you use many nullable columns?
Paul Nielsen: You have to deal with optional data some place. To be practical you need to capture what data you can. If you accept there will be some optional data there are only three ways to handle it. One is what I call a null row which means you take that attribute, put it into another table and if there’s no value there you don’t put a row there. You go to a one-to-one relationship with it. That causes performance and integrity problems if your developers don’t know how to get all of that nullable data. Option two is to have a regular nullable column. There are pros and cons to all of these--you still have to handle the null with an isnull function. The third way is with a surrogate null.
Greg Low: Surrogate null in terms of a special known value, you mean?
Paul Nielsen: Yeah, you put in NA or an empty space. A surrogate null story: here in the US a two year old girl was summoned to jury duty and of course she can’t go, she’s only two. Turns out when the birthday is unknown they put in 1776 as a surrogate null. Somebody did a report that said everybody born before this date show up for jury duty. If you have a surrogate null you better understand it in your reporting too.
Greg Low: That’s a great story. When we were at the PASS conference last year, one TV show talked about similar identity problems. They were talking about the problem airlines have identifying people. Currently all they have is the name. They found a name, David somebody, and some really bad guy has that name and everyone with that name who shows up at an airport gets well and truly searched. They realized this was an issue and they went around the country interviewing everybody with that name. It was totally fascinating. Even parents were saying that their seven year old kid, David, is the one that gets taken off. He was getting completely paranoid and they had no idea why their son was getting searched every time at the airport. A rabbi with that name spent six months filling in forms and talking to government departments to get off the list and he says the only difference is now he gets searched every time.
Paul Nielsen: There are advantages to actual keys but there are disadvantages too.
Greg Low: What they were suggesting is that the populace doesn’t trust the government with the details about someone. One government proposal was that when you booked a ticket they wanted to send it out to 10 or so different providers each of whom would come back with an opinion if you were probably who you said you were. And then they would make an estimate, based on the goodness feel of what they got back, but they wouldn’t have all the details themselves. Sounded overly complicated but I do sympathize since it’s really hard to do that. I hadn’t come across the one of the poor kid selected for jury duty. Nullable columns in your case, you’re happy with them but it’s just where the data is unknown at the time?
Paul Nielsen: Right. It’s data that’s optional, unknown at the time, or doesn’t apply. As a business you have to decide do you accept the data that does apply or that the customer does have? I became looser working with nulls when I was with an organization working with third world children. Sometimes the data is not available but you want to accept what you can.
Greg Low: Things coming up in your world? We can start with the PASS conference and PASS board. Any news? Things coming up at the upcoming conference?
Paul Nielsen: Well, talking to you is pretty exciting. I’ve been on the PASS board since the last PASS summit. It’s been an eye-opener seeing how hard they work, getting to know other board members and I’ve enjoyed that. I was in Montreal for the PASS board summit and the Montreal DevTeach conference. Had a fantastic time. Was in Barcelona last February.
Greg Low: I really enjoyed Barcelona. I did present once, oh, you were in the session.
Paul Nielsen: I loved your session. It was excellent.
Greg Low: I enjoyed Barcelona. It was a smaller conference but it was great.
Paul Nielsen: Plans are coming into place. My portfolio on the PASS board is online content and I expect to have exciting news and announcements at the PASS summit in terms of online content. Personally things I’m doing besides NORDIC is a workshop called advanced design and optimization which digs into optimization theory. Shows you how to design or refactor a database that flows well from a holistic standpoint down to the individual details and techniques.
Greg Low: The summit coming up, November in Seattle. Encourage people to get along to that. The one in Dallas was excellent so anybody who was there should be keen to be at the next one.
Paul Nielsen: There are advantages to being in Seattle. Almost all the Microsoft SQL people can attend and it’s really great. We can’t announce yet who the keynote speaker will be but some of the people we’re talking to are extremely exciting.
Greg Low: Chuck mentioned that the number of submissions for sessions was really good and high quality.
Paul Nielsen: That’s what I’ve heard. Bill Graziano is head of the program aspect of PASS and he said the number and quality of abstracts are twice as great as last year. Some tough decisions. Every indication is that this will be one of the best PASS summits yet.
Greg Low: Book wise, is the new book nearly out?
Paul Nielsen: Yes, SQL Server 2005 Bible is 1,418 pages. I’m copy-editing the proof now and it should be out sometime end of July.
Greg Low: Which publisher?
Paul Nielsen: With Wiley. It’s a follow up to SQL Server 2000 Bible. Wiley let me experiment. Instead of only having figures with captions, I can also put an icon there for screen captures. So I’m putting just two to five minute blurbs on my website. I want to put up 50-70 of these to show how to do one little task, watch me do the code, etc.
Greg Low: Back at the MVP summit a few of us got taken off to a press session. A few Microsoft Vice presidents were there. I talked to them about how I see people learning to use products--they just ask somebody else and they show them how to do some little thing. I don’t understand why there isn’t already a huge bank of things that can be searched straight from the product and maybe a one minute video comes down and shows you how to do it.
Paul Nielsen: When I worked with the organization that helped third world kids, they had offices all over the third world. This guy, Kenny, spent tons of time recording little snippets of how to do things in Excel, in Outlook, and that’s how he did world-wide training. And I thought this is really, really cool.
Greg Low: That’s exactly the way it should be. There are so many of the MVP community who would be more than happy to build all the little snippets.
Paul Nielsen: Well, you don’t have to get into Microsoft, you can just put them on your site.
Greg Low: Yeah, but bandwidth might be a bit of an issue for people, serving up all the videos. Anyway, that brings us to time. Thank you very much, Paul, for being on the show.
Paul Nielsen: Thanks so much. It’s an honor to be on SQL Down Under and to talk to you and to be on the list of dignitaries of SQL Who’s Who that you’ve interviewed.
Greg Low: Thanks Paul.
Phone: 1300 SQL SQL (1300 775 775) l International +61 1300 775 775 l Fax: +61 3 8676-4913
Copyright 2017 by SQL Down Under | Terms Of Use | Privacy Statement