Food From Faraway

Food
Last time I mentioned visiting Al Duomo in Brighton and being inspired to a recipe by an item written on their daily menu. Their offering, so far as I recall, was Pasta con Funghi Porcini e Rucola. "Pasta with Porcini mushrooms and Rocket" in England, where Rocket (from the german Rauke) is the name for Arugala.

After we finished out (very good) antipasto lunch snack we went to Asda to get ingredients to make dinner. These quantities were intended (roughly) for two but ended up enough for three!

about half lb of pasta                                      half bottle of light red wine 
a dozen mushrooms, 1"- 2" across    quarter lb butter
half lb rocket                      quarter pint crème fraiche
half a medium onion                 teaspoonful chopped garlic
olive oil

• Boil salted water, add a little oil, and set the pasta to cook.
• Fry the onion and garlic gently in the oil for a few minutes, add the butter and melt it. Slice the mushrooms in two or three and add them to the mix, making sure that they're well cooked to be tender.
• Once the mushrooms are done take them from the heat. 
• When the pasta is cooked to a little less than your taste, drain all the water from it, leaving it in its pot.
• Add the mushrooms only to the pasta and return that pot to a very low heat. The pasta will finish cooking.
• Add the crème fraiche (or light cream, or plain yoghourt, if you can't get crème fraiche) to the onion/garlic mixture in the frying pan and heat. Add a little Worcestershire Sauce for flavour, and then pour enough red wine into the mixture for it to turn a pleasing pink colour.
• Take the pasta from the heat and mix the rocket in.
• Lastly, add the sauce mixture to the pasta and serve.

I served this in bowls: plates would be equally good, and serving it over sliced toast would add a good base texture. Grated Parmigiano or a similar hard cheese goes very well indeed, with the rocket providing a crunchy texture to offset those of the mushrooms and pasta. A light red wine is an excellent accompaniment.


More Food
This morning a noted on FB that I was having Oeufs Pochés on toast for breakfast, which raised some interest, so here's what they are.

You may know "Poached Eggs" from England, which are made by cracking an egg gently and decanting it from its shell into an open-topped little hemisphere in which it will cook by floating in boiling water, You can get special pans for this or an insert for your normal frying pan. You can recognise the germanic influence here when you find that oeufs pochés are the original poached eggs, but created in an extremely free-form manner.

In this form you just boil some water. Then you crack the eggs gently on the side of the pot (so you don't get shell in the water!) and pour the whole content gently into the hot water, taking care not to break the yolk. Then you just wait for enough time to pass for the yolk to cook to your taste and use a large spoon to rescue your egg and lay it onto your freshly-toasted piece of bread. I like salt, pepper, and grated cheese on top.

Tech
A lot of people, especially people who don't use SQL very often, have found the Cursor and recognised that this is the equivalent of the loops found in procedural languages such as FORTRAN, Pascal, C, C#, SmallTalk, Java, and others. Then they cling to this construct like survivors of The Titanic to lifeboats.

If there's no great pressure of time, and if the tables involved are not in much use by other processes, then all is fine, and the cursor satisfies the need of the programmer to write code that varies according to the content of the individual tuples in the dataset obtained by the cursor.

However, a cursor (unless it is specified as real-only) can lock large parts of the table(s) from which it is drawing data, meaning that the process using the cursor is getting in the way of other processes seeking to work with the data. When these other processes are also using cursors life can get a little slow!

There is a simple way to improve this sort of code: use a table variable. This feature, introduced in SQL Server 2000, allows you to declare a table within your code and work with it there, completely independently of all other processes. Contrary to lore, a table variable will appear in the temp table, but only if it needs to - if it is big enough to exceed the amount of memory SQL Server has available in cache. However, the independence and specificity are the main attractions here.

The independence is provided by the ability to work with your own copy of the data - 80+% of all data accesses are reads in almost all installations, so you read in your whole dataset in one fell swoop rather than tuple-by-tuple, which is what the cursor will do. The specificity advantage is obtained by only pulling in the data you really need, and no other fields or tuples. Again, this reduces the impact on the system as a whole.

Once you have the data, you can use a simple while loop as below to work through it (the scalar variable declarations aren't shown but are obvious):

   declare @ta table (ID int identity(1, 1), --Identifier for the rows

                      Field1 nvarchar(50), 

                      Field2 int, 

                      Done varchar(4))       --Use to mark when I've done the row

   insert into @ta

      select Field1, Field2, 'No' 

      from   database.dbo.tblInfo 

      where  field3 = 'condition'

   while 'forever' = 'forever'              --This loop will never end

   begin

      set @intID = (select top 1 ID

                    from @ta 

                    where Done = 'No')      --Get top remaining unmarked record

      if @intID is null break               --Null if none left, so exit loop

      select @strFld2 = Field1,

             @intFld3 = Field2

      from  @ta 

      where ID = @intID                     --Get data to work with

/*

Do whatever processing you need to do here

*/

      update @ta set Done = 'Yes' 

                 where ID = @intID          --Mark record "done" to avoid repeats

    end

Taking the principle of doing less a step further, you can also use table variables for storing pointers (i.e. primary keys) to the data you want to work with in a much larger table, so that even when you do use a cursor, you've already done the searching part of the work with a set operation. In fact, creating a list table like this means that you can use it for further set operations, reducing the procedural part of the code even further.

These suggestions aren't one a par with the ones you get from the SQL Gurus at the sites on my Tech Links list (right), but they are techniques that should be part of your everyday arsenal of methods, kept on your Code Snippets CD, just like things like code for searching for code in all the sprocs in a database.

You do have a Code Snippets CD, don't you?

TTFN