mknooihuisen's avatar

Best practices when dealing with Helper DB tables

I've occasionally found situations in which I've needed a sort of helper table with the sole purpose of controlling interactions with the data in another table. A quick example:

I have a Tasks Eloquent model which is displayed to my users as the standard unordered list, but with drag and drop functionality. I want my users to be able to reorder the tasks by priority and save the result, so I created a second (helper) table to store the ordered Task IDs. Note that this is not a voting system, each person's priority list is saved as its own entry in the helper table, just because.

In this system and others like it, the helper table has no functionality, I only need to read it to determine how to display my Task objects. Is it best practice to create an empty Eloquent Model class for this, or to use the Query Builder? Or is there a third option I may not know about?

Thanks in advance, Mike

0 likes
2 replies
Cronix's avatar

I'm doing the same kind of thing, but I store the order within the task table so don't need an intermediary table. Each task has 1 order so why does it need an additional table? Am I missing something? Or is there only 1 set of hardcoded tasks and all users have the same tasks so you need to store the order separately for each user?

My table structure basically looks like

tasks
-id
-user_id
-task_order
-name
-description
-due_date
-completed
mknooihuisen's avatar

The latter. One set of tasks, multiple users, with the idea in this example being to be able to store and show each user's preferred order for the tasks. I wouldn't want to hardcode the tasks either though.

Please or to participate in this conversation.