Striving to be the person my dog thinks I am.

I was working on the new application database recently, and it came time to create some triggers to keep date/time and a few other fields up to date. Therefore, it seems like a good time to talk about trigger naming standards. They’re simple, because I’m convinced trigger use should be limited (see Trigger-holic, below). At most, I would expect to find three triggers on a given table; one each for the three triggering events, insert, update and delete. Also, the impact of the trigger should be fairly limited — at the very most — to the table with which the trigger is associated.

With that admonition, the standard trigger name consists of three parts; the name of the table with which the trigger is associated, followed by the event(s) that fire the trigger, followed by the letters Trg. For example, the trigger on the table Dog executed every time a record in inserted or updated, would be called DogInsertUpdateTrg. If the table was called Breed, and the trigger was fired on delete, then the trigger name would be BreedDeleteTrg. As with other naming standards, the three parts of the trigger name as distinguished through the use of camel case. As usual, you’ll see that I have traded a succinct name for one that is a little more verbose, but easy to understand.

Also, keep in mind triggers are associated with schema names, and it is suggested that the trigger schema and the table with which it is associated be the same. For example, if the schema was VetOMatic, then you would want the trigger(s) on this table to be associated with the same schema. The examples above, triggers would be fully specified as VetOMatic.DogInsertUpdateTrg and VetOMatic.BreedDeleteTrg. Don’t get me wrong — VetOMatic is a terrible schema name, but it works for illustrative purposes. More on SQL Server 2005 schemas in a future post.

I’m a Recovering Trigger-holic A long while back, when I first introduced to SQL Server 2005 triggers, I went kind of ‘trigger-crazy’, figuring they were the cure that virtually everything that ailed me. I even went so far as to have triggers create and delete records in related tables to ensure referential integrity was being maintained. It turned out to be a very bad idea. When I eventually handed over the database to someone else to maintain, they were totally flummoxed by records appearing out of, and/or disappearing into nowhere. What I learned from this experience is logic implemented by triggers is not self-evident. More specifically, they don’t show up on the database diagram on SQL Server Management Studio. That’s my primary method of communicating database structure, and the diagrams do nothing to communicate the trigger logic. So these days, I’m limiting trigger use to maintaining date and time stamps, and also, by linking changes to database content to a session record.

OK, that last part was really not much to do with the naming of triggers, but useful information anyway, hopefully. As always, thank you very much for reading, and by all means, let me know what you think.

Recently, I was reviewing and rationalizing a group of keys and indices for a revamped database design, so I thought it was a good time to talk about applicable naming standards for these types of objects.

The default names SQL Server 2005 comes up with aren’t all that bad, actually.  For example, the primary key for the table Dog will be, unless you specify otherwise, PK_Dog.  If you create a foreign key on this table to a table called Breed, it will be called FK_Dog_Breed.  In addition to these basic keys, let’s assume you create a unique index on Dog.nm; that index will be called IX_Dog.  So far, so good, particularly given most tables will have some combination of these three objects, and nothing else.  You could therefore do much worse than just leave well enough alone and go with the SQL Server 2005 default index names.

Things get somewhat uglier, however, in the situation where multiple additional keys or indices of a given type associated with a given table.  For example, assume in addition to the above, you decide to add a unique index on Dog.lbl  — this index will end up being called IX_Dog1.  I’m not a big fan of the tacked-on number suffix to differentiate one object name from another.  It makes the name unique, of course, but does absolutely nothing to convey any sort of meaning as to what role the object plays.  As noted in previous posts, system documentation often doesn’t get written — much less read — so the more self-evident meaning you can pack into a succinct object name, the better.

Key/Index Base Names  Very similar to the approach taken with other SQL Server 2005 database objects, key/index object names are rooted in a simple, ultra-short base name; pkey and fkey for primary and foreign keys respectively, and idx for other indexes.  If the index is unique, the base name is uidx.  It’s highly unlikely you will use any of the base names by themselves, however — unless you have only one of each type of index for your entire database.  This is virtually never the case.  So, in keeping with the other object naming standards, one or more prefixes are added to distinguish one object from another.

Table Name Prefix  The first prefix for all key/index names is the table name with which the object is associated.  Continuing with the example above, the names will therefore be DogPkey, DogFkey and DogIdx and DogUidx.  You might think that the first letter shouldn’t be capitalized, but you’d be wrong.  The use of the capitalized first letter visually connotes the table name.  As usual camel case is used to distinguish the various components of the object name, and therefore pkey becomes Pkey when the prefix is added.

Additional Primary Key Prefixes  There really should be only one primary key, so there are no additional standards  primary keys.  In other words, if you find yourself wanting to name two indexes firstDogPkey and secondDogPkey, you should think long and hard as to whether you’re not trying to paper over some fundamental flaw in your database design.

Foreign Key Prefixes  Foreign keys define a relationship between two tables.  You have referred to one of them with the table name prefix described above.  Now, add the name of the table that is being referenced with the foreign key.  A foreign key to the Breed table will therefore be BreedDogFkey.

Index Prefixes  The column, or columns, that form the basis for the index should be used as prefixes for indexes.  nmDogUidx is a unique index on the Dog.nm column.  lblDogIdx is an index on Dog.lbl. 

Compound Index Prefixes  Let’s assume you have a unique index that ensures a dog’s name is unique within a given breed.  This will be enforced with an index that refers to the nm, and id_Breed columns in the table Dog.  The two  columns that make up the index should be prefixed to the object name, in the order the columns appear in the table.  Technically, this means the name of the index should be nmId_BreedDogUkey.  However, the id_ makes the object name much less readable, and doesn’t add a lot in terms of meaning, so it’s dropped.  Hence the ‘correct’ name for this index would be nmBreedDogUidx.

Multiple Foreign Keys to the Same Table   All is well except in the situation where you have two indexes defining foreign key relationships to the same table — and it does happen, from time-to-time.  For instance, let’s assume you have two columns in Dog called uid_Session_create and uid_Session_modify.  Both are foreign keys to the Session table.  In which case, you have to add yet another prefix to the index name; hence, createSessionFkey, modifySessionFkey.  Note that in this case, the prefix is not capitalized, this is because it descriptive in nature (attribute-ish, if you will) rather that identifiying another object.

That’s it — it always seems like it takes much longer to explain the standard than to apply it.  Like other standards described previously, once you use them for a while, they become second nature, and very easy to apply.  Thank you very much for reading and, by all means, let me know what you think.

The most revealing moment of Valley Boy, Tom Perkins’ recently published autobiography, comes on page 143 where the author describes a brief, informal conversation with Dave Packard.  In the conversation,  Packard rhetorically asks; "[H]ow did I ever let you get away from HP?"  Perkins identifies this as the single most significant compliment of his entire life.  So, even for those who achieve almost unimaginable material success, there is still a mysterious rosebud which is the essential key to happiness.  No matter where life takes us, perhaps the thing we will always seek the most is the approval of our parents.

This is fascinating, given that Mr. Perkins is the P in KPCB, the legendary Kleiner Perkins Caulfield and Byers that arguably invented Silicon Valley-style venture capital.  At the very least, they perfected it, and raised it to the pantheon of unadulterated, unapologetic, American-style free enterprise.  Perkins and KPCB hits have been spectacular to say the least — ever hear of a couple of little outfits called Amazon and Google? — but there have also been some fairly spectacular failures, as well.  Perkins is surprisingly candid talking about them.  Despite what anybody might say or think about Perkins, he is, at the very least, blessed with crystal clear self-perception.

What’s harder to know is whether any of Perkins’ accomplishments have provided any level of satisfaction for him.  Right up until the very last line of the main text, when he finishes describing the construction and launch of the magnificent Maltese Falcon, he hints that there are still more rivers to cross and dragons to slay.  There are also earlier signs of the same condition; he spends quite a few pages describing his passion for old, supercharged sports cars.  He then wraps the chapter up with how he sold them all for no better reason than it was the ‘peak of the market’.  There’s an inherent sadness in this state of affairs, where love is for sale and measured in dollars and cents.  Perkins is passionate, yet passionless.

Valley Boy describes some rollicking adventures, which makes it somewhat of a pulpy, page-turner at times.  His run-in with a bond trader that nearly lost Kleiner and Perkins’ entire founding stake, and his collision with a coke-fiend, former-friend CEO seem taken more from Perkins’ Sex and the Single Zillionaire than from real life.   They must be true, though, because it’s hard to imagine in a life so full of astounding, verifiably true stories, Perkins would resort to making anything up.  One wonders, though, why the tech-savvy author wouldn’t have taken the time to Google "natasha steinmetz celebrity wire" before quoting the entire interview in Chapter Ten.  The latter leaves the reader with the impression Perkins may have adopted the ‘memoire’ format pioneered by James Frey.

It’s possible for those who achieve great wealth to make the transition from insufferable upstart to establishment magnate, and somehow pick up a clear understanding of noblesse oblige along the way.  Bill Gates will undoubtedly be remembered for his founding role in Microsoft, but in very long term, he will likely be just as well known for his work at the Bill & Melinda Gates Foundation.  Perkins has undoubtedly done his fair-share of philanthropic work, and has given a substantial chunk of his fortune to this end.  He talks extensively about his hands-on work with the San Francisco ballet, for example — but his underlying motivation is less clear.  Being the ‘best damned philanthropist in history’ might just be it.  But, in the end, the good work still gets done — and that’s what it’s all about, right?  However, even in the altruistic sphere, Perkins must dominate and control the work in order to be effective.  Effective, yes, but less appealing than you might like.

You would think that Perkins, having achieved near mythological status in his own career, would be satisfied to be married to someone equally successful in their own, respective domain.  Yet, in his brief marriage to Danielle Steele,  Perkins is compelled to compete with her, which seems driven by near anti-social competitiveness rather than any desire to write a ’sex novel’ (as Perkins calls it).  Fair enough, but really, what is the point?  Perkins provides little if any insight in this regard, and yet it is likely this same flaw in his character that made him so successful in the first place.  This is what we really want to know about Perkins, and yet we are left to figure out the answer ourselves.

Structurally, the format of Valley Boy is jarring.  As Perkins himself readily admits in the preface, it’s really a series of anecdotes, seemingly sequenced in the order in which they came out of his head.  It’s quirky, or maybe just lazy.  I’m paraphrasing, but essentially he tells the reader that if they’re looking for logic in the way the book is structured, there isn’t any — rather, these are the stories that would come up in dinner conversation.  And mighty good stories, they are.  If you ever found yourself Mr. Perkins’ dinner guest, you’d be well advised to shut up and listen; you’ll be entertained, certainly, and you may just learn something along the way.

To say that Tom Perkins is complicated is as blindingly obvious as it is true.  The reader is left to figure out the puzzle though — the anecdotes that make up Valley Boy have to be pieced together in the readers mind to try and get an integrated picture of the author.  Like Picasso, some will see seminal modern art, and others will just see a bunch of ugly, squiggly lines.  It may be cliché, but its both, and neither, at the same time.

If you’re looking for a history lesson on Silicon Valley, two recently published books, Bill & Dave by Michael S. Malone and Andy Grove by Richard S. Tedlow are well-researched, well-written, fact-laden and thoroughly readable works.  However, if you’re just about to jump a flight to Palm Springs and need something to read by the pool, Valley Boy will be right up your alley.  The chapters are certainly short enough that you’ll get through at least one before dozing off under that beautiful Coachella Valley sun.

I have been using Motorola’s Moto Q on Telus for quite some time now — a few months at least — and I’m reasonably satisfied with it. It certainly meets my requirements taking into account relatively low voice-call volume, and the text/email interfaces are reasonably good.

However, there is one thing that it doesn’t do which seems like a really significant oversight — there is no way to modify an existing task! My work style is very list driven; it’s sad, I admit, that pretty much everything for me is a list of tasks. What’s true, of course, is tasks and priorities change all the time.  So if the only recourse is to delete the task, and then re-add it with the updated information, that seems like a lot of fuss to get the job done.

Of course, it’s entirely possible that a dud like me has simply missed the part of the manual that covered this. Or if I really am correct, and it really doesn’t do this, maybe there is some sort of work around or fix? In either case, if you’ve encountered this problem and solved it, by all means let me know.

Actually, come to think of it, there’s one other thing that really is abominable — ActiveSync.  But I’ll lament that some other time.

I spent the better part of half a day chasing this problem, so I figured I would make a brief post in the hope I can save another developer the frustration of chasing down a solution.

Problem

I was working with the Dataset Designer in Visual Studio 2005, and was about to make a very minor change to one of the DataTable objects.  After hitting F4, I was surprised, and a little dismayed, to find the property page blank.  I then discovered I couldn’t get properties for anything — not for a table, not for a column, nothing!  I first thought this was a result of a hand edit of the XSD (to reverse the sequence of two columns), and somehow, there was some corruption preventing Designer from reading to the XSD to get properties.  I then discovered the problem was more widespread than I first thought. For the life of me, I couldn’t get the properties for any object to show — even very simple, straightforward things, like buttons on a form.  I had visions of having to reinstall VS 2005 or some such butchery, but it turns out it was a simple and effective fix.

Solution

Some digging with Google yielded up the answer.  Briefly stated, it’s the devenv.exe utility, used with the /setup option, executed from the Visual Studio Command Prompt.  To access this,  click Start, then All Programs, then Microsoft Visual Studio 2005, then Visual Studio Tools, and finally click Visual Studio Command Prompt.  When the command prompt appears, type;

devenv /setup

It takes quite a few seconds to run…maybe as much as a minute.  Also, the utility runs without generating any sort of feedback.  When it completes, the command prompt simply re-appears.  But when Visual Studio 2005 fires up — voilà! — the property pages will have returned.  

Full credit where it is due; I found this answer on the ASP.Net forum, authored by Benson Yu.  As always, thank you very much for reading, and let me know what you think.