The Anti-Social Network – an opinion.

The Anti-Social Network – an opinion.

As some people may (or may not) have noticed, a rather large social network made a fairly insignificant change to it\’s UI recently.

There then followed a large number of negative comments (at least in the circles I move in) about that change. Please note, the reference to circles does NOT mean I\’m talking about G+ here. And the main comment was along the lines of:

\”I\’ll decide what\’s interesting or relevant, that you very much !\”, followed by much gnashing of teeth and high dudgeon.

So, the question is, how does a company / application / whatever \’decide\’ what\’s relevant to you ? With the best will in the world, machines are still unable to predict an individual\’s behaviour or motivation (although they are rather good at predicting what a large number of people will do).

Just because one of your contacts refers to cycling a lot in their postings, it does not mean that you are also interested in cycling. If a number of your contacts happen to be in the same place, it does not follow that you are interested in events in that place – you could be halfway across the world at the time.

We know from various clever people who design data-mining algorithms that behaviour can be more or less predicted across a social profile, group, key demographic, etc, but the closer you get to one actual person, I believe that the prediction becomes less and less accurate, and therefore more and more intrusive.

There\’s a well-known example in the Analysis Services tutorials from SQL Server. You take a number of facts, and you can then infer that a man of over 40 but under 55, with a wife, two children over the age of 20, and who lives within 5 miles of his workplace is more likely to buy a bicycle in the $500 – $800 range. That\’s well understood.

But it does not mean that every man fitting that profile is in the market for a new bike. Nor does it mean that the largest number of bike sales in that price range are to men in that profile. Data aggregations are great for Business Analysis and shaping future decisions to increase revenue or broaden market share, and even (in one case I know of) change the business model entirely to focus on what they do well that generates the best bottom line. But, when it comes down to actual people (not business) it\’s less useful.

However, we live in an age where e-marketing / e-advertising is largely free (the return rate can be as low as 1 -100,000 and profit will still made), so I can\’t see there being a shift away from inappropriate \’recommendations\’ any time soon.

It\’s just that I don\’t like being second-guessed by software. It\’s creepy, and usually wrong.

Back soon…

Temporary ( ) variable – A couple of points

Temporary ( ) variable – A couple of points

*The word between the parentheses is \’TABLE\’

It\’s been another one of those days when you realise that you don\’t really know as much as you think you do.

This time, it\’s table variables and temporary tables . You assume that temporary tables exist in the current database context, and that table variables exist only in memory.

Or at least, that\’s what I assumed. I was wrong. On both counts. They both exist in TEMPDB.(point 1)  But not exactly how you might think. (point 2)

Here\’s a small snippet you can use at home to prove what I\’m saying:

–Execute in ANY database context

CREATE TABLE #temp1
        (ID INT NULL)
       
DECLARE @temp1 TABLE
        (ID INT NULL)
       
SELECT * –< I know, but it's useful to compare the data
FROM tempdb..sysobjects
WHERE name LIKE \’#%\’

DROP TABLE #temp1

I\’ll step through this, if I may….

Firstly, pick a database context. Any database context will do, as long as you can execute SQL statements therein. 🙂

Then create the temporary table. (Note: There\’s nothing \’temporary\’ about temporary tables – they\’re real tables, and it\’s how you use them that makes them temporary)

Just for fun, skip the creation of the table variable and do the SELECT from tempdb..sysobjects. You don\’t have to include the WHERE, but it narrows things down a bit.

What you should see is an object that has a name a bit like the temporary table you just created, except it has some extra underscores and what looks like a hex value at the end. It\’s definatley your temp table, though. What\’s interesting about this is that SQL Server has to maintain an object reference somewhere to match up what you called the table, and what SQLServer called it in tempdb. Perhaps each of those references requires a bit of memory, so it\’s not quite as lightweight as you might think ? An ordinary table doesn\’t have these requirements.

Moving on, you\’d expect from this that the table variable you create would have a name of @temp1 (in the example), and possibly some underscores and a hex value at the end. Or is it just me that expected that ?

What you get when you create the table variable is….. well, you do it and see what you get…. Oh, you haven\’t got access to a SQLServer at the moment ? Right, so I\’ll tell you….

You get an object whose name starts with a \’#\’ sign, and eight characters representing a hexadecimal. Each time you create the table variable, you get a different hex vlaue, even if your definition is the same (I just got #6C190EBB and #6E01572D). This appears to be random (although you can never be sure with random).

What\’s REALLY interesting is that if you execute the script above several times, the hex value in tempdb for the temp table is INCREMENTAL. You start with 00000000, then 00000001, through 0000000A – F, 00000019, then 00000020, 000 021, and so on. Go on, give it a go. Even if you create the same temp table in another session, the hex value increments. THAT was unexpected !!!

Wait.

It gets better.

Change the name of the temporary table (and don’t forget the DROP change as well), and examine the name generated in tempdb. The first part of the name is your new table name, but the hex value at the end has incremented by one.

Go back to the first script and you\’ll see that the hash value has AGAIN incremented – even though you\’re referencing 2 different objects, it would appear that SQL is keeping count of the number of times a temporary table has been created.

And THAT, dear reader, is most interesting.

I wonder what happens when the 8 character hex value overflows….. But that\’s for another time, I think.

Back soon …