There is an art and a science to database design. The science is normalisation. If you're intent on learning about databases you will need a solid understanding of it.
The art is in deciding just what exactly the "things" are that are going into your database. Defining them in a why that is comprehensive and precise is a skill to learn.
In your particular case, storing multiple card ids in a single column prima face breaks first normal form. This is where the "art" bit comes in. If you only ever consider these cards all together - say, as a "hand" or a "pack" - and never as individual items then it would be legitimate to model them as a single column. If you ever want to consider each card individually ("How many times has the Queen of hearts been delt?") then you would be better of modelling a seperate table with one row per card.
A second consideration is performance. It will always be faster to insert or delete one row than 52. It will almost always be slower to pull a substring out of a long varchar than to pick a single row from a large, well-indexed table. These considerations conflict. On balance, I would always recommend the one-row-per-card approach until it was proven otherwise.
You are best placed to judge the usage and volumes of your application and, hence, resolve the conflicts.