Profilo di BenBens HouseFotoBlogElenchi Strumenti Guida
03 aprile

SQL - I don't like it.

Imagine the following Database setup
TableA has an ID column, AID
TableB has an ID column, BID
Table AB has 2 columns, AID and BID which realte to the IDs from TableA and TableB respectively.
 
Now imagine you want to delete one of the references between an A and a B from TableAB, easy.
DELETE FROM TableAB WHERE AID = @AID and BID = @BID
 
Now tidy up so that any As that aren't referenced by a B are removed
DELETE FROM TableA WHERE AID NOT IN (SELECT AID FROM TableAB)
 
You might want to throw those two lines in a stored procedure, call it DeleteAB. Now how do we delete all AIDs which are referenced by a specific BID whilst still keeping TableA as clean/empty as possible? One of two ways...
--Get a list of the used AIDs for the specific BID
DECLARE @AIDList CURSOR FOR 
  SELECT a.AID FROM TableA a INNER JOIN TableAB ab ON ab.AID = a.AID WHERE ab.BID = @BID
 
--Loop through the keyword list, calling the StoredProc (DeleteAB) to take care of the acutal deletion
DECLARE @Current_AID int
OPEN @AIDList
FETCH NEXT FROM @AIDList INTO @Current_AID
WHILE @@FETCH_STATUS = 0
BEGIN
  exec DeleteAB @Current_AID, @BID
  FETCH NEXT FROM @AIDList INTO @Current_AID
END
CLOSE @AIDList
DEALLOCATE @AIDList
Or the quicker way...
DELETE FROM TableAB WHERE BID = @BID
DELETE FROM TableA WHERE AID NOT IN(SELECT AID FROM TableAB)
The thing is, whilst I much prefer reading the SQL code for the second version, I hate the lack of architecture behind it. If we make an alteration to the Database so that A is not used somewhere else, the first example need only alter the StoredProc, whereas the second solution would need an alteration for both the single deletion and multiple deletion methods. In the world of a normal programming language (C# as an example) we'd more than likely go with the architecturally sound version -
public void DeleteAB(int AID, int BID)
{
  //Code to remove AB
}
 
public void DeleteAllAForB(int BID)
{
  //Foreach AID related to BID
  {
     DeleteAB(AID, BID);
  }
}
Why do we get sloppy on the design with SQL? Because we need the performance of the inline code. Not that I like it.
02 aprile

Microsoft Surface in AT&T Stores

I was reading this article (Microsoft Surfaces finds home in AT&T stores) when I wondered how many people wont understand the idea of dragging an icon on a touchscreen. Think about it - a big icon on a monitor looks like a button, so you expect to press it. Thanks to the last 30 years of computing, we expect to be able to click/press most things on a monitor and although dragging might make a lot more sense from some angles (to put a ringtone on the phone you drag the ringtone to the phone) we've had too many years of clicking-not-dragging to expect this change to work overnight. Is this what's preventing more touch specific applications for the tablet PC? And how did Apple manage to do touch so right with the iPhone?
01 aprile

Has Microsoft Lost Its Way On Desktop Computing?

Actually, I agree with this article on ZDNet (Has Microsoft Lost Its Way On Desktop Computing?) which basically says "yes", so this could be a very short "me too" blog post. And it is.