Would you rather… ? (2)

Another simple choice this time 🙂

Assume you have 6 web services running off the same server (I\’m not a Web Service guy, so humour me a little).

4 of these Web Services tick over nicely, the 5th does not play nice with the others at times and the 6th is critical to line-of-business. When the 5th one decides not to play nice, it seriously affects all the other services on the box.

You have budget for a new server (this IS hypothetical after all).

Would you rather:

Protect the line-of-business web service by moving it onto the new server, leaving the 4 simple services and one bad boy ?

Or

Move the unfriendly web service to the new server, and leave the l-o-b service with the other 4 ?

Personally, option 2 gets my vote. If the unfriendly one decided to throw it\’s toys out of the pram, then at least it\’s the only one in the pram… It\’s kind of like moving the naughty kid to another class all by himself instead of taking smartypants out of school altogether.

Again, I\’d be interested in your comments !

Would you rather… ? (1)

OK, short one on partitioning this time 🙂

Kind of an odd situation, but we\’ve been having quite a serious discussion about this. Assume you want to partition by day (yes, 2day\”, we are quite mad), and you have to keep records in the partitioned table for a year.

Would you rather :

Create a partition function and scheme based on the date (2010-09-03), creating a new one whilst ageing the oldest each day

Or


Create a partition function and scheme using the DATEPART (DayOfYear) function, and reuse the partitions when next year comes around


And yes, this is in part related to the last post !


Because I\’m primarily a lazy DBA, I\’d go for option 2. It just seems a little more elegant – set it up once and let it roll. You get all the benefits of having the table partitioned without the headache of constantly maintaining it.


Comments are invited !

DBAs are from Mars, Developers are from Venus

Before you start, this is NOT a post about Multiple Active Result Sets, so don\’t get too excited (but don\’t go away yet either – hear me out).

A perennial challenge between the DBA and his/her development colleagues is that they speak a different language and some things are bound to get lost in translation. A good team will use many different strategies for coping with this, other people will constantly be at loggerheads. The DBA wants to use native tSQL, the developer C# CLR stored procedures. The DBA wants to use out-of-the-box functions in SSIS, the developer .net code. We\’ve all seen this.

Unfortunately, Microsoft don\’t make it any easier for teams to begin to understand each other, because they use differing constructs in different tools to accomplish the same thing.

I\’ll explain:

Situation arose today where it was needed to get the day number for a given date. Simple enough to do in tSQL – 

SELECT DATEPART (DayOfYear, \’2010-08-26\’);

Nice and simple. What really irritated was that to accomplish the same thing to add a derived column to a pipeline in SSIS, you\’ve got a different syntax:

DATEPART ( \”DayOfYear\”, [MyDateColumn])

(Note the requirement for the double quotes around the DATEPART specification)

Is this really a problem ? Not so much, but it certainly doesn\’t help when you\’re trying to convince a dyed-in-the-wool tSQL guy that they should really take a look at this pipeline ETL stuff called SSIS because it\’s really easy….

All I\’m pointing out here is that maybe things could be a little better integrated. SQL2005 introduced CLR and .net scripts inside stored procedures, but I don\’t see anything allowing tSQL to drive things the other way round.

Please could someone prove me wrong about this ? Is there such a \’killer app\’ that will let DBAs and Developers perhaps not talk the same language, but at least allow them to use a common thesaurus ?