If I remember well some database theory, you are using a denormalized database: you have a field in the USER table which actually contains a list of user hobbies:

Anonymous Monk|89|1:2:3
[download]

From a database-design point of view I think you should have 3 tables:

USERS(USER_ID, NAME)
HOBBIES(HOBBY_ID, DESCRIPTION)
USER_HOBBIES(USER_ID, HOBBY_ID)
[download]

The table USER_HOBBIES describes the relationship between USERS and HOBBIES which is a many to many relationship.
If you had this db structure, and your current user is for example "Anonymous Monk", whose USER_ID is 89, you can retrieve his hobbies with a select performing a join:

SELECT HOBBIES.DESCRIPTION
FROM USER_HOBBIES, HOBBIES
WHERE USER_HOBBIES.USER_ID = 23
AND USER_HOBBIES.HOBBY_ID = HOBBIES.HOBBY_ID
[download]

With this approach you don't need the hobbies array, and you don't need to perform any split from your perl script: you move the logic into the db and let the db engine do the work.
You may want to evaluate which approach gives the best performance: the denormalized database with perl performing much work, or the db with one more table and the join query.
IMHO db engines perform these tasks very well, and AFAIK denormalization is mainly used when designing datawarehouses (which are not actually 'relational' databases)
I hope this may help
marcos