Why is the usage of string keys generally considered to be a bad idea?

This has been bugging me for a while. Most of the time, when it comes to storing data in structures such as hashtables, programmers, books and articles insist that indexing elements in said structures by String values is considered to be bad practice.
Yet, so far, I have not found a single such source to also explain WHY it is considered to be bad practice.
Does it depend on the programming language? On the underlying framework? On the implementation?

Take two simple examples, if it helps:

An SQL-like table where rows are indexed by a String primary key.

A .NET Dictionary where the keys are Strings.

It all has to do with the two things basically:

1) The speed of lookup (where integers for instance fare much better)

2) The size of indexes (where string indexes would explode)

Now it all depends on your needs and the size of the dataset. If a table or a collection has like 10-20 elements in it, the type of the key is irrelevant. It will be very fast even with a string key.

P.S. May not be related to your question, but Guids are considered bad for database keys too (16 byte Guid vs. 4 byte integer). On large data volumes Guids do slow down lookup.

There is one more issue with using strings as keys, or more accurately, using string literals as keys, setting aside pure performance/efficiency reasons. Typos. If you use string literals as keys in a dictionary, you’re setting yourself up for a nasty surprise when one "ReceiverId" becomes a "RecieverId". Set up constants to store the key values and reuse them whenever you access the dictionary.

Trivial and obvious, you can say, yet a stunning number of .NET code examples around the web uses string literals, propagating this dubious practice. ASP.NET with all the Sessions, ViewStates and QueryParams strewn across the codebase is particularly guilty here.

There are many tradeoffs here. Actually I use string keys frequently, but often I include surrogate secondary keys for joins (obviously it would be the other way around if I was using MySQL). There are cases where I don’t however.

First I am a fan of declaring natural keys as the primary key where the db can handle this well (PostgreSQL for example). This helps with normalization and makes for clearer database design. Surrogate keys make joining easier.

There are two reasons I usually add surrogate keys:

It isn’t always clear what a natural key is. Sometimes these have to be changed. Changing a natural, composite key when it is used for joins and referential integrity is complicated and error prone.
Join performance on composite keys is problematic and once you go down the natural key route, you get stuck there.

In cases where a natural key is definitional, single column, and text, however, I usually join on the string key. My reason for doing so is that this often avoids joins on lookup. The most common use is providing proper db design around the use case of enum types. In most cases, these do not require the extra join for routine queries. So where this is the case, string keys as join keys makes perfect sense.

For example in LedgerSMB, we store account categorizations. These are identifed by string reference.and some other data is stored with the string reference which is used to enforce rules regarding the combinations of categorizations that can affect an account. The only time that logic is needed is when saving a set of categorizations, so we join on the string key.

As to why the default would be integer keys, I don’t think it’s just a question of index size. A big issue is management of keys. Since the key is arbitrary and you may be dealing with millions of records, you have to have a way of generating unique strings. There are cases where people use UUIDs for this, but there is a non-zero chance of UUID collision, and where billions of records are stored, this chance becomes high enough one might actually see while the chance of collision with incremented integer types is zero by definition.

There are a number of potential issues with using strings as keys, especially when it comes to sql-like tables. As mentioned by @bunny, the indexes for your tables are going to be bigger, but I think more significantly, any foreign key relationships to the table will involve BOTH tables to have contain the string as opposed to a lighter-weight (integer) identifier. If you find that there are even more tables with references to the first, the string keys will be proliferated throughout your database.

It’ not a bad idea in and of itself, it’s usually with 20/20 hindsight a poor design compromise.
The flexibility and range of string versus the additional cost and complexity.

If integer does the job range wise and the bulk of the expensive processing doesn’t need to know what the integer represents, use one.

You somehow retrieved the wrong data from a Hashtable.

Did you mean “DaytimeTelephone” or “EveningTelephone”?

Did you mean 1234567 or 1234576?

Whilst numbers are arguably more efficient for the machine, whenever things go awry (and they do), it falls to the likes of you and I to make sense of what’s happened and, at that point, that saving of a few bytes of storage and a few micro (nano?)-seconds of processing loses out to clarity every single time.

Lots of trade offs and no one right answer. Many programmers would never consider using string keys in the database because they aren’t aware of hashing and how a database works. String keys as long as they are either extremely stable, or meaningless (surrogates), are a good design choice in many circumstances.

string key will make sense, when it comes to lookup table with about 10-100 short string records; related data is more readable + e.g. change tracking (numeric/guid id vs. string e.g “Administrator”); btw, ASP.NET Membership database uses string keys for AspNetRoles.

Filed under: softwareengineering - @ 17:47

Thẻ: data-structures, database-design, programming-practices

Thiết kế website giá rẻ

Danh mục

Why is the usage of string keys generally considered to be a bad idea?