Having data in the structure "1,4,5,6,14,51,..." as one data value is a denormalized value.
Lets say you've got something that looks like:
Person2's friends are: 1, 4, 5, 7, 14, 51
Person3's friends are: 1, 5, 7, 15, 50
And so on. Now, lets ask the question "How many people consider person 5 to be their friend?" Well, in a denormalized structure, you're going to fetch every person's friends and then break it apart on the delimiter, and then see if 5 is in that list, increment the count and move on.
With a relational database, you've got a structure that looks like:
| user | | friends |
| id (pk)|<-+--| from (fk)|
| name | +--| to (fk)|
| ... | +----------+
And your query to answer this question is:
select count(1) from friends where to = 5 And, well... you're done. You've looked over one small table that can be queried very quickly.
You've also got things if you want to cascade a delete to properly clean up the references in other tables (you've deleted user 5, make sure 5 is deleted from all the users). There's things like consistency, isolation and durability (part of ACID) that help ensure that your data maintains the proper structure.
NoSQL has its place. But its not a relational database and doesn't pretend to be. It also throws away the guarantees of ACID as a trade off for speed and ease of clustering (part of speed). There are times you don't care about ACID and instead want the API that is provided by a nosql database (i.e. you are creating an offline instance of an application and cache all web requests - your couchdb, being accessed as a web request means that the off line one doesn't need another database).
I would suggest reading the nosql tag on Martin Fowler's bliki (blog + wiki).
There are solutions where nosql fits quite well. LDAP is an ancient protocol that could be thought of as one of the earliest nosql databases that exists today. You don't access it via sql, but you do for storing data... hierarchal data. It really works well for such data, and very fast. Its got clustering and eventual consistency and all the things you think of when you hear about of nosql.
I wouldn't want to implement a chat system in ldap - its not the right structure. Trying to make relational databases do what ldap does is also not a fun process.
If you are thinking of doing this as a learning experience. Something to understand how nosql works, yea... go ahead. Try implementing a chat system in mongo or couch. Many people have. I wouldn't be surprised if SE's chat isn't backed by such a data store... though I'm not sure if its couch, or mongo... the domain of noSQL is quite large in that two nosql databases may share more in common with mySQL than with each other in design. Do chose a key-value database? or a column oriented one? or a documented oriented one? or a graph database? or... Wikipedia lists 10 different flavors of NoSQL with 5 different sub flavors of the key-value store.
I would suggest reading from SO SQL (MySQL) vs NoSQL (CouchDB) and chase the links and related links on that page.
If the data is relational... well, its likely a relational database that you are looking for (and you should make sure you learn about database normalization).