I personally would not want to set up a database in the latter format, as it introduces a good deal of formatting issues whenever you want to pull data from that.
Normally, what I would do, is split the data into either two or three tables, depending on whether didn't usernames can be associated with the same URL or not. If they can't (one to many relationship)
I would build two tables:
USERS
USERID USERNAME
0 jake
1 po
URLS
URLID USERID URL
0 0 abc.com
1 0 123.com
2 1 google.com
3 1 googl3.com
4 1 ranoutoffakeurlslol.com
Or, if urls can have different users (many to many), USERS would be the same, but URLS would be:
URLS
URLID URL
0 abc.com
1 123.com
2 google.com
3 googl3.com
4 ranoutoffakeurlslol.com
and there would be a third table to join them
USERURLS
USERID URLID
0 0
0 1
1 2
1 3
1 4
This way looks a bit complicated, but repeats less data (only ints instead of strings), and is much easier to expand later on, say if you wanted to add address, phone number, password to the usernames, or anything else. I would look into the Normal Forms (NF) of relational databases, if you aren't familiar with them. (wikipedia article)