Dear Thorsten Rinne
There are many methods/strategies to uniquely identify an item in the world - being it a book, a grocery product, a software component, and so on.
One method wildly used in computing areas is the UUID (Universally Unique Identifier) - and the GUID, Globally Unique IDentifier.
phpMyFAQ uses an auto-incremented sequential number to identify records - FAQ articles, categories, etc -, that is, IDs. The increment value is user-definable.
While this approach is simple and fast, it may cause some problems (as some users have reported).
- If the increment value is changed, there is the possibility of generating an already existing ID.
- If someone wants to merge two or more (FAQ) databases, the resulting DB may contain duplicated record IDs (the administrator must be aware of this possibility, but errors occur …)
On the other hand, when using rewrite statements on a web server, changing a FAQ’s question text breaks bookmarks and links on external sites (search engines pages, etc).
This situation may also occur after changing a FAQ’s category.
So, using UUIDs “v.4”  or “v.5”  to identify records (and other elements) is an option in order to minimize this kind of situation (it is possible to generate duplicated UUIDs but the probability is very low).
Generating a new UUID ID is slower than generating a new numeric ID - but it happens only once per record/entry.
A UUID “v.4”/”v.5” value can’t be used to sort records by their creation  sequence - and comparing strings is slower than comparing numbers -, so for this purpose it is possible to use an extra numeric field (similar to the current record ID) or just the numeric value of the creation date field.
Returning to the rewrite operation.
Using UUIDs, the administrator has two rewrite options:
- the current approach (with the question’s text – prone to changes and possibly long);
- the record UUID (“permanent”).
The UUID has also the advantage of being shorter (but not as user friendly as the first option), and may obfuscate the internal query/DB implementation to the external user.
URLs with “v.4” UUIDs don’t need to be URL-encoded (percent-encoding).
Another advantage: the record's UUID value may be used in the RSS <guid> optional element (this avoids feed validators complaints).
- Without rewrite statements
- With the current rewrite method
- Using UUIDs on the rewrite
 RFC 4122. More recent documentation about this subject is available.
 A UUID “v.1” contains the creation date/time but has security problems – it includes the host MAC address.