Please stop using the database and start writing remote apps

As I get down off my soapbox from yesterday about overpriced third-party SharePoint tools and components I have a new gripe (seems like a good week for this). Time and time again I'm seeing two things become apparent in tools that are coming onto the market. First, some are just bypassing the rules of the road and doing stuff directly against the SQL databases. Second, about 9 out of 10 tools must be run directly on the server and require a local administrator.

Okay, first on the SQL stuff. I don't understand why developers can't get over this. You've seen numerous posts (including Fitz going on a few times about it) to get out of the database. So why do you keep doing it? My only reasoning is that you're frustrated by the lack of access to things that we think should be apparant and well, we can all write T-SQL so why not talk to it directly? What's the harm? I'm not going to get into the issues of what the database is doing as Fitz had a good explaination around that. Maybe that position should change though as more and more products are just blatently going against the database to do things like counting the number of sites in a portal. Rather than looping through a property in the Object Model, a quick "SELECT COUNT(1) FROM WEBS" will do the trick. So the $10,000 question might be should we be doing this? If you're using the database directly can you do simple selects, counts, etc. as long as you're not doing updates?

Second is the ever growing number of tools that keep requiring two things. One to be run directly on the server and two to be run by a local administrator. It's great for some tools because they are administrator tools, but I think the one big thing with SharePoint that people are having trouble with is the admisistration. More and more companies are either outsourcing their infrastructure or trying to get everyone to do their jobs from a single location. At our company, a huge effort just finished on stopping the free love access that users had to systems. The other thing is that a SharePoint administrator shouldn't have to have local admin to the SharePoint box. In a clustered or scaled out scenario, that means they really need access to several boxes (including the database servers). I think what we need is more tools that users can use off their desktop (via Web Services) to do the mundane stuff that SharePoint doesn't necessarily expose through the Web UI, or for custom tasks that are specific to your business needs. Again, we're given lots of tools but most of them we might be in a position to not be able to use in our environment due to restrictions on our infrastructure. I don't think the answer is to keep opening up the infrastructure to allow a SharePoint admin local root power but that's just me.

 

6 Comments

  • "Okay, first on the SQL stuff. I don't understand why developers can't get over this. You've seen numerous posts (including Fitz going on a few times about it) to get out of the database."



    The root of the problem is quite simple. I'm currently working on a project which involves Microsoft Project Pro 2k3 and Project Server. Unlike the excellent Reporting Services API, PDS is severely limited in functionality it seems. In addition, and this still baffles me, it seems like a *lot* of the features of Project are directly tied to the UI *gasp*!!1!11



    It's getting so ugly, that we may have to *automate the UI* to get some of this crap done. Good lord, who architected this stuff? So given the choice of *automating the UI* or going directly against the SQL Server DB, which would you choose?



    In an ideal world, all of the functionality of Project would be accessible via some class library that we could program against where the UI is simply another interface to this library (like Reporting Services). The whole situation is just ugly. I don't like going directly against the SQL DB, but the idea of automating the UI *disgusts* me even more.

  • Hi Charles,



    I agree that what is provided through the UI (or web services, or the object model) isn't ideal. I do ask the question anytime I get about "what were you guys thinking?".



    I guess the crux is that I see the UI, Web Services, OM (or whatever interface Microsoft provides me) for SharePoint as the public interface. It will change and I will update my solutions accordingly however just like any public interface, they'll think long and hard and we'll have plenty of advance notice (at least I hope we would) of these changes. With changes to the database, I don't care and if they want to normalize/denormalize for performance reasons go ahead. Writing against the datatabase may be easy and nice but it's like writing my entire domain in my UI layer. It's easy and it's one place to fix things but it's just not correct. Having the database change shouldn't be something I should care about when I install the next service pack nor should I have to retrofit code (unless again I knew a public interface in the OM might change).



    It is ugly and I hate going there. I just want to avoid it all costs because I know there's a better way (or at least I think there is).

  • MCMS is annnother product with this kind of problem. Stefan often posts about interesting utilities that lead to unsupported installations.



    For me, the temptation to interact directly with a products data store is because the product's UI can do something that I want to automate. The product doesn't have an API for that.



    I thought about UI automation, but I don't have time right now, so I just "forgot" about the whole thing

  • The point is that we shouldn't have to automate the UI.



    Reporting Services is the perfect example of the "right" way to seperate your business logic from your UI layer.

  • Hi Bil,



    You are absolutely right... we should do it the "correct" way, through web services/OM. But sometimes.... sometimes you just can'tt resist. An example: I need the complete SharePoint structure up to the list level for a sSharePoint statistics project I'm working on. I started out with your excelent web service based object model (SharePointWrappers), but it was a lot of programming work, and it was slow. I came up with the following three lines of code doing the same job for me. Ok, it's unsupported, it's not good, it's even evil... but this costs me 5 minutes to write, and if the database model changes I will have new issues anyway...



    My three lines of code (with some surrounding stuff, only the bcp commands count):



    @echo off

    @set CURRENTDIR=%~dp0

    @if (%1)==() goto usage

    @if (%2)==() goto usage

    @if (%3)==() goto usage



    @echo Dump SharePoint Site Structure Tool: Dumping site structure for database '%2' on server '%1' to directory '%3'



    @echo on

    bcp "SELECT Id as SiteId,FullUrl FROM [%2].dbo.Sites" queryout %3\%2-Sites.txt -c -T -S %1

    bcp "SELECT Id as WebId,SiteId,FullUrl,ParentWebId,Title,WebTemplate FROM [%2].dbo.Webs" queryout %3\%2-Webs.txt -c -T -S %1

    bcp "SELECT tp_ID as ListId,tp_WebId as WebId,tp_Title as Title, tp_ServerTemplate as ServerTemplate, DirName + '/' + LeafName AS RootFolder FROM [%2].dbo.Lists AS Lists LEFT JOIN [%2].dbo.Docs AS Docs ON (Lists.tp_RootFolder = Docs.Id)" queryout %3\%2-Lists.txt -c -T -S %1

    goto end



    :usage

    @echo off

    echo Usage: DumpSharePointStructure.cmd Server Database OutputDir

    echo Server - Name of the database server containing the SharePoint databases

    echo Database - Name of the database containing SharePoint data. The database specified must always end with _SITE

    echo OutputDir - Directory to output the result files to

    rem exit -1

    :end

    @echo off

    @echo Error: %ERRORLEVEL%

    rem exit %ERRORLEVEL%





  • Why do we keep writing unsupported code? Because the SharePoint architecture is so limiting, confusing, and difficult to work with that it sometimes feels like trying to write an enterprise application in Word VBA. I'll admit that I'm not a brilliant programmer, and that, I think is the point: between the security restrictions, the model limitations, and the things that plain don't work as documented a average joe VB developer like myself finds that figuring out how to do things "right" just takes too long. Microsoft's built its early reputation by providing tools and models that were accessible to average developers operating under the premis that "time is money" and MS tools help you do it cheaper. I have not found that to be the case with SharePoint, and don't even get me started on Project Server...

Comments have been disabled for this content.