SQL different table or store as text in same table

Question

I have a dilemma that i can't seem to put to rest.

On a page i have a list of objects. Each of those objects is a slider - like aribnb - https://www.airbnb.com/s/London--United-Kingdom?source=ds

In my DB where i store information about that object (it has other info except the slides), i'm thinking, it would be easiest to store the URL for all the slides as a block of text.

URL       | other_field
-----------------------
url1,url2 | other stuff 

then handle it from there in either front end or backend by converting them into an array etc.

The second approach would be to create a separate table where i'd store each url and id of the object that url belongs to on a separate row

URL  | obj_ID
-------------
url1 | id1
url2 | id1
url3 | id2
.............

. I'd do a group_concat( distinct X) and it would return them to me as a block of text. I'd then do the same thing with splitting them up.

Long story short, do i store them as a field in the initial table or in a separate table, each being it's own row. What would be the advantages and disadvantages to either approach? To me it seems easier to have them as text in the same table, but i'm inexperienced in this, so i need some advice.

EDIT: The final usable format will be a JSON with the slides being either an array, or a text to be split into an array at the appropriate time.

Answer 1

The answer is... it depends. If you think of your URLS as simply notes in a block of text, then maybe it makes sense to just store them in one field. Make sure that you set the field length large enough.

However, if you think you ever might need to treat a URL as a relational entity... then you need to go the second route. What do I mean by that? Well, what if in the future you need to add a requirement to store not only the URL but a short description of it? Maybe you need to add an active date to tell when the last time that URL was checked to be valid. Maybe you would like to be able to find objects that share a common URL. I'm not saying that these should be your requirements; I'm saying that you don't know what future requirements will be. If you're very certain that this is just a block of text and it will always be just a block of text, then sure... put it in a VARCHAR(MAX) field. Down the road though as requirements are built on, you'll be tempted to try to hack more stuff into that blob of text, which will make things more difficult going forward.

Sometimes it's appropriate to break normal form for speed or simplicity, but you want to do it sparingly and with as much forethought into the future as possible.