Hello,
I would like to propose a new feature request to have an option for Zammad administrators to choose where and how to store object data (for example ticket objects).
I will try to explain on my experience with Zammad (Ticket object Tree Select hangs zammad 5 and page become not responsive - #12 by ali), but I think it will improve performance for other users of Zammad.
I have a TreeSelect ticket object which consist of about 5000 items (because of its syntax, it takes more about 20k rows in one object. We need it to store them in TreeSelect to structure data by regions, product type, and item itself, where the Customer have a problem, so that we can provide Customer to choose exact problematic product and in the future provide a report about it, problem frequency, etc.). To store it Zammad (on postgres) uses one cell of column data_option in table object_manager_attributes. When data is retrieved from database, Zammad needs to process all of this data for every ticket, so that if we have about 1000 ticket, then it will process 5000 items 1000 times. But if this data will load only once at user login, then it could greatly improve performance of the Zammad, Customers, who has such big objects will be happy 
.
I tried to store them in separate objects, somehow optimize data, but finally I saw that the problem still remain, and this is mostly because the way how data objects are stored.
For now, I use workaround like this: I saved my ticket object to list of Tags, and disabled the TreeSelect ticket object on Zammad. And Zammad started to work very fast. So as I think, the difference is that, Tags are stored on a separate table and access for this data is fast, and show only limited of number of items (depends on user input). And also one remarkable thing is that Tags are Searchable like TreeSelect. But in my case I can’t provide Customer option to choose an item from this list, because it is hidden for Customers by default in Zammad (Tags visible for customer).
If Zammad could provide users to choose where and how to store data, like separate table in DB or store it as an object in one cell (data_option), this will improve its flexibility and performance for users with many data.
I also understand, you have done great job, making storing data the same for many different objects, but data growth and storing large objects and processing them every time for every object, I think, it is not good idea for future.
As Data is growing everyday, so working with large objects may become more popular in the future. And I hope this feature request can solve this problem before it appear.
In case of TreeSelect, database table could use column like ParentItemId or ChildItemId, so it will be easier to build a tree.
I will be glad to hear any ideas about it or answer a questions if you have any
Best Regards.
Ali