Job Pay Strategy - database and class design

I have an application where a Job can have one pay strategy - per mile, per hour, salary, or allowing for any additional strategy in the future.

In the database I have a Jobs table, of course. I would anticipate I need a lookup table for the strategies.

However, when it comes to the objects/classes and the data that gets stored as part of a strategy, i am unsure how to proceed.

Theoretically I should have IPayStrategy, and a concrete class for each strategy.

But when it comes time to present a data entry form and a pay strategy is chosen, the next part needs to ask for values related to that strategy.

Each class could have a viewlet that would define how to present the data input fields, and that's fine with me (unless y'all have another way of thinking about it...), but when it comes to actually STORING that data, does this design then limit me to creating a brand new database table for each pay strategy that comes up now or in the future? As in, each of the pay strategies i've mentioned only requires a single value, but it's possible that another pay strategy could come along in the future that requires more complex data entry of some kind... so how do you tie a pay strategy to a job, and store the data?

In short, how does data storage work with the Strategy design pattern?

I have a feeling my disconnect here might be related to the Strategy pattern being for behavior alone(?), but this behavior necessarily has data tied to it...

I welcome your input!