Violating 1st normal form, is it okay for my purpose?

So I'm making a running log, and I have the workouts stored as entries in a table. For each workout, the user can add intervals (which consist of a time and a distance), so I have an array like this:

[workout] =>
    [description] =>
    [comments] =>
    ...
    [intervals] =>
        [0] =>
            [distance] => 200m
            [time] => 32
        [1] =>
            [distance] => 400m
            [time] => 65
        ...

I'm really tempted to throw the "intervals" array into serialize() or json_encode() and put it in an "intervals" field in my table, however this violates the principles of good database design (which, incidentally, I know hardly anything about).

Is there any disadvantage to doing this? I never plan on querying my table based on the contents of "intervals". Creating a separate table just for interva开发者_如何学Pythonls seems like a lot of unnecessary complexity, so if anyone with more experience has had a situation like this, what route did you take and how did it work out?

I think this is a bad idea. For example, how large should the intervals field be? If you break this into two tables, since it looks like a one-to-many relationship, you will not need to consider an artifical size constraint on the number of intervals.

Also, although you are saying you will never need to query based on the intervals, you may later change your mind and find cases where you actually do want to do that. Why limit your abilities and artificially denormalize this particular case. The creation of two tables is not all that complex. Also, you can always join them in a view to treat them as a single logical data set for queries and have the best of both worlds.

If you never plan on having to decompose the data you are storing to search against it or to read/update/delete/insert individual values I would just chuck it in and treat it as a single atomic entity for your purposes.

Strings can be decomposed into individual characters but no one claims they violate 1NF AFAIK.

That the values are numeric suggests to me that you'll eventually find a need to perform some sort of mathematical function against them such as an average or standard deviation. As such you'd be better off storing them in such a way that you can use SQL to manipulate them as opposed to pulling it back into a programming language.

Now, that doesn't necessarily mean you have to use another table. But it's certainly the easiest, standardized way of doing so. But if you really want to store it away with your other data in one table (i.e. the workout table), use XML.

I say XML because most database engines offer non standard SQL for querying those values out. SQL Server, Oracle and MySQL all have ways of doing so. Serialization binds you to whatever programming language you're working with (e.g. Java). JSON doesn't have SQL support AFAIK so you still need to pull it back into a programming language to manipulate in a meaningful fashion.