If one stores an object's attributes as rows in a table with two columns (name, value) it makes for an incredibly flexible object/relational mapping implementation where the database can support all kinds of future objects without modification. The basic idea (very simplified) would then be to have 2 tables: one OBJ table to store object handles and types and one ATTR table to store the objects' attributes and values. Each ATTR row would of course point to a single object handle in the OBJ table.
But, of course there are trade offs associated with this flexibility. One is performance, which is not a major issue in my case. E.g., I realise that no matter which object i access different threads have to work with the same tables.
But the problem I haven't found a good solution to is sorting: how would I sort all user objects in the OBJ table according to their corresponding NAME value in the ATTR table. I would like to do this sort in the DBMS, not in application memory.
Any ideas as to how this kind of SELECT would look?
When performance is not an issue I find this simple design to be most interesting to speed development...
Best regards,
Marcus
But, of course there are trade offs associated with this flexibility. One is performance, which is not a major issue in my case. E.g., I realise that no matter which object i access different threads have to work with the same tables.
But the problem I haven't found a good solution to is sorting: how would I sort all user objects in the OBJ table according to their corresponding NAME value in the ATTR table. I would like to do this sort in the DBMS, not in application memory.
Any ideas as to how this kind of SELECT would look?
When performance is not an issue I find this simple design to be most interesting to speed development...
Best regards,
Marcus