i have been doing a little brain-storming and would like to get some enter from you guys. a consumer asked if it is viable to apply a unmarried cakephp installation (likely v3, perhaps v4) for all his clients to apply at the same time as also supplying purchaser-precise records and useful necessities through a plugin gadget.
for example, shall we embrace all of the clients need to create an article. at the maximum simple shape, all customer could be able to keep a title (article.identify) and frame (article.frame). a few customers can also need to save a precis (article.precis). different clients may also want to shop a list of members to the object (a has-and-belongs-to-many association with the users desk, for example).
the idea is that the base device could meet 70%-80% of his purchaser’s desires, some thing very unique could be furnished through a plugin and loaded simplest for those customers. keep in mind this is all on a single cakephp installation.
at first i notion it might be feasible but after some wondering and experimenting i am no longer so sure. i am getting stumped on where the custom information need to be stored and the way it’d have an effect on the database table, the table magnificence, entity magnificence and validation regulations. as an instance, if only some clients desired to have an article precis, need to it be saved inside the articles desk or a totally new desk? if we use the articles table, we’d need to have exclusive table instructions for exclusive customers so we’d need a way to dynamically load the appropriate table elegance (and entity magnificence. is that this even feasible?) if we use a new table to save custom facts, i believe it’d get very puzzling due to the fact the table could need to take delivery of all varieties of facts (with different validation regulations) from all of the fashions inside the machine.
and that’s simply facts. i have never even all started to think about how to take care of custom institutions or custom capability (e.g. a few clients may need to organization their articles into classes etc…)
any thoughts could be preferred specifically from the ones who’ve tackled some thing comparable.
I think I understand what you mean. This sounds like the kind of idea that I frequently pursue, clever but impractical.
But probably not impossible.
I can think of two ways to approach the problem of custom information storage.
Version One
Once you’ve created your basic record that will satisfy most cases, you can later add a linked record that satisfies your special case and contain it in your queries.
The old uses of the article entity will ignore the newly present, and empty property. Your new features can check the property and act if it is present.
Or you can, in certain cases wrap the Article Entity in a new class (or use a new class in its place).
Version Two
Another way is to always have a json type field in your table or in a linked record. This discusses json fields but they are now built in, not special types.
You can use a Modeless Form to define what the json schema is and different client needs can use different Form Classes to operate with different schemas. But your table schema remains the same.
This is how I implement user preference systems. I never know ahead of time what values I might want want to track. A json field lets the system evolve without the need to change the database.
In Conclusion
But you’re always going to be fighting against creeping complexity.
