Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

ohffs's avatar
Level 50

Single complex model or several similar simple models

Hi all,

This is a fairly general question about design I guess. I have an app where people can book equipment. There is often some commonality between the bookings (such as 'Notes' about the booking), some need start & end times, some don't, some need a file uploaded with the booking, some don't etc.

At the moment I have a single Equipment model and just quite a few nullable() columns, and also for some of the more complex equipment there are extra related models that I check for in a kind of $equipment->specialBooking way and show/hide fields as appropriate.

This is making some of the code very straightforward as I can operate on the single Equipment model and share a lot of code - but other code is getting a bit spidery where there are a lot of if/else type stuff in the code & views.

So I was wondering if anyone else here has had to work with this kind of pattern and what they did? I'm tempted to separate the different major types of Equipment into their own models/controllers (maybe with common code in a helper/repo) and just deal with the complications that itself brings?

0 likes
7 replies
ohffs's avatar
Level 50

I'll do a quick reply to this myself as the original post seems to be trapped in the "doesn't appear until a reply" that some others have seen.

Just to expand a little on what I mean with the complications that would come with having separate models, I would (I think!) end up with separate matching Booking models for each type of kit, there are also fault reports, service reports, cost reports etc that are all relatively easy to do with a single Equipment model, but would get a bit messy having different models for types.

pmall's avatar

A model per table (even if they contain almost all the same colums) then use traits to share a particular functionality.

ohffs's avatar
Level 50

@pmall that's what I've been edging towards, but I can see it adding complications itself. For instance just showing a list of all equipment or recent bookings becomes a bit fiddly as I need to merge multiple models into the view and provide links back to the right model view/edit etc. Where-as with a single (albeit complex) model that's all fairly straightforward.

pmall's avatar

I dont understand. If you have a model per entity why would you merge it with another model to display it ?

ohffs's avatar
Level 50

Because the users of the system will want to see pages like 'my recent bookings' or 'available equipment' and expect them just to be ordered by date or name irrespective of the 'type'. So say you clicked the date on a booking to see the details I would need to make sure the link was to something like /equipment/{type}/booking/{id} whereas with a single equipment model that's more straightforward. But I guess it's just moving the complexity from one place to another in the code.

Also, where-ever there is code that needs to do anything like that (say reports on booking charges, or recent faults) I would need to loop over each model type - and remember to keep all the code updated or have some kind of lookup table of types -> ModelName. And adding new types of equipment means duplicating all of that code again (or indeed removing a type). With a single (complex) model users can actually add and remove types by themselves (unless it's something totally different that needs radically different forms at least).

I'm possibly seeing problems with both ways of doing it - but I wanted to see if I could get any feelers from people before I commit to one path or the other.

ohffs's avatar
Level 50

@pmall ahhhh! that's interesting! I'd only skipped over that section a year or so ago and not really seen a use for it at the time. It sounds like it could really help me here. Thanks for the pointer!

Please or to participate in this conversation.