Let’s set the stage, PHP & MYSQL:
I have a table we’ll call Directions to hold each step for a given task. Each task has variable steps.
The only real essential fields for this question are (primary) step_id,**task_id**, step.
When the author updates their directions, they can update each step, add new ones, remove old ones.
I understand how to handle the updating / insertion / deleting logic structure
INSERT ... ON DUPLICATE KEY ... and so on.
My concern lies elsewhere. Say someone writes directions for task #1, five months later they update task #1 with a few new steps. In that time, there are 1000 new tasks.
Is it really an issue that the majority of steps for task #1 will be located in say… step_id 1-10, and that new step will be way down in 10001?
Since I run no specific computations on the steps, is this a situation where I’m better off storing each step as a serialized array in a single row?
I believe task_id is quite essential field for this question too. If it is indexed you won’t have any performance issues with selecting steps for a given task no matter how separated they are in your table.
With steps serialized you would have more issues as you would have to deserialize them for every update/delete, serialize again and then update the row, also you could run into problems with column size unless you limit number of steps for every task.