Best practice design route for an estimates table

Question

I need to allow users to store monthly estimates so that they can be later retrieved in our management information system.

It would look something like this but with the next 12 months. The first data row would hold the current month.

Month	Estimate	Programme	activity	comment
July 2024	10	prog1	act1	initial guess
Aug 2024	15	prog1	act1	more demand
...	...	...	...	...
June 2025	3	prog1	act1	Initial guess

The programme and activity columns are already Taxonomy items within the CMS.

We are now on Drupal 10. From what I can see (and as usual in Drupal!) there are a few approaches I could take - just a custom table and form, a custom entity, a content type and fields or even a plain MySQL table. Ideally when the user loaded the page, they would see the existing entries. So I am thinking of a view with a custom bulk operation on each entry. I am assuming I would reuse the Taxonomy items rather than create another table to store these items in.

We generally use the Webform module for forms. Talking with colleagues, we would always use the latest estimate supplied, so from a data retrieval point of view, a table that just timestamps every update would be fine and we could see a history of changes like that.

Is there a best practice way of approaching this in Drupal 10?

Answer 1

a custom table and form, a custom entity, a content type and fields or even a plain MySQL table

Speaking very generally, I would first try to use a content type and fields, since custom content types can be built and customized entirely via the UI and give you all the nice extras provided by nodes, plus lots of additional options in contrib. It's also extremely easy to reuse the taxonomy terms and VBO with this approach.

You could also use Webform for this; I don't know which would be more work to configure, webform or a custom content type.

If I wanted to avoid the overhead of nodes, I would use a custom entity, but then you need to add Views support.

I would avoid using a custom table + form or plain MySQL table. If needs change and you need to rework the feature, it's much easier to have your data in Drupal stored as entities.