I am looking for a little advice on database design.
I am constructing a slideshow applicatino on the symfony2 platform, and I have four different types of slideshow containers (company, geo-area, property and individual monitors). This is for the purpose of organizing content and inheriting content down the line (a monitor sits in a property, a property is part of a geoarea etc.).
Now, on flat PHP I would have used only two tables, “containers” and “contents”, and put a type field in the containers table defining whether the container in question is a geo-area, property etc. and just linking each content piece (i.e. slide) with a FK to the appropriate container.
Now, learning about symfony2’s entity system, it seems that I could gain a lot inheritance-wise by instead defining the different container types as separate entities, thus being able to fetch for instance the geo-area, and automatically get returned all of its child objects (all properties, and in turn all monitors belonging to that property) on the fly. I do however want to be able to switch the “belonging” of a content piece between different containers, and different container types. I sense this will be somewhat hairy with the described approach, seeing there will most likely be a problem with the relation (FK) of the content piece if it must have the capability of “belonging to” any of four different entiy types?
Someone seasoned in the symfony2 world could perhaps enlighten me as to the wisest path to proceed here?
In our project we use Propel 1.6 and PropelBundle
Its syntax is quite developer-friendly.
One great advantage of
Propelis “fake” relations between tables. In your schema by just definingskipSql = trueflag you omit the generation of FK, but one object can be fetched with another just by defined fake relation.In your case it will end up with something like below:
During population of objects with related ones – you achieve great opportunity to use reverse relations:
Just ask in comments, and I’ll extend my answer with whatever you need 😉