Further migrating to single table for large communities have thousand of users will be nightmare for people. I don't want people to get frustrated for new change. Many people running OSSN on shared hosting and you know these shared hosting works with database limitation they will likely to get timeout and everything will be messed. Not everyone will have knowledge to debug and find the upgrade issue.

I can't find no real-world example of that. Whenever using entity->add() , an accompanying entitymetadata record gets created automatically. So even if I'm not interested in the value, the record is there. And of course the same could be achieved much easier with an empty 'value' column in ossnentities than having an extra table with an empty row.

You both are right on each side. Actually the goal of OSSN is to make sure nothing breaks on future versions like it does in most of CMS. I have so many private non social network sites based on OSSN and If I move to single table It will break most of components and most of my sites. It will nightmare for me to migrate.

Actually you may not find the only entities table search in here on community but let me just share example i am using:

1. User signup using facebook
2. entities have signupusingfacebook key it can have any value lets say key=timestamp()
3. Now I only wanted to check if user registered using facebook I'll only query for this key in entity table I don't need its value (joins)

Other example

1. Account closed entity exists account_closed and value contain a very large text that user explains why he closed he may write 3-4 pages for the reason :) (just a example)
2. I am only interested in if(entity.subtype == 'account_closed' exists) not interested in value.

Yes there is other way to pass parameters in query you need for output. On other hand while debugging I don't need to look whole stuff in the table to find issue so I am only interested in toplevel stuff.

Performance can be improved by great margin if value column is moved to ossnentities itself.

There will be only few milliseconds performance improvement. I wouldn't agree to make it single table. Instead we can just use that time to improve existing things and add more features.

This topic relates more to https://github.com/opensource-socialnetwork/opensource-socialnetwork/issues/1864

I am not that database expert however feel free to :

Improve existing database (checking indexes , types .etc) like someone tried on #1864 github and let us know the results.

Well everything is possible single or double tables but its depends on the developer flavor. I just have problem above which I'll not vote to move to single table for 2-3 reasons above.

There is reason for the separate tables for the values sometimes we don't need those values but only interested in the entities.

I can't find no real-world example of that. Whenever using entity->add() , an accompanying entity_metadata record gets created automatically. So even if I'm not interested in the value, the record is there. And of course the same could be achieved much easier with an empty 'value' column in ossn_entities than having an extra table with an empty row.

Performance can be improved by great margin if value column is moved to ossnentities itself.

The question is: Would we really notice that performance improvement? I mean: You can read a lot about database optimization, but in the end you might often win just milliseconds. So the effort of all necessary code changes - not to talk about the danger of a database conversion may be in no reasonable relation to the benefit.

But I didn't want to sound demotivating. If you have fun to provide 2 showcases - with/without metadata, why not :)

HI @ArsalanShah
Thank you for your reply. I agree with @zetman
I checked the code and it always returns only one value from ossn_entities_metadata table for each ossn_entities entry using JOIN. That means only one ossn_entities_metadata per ossn_entities entry. That is equivalent to having value column within ossn_entities itself.

Infact all the methods in OssnEntities and OssnUser saves and returns only one value from ossnentities and ossnentitiesmetadata joining them. Performance can be improved by great margin if value column is moved to ossnentities itself.

Current table structure is only useful if multiple ossn_entities_metadata are allowed for a single ossn_entities
For example, saving alternate emails of a user. It will have 1 row in ossn_entities but can have multiple rows in ossn_entities_metadata for this entity.

Regards,

I can't find no example for a usage like that.
Having a look into my site: the number of ossn_entities_metadata is exactly the same as ossn_entities, although a lot of metadata records have no value.

There is reason for the separate tables for the values sometimes we don't need those values but only interested in the entities.

Strange, I see 1 reply on Discussion Topics page but no reply here.
Still confused about the table. Is it reserve for future use?
If not, I can contribute to this project on Github and move the values to ossn_entities table.