问题
I am trying to store "dynamic" properties about objects in SQL. As an example, let's say I have a table called objs that has two columns (id, name). Now some users may want to store a property called hocus while others may want to store a property called pocus (or even banana). Anything really.
My thought is to create two tables, props and obj_props. props would have two columns (id and prop_name), and obj_props would have (obj_id, prop_id, and value).
My only concern is this seems like a lot of overhead if there are millions of objects, each with 20-30 properties. I know I could create an index in obj_props on obj_id and prop_id but will this still be able to perform well? Is there a better solution for something like this? I'm looking into MongoDB but the lack of joins is frustrating.
回答1:
This has been discussed repeatedly before:
- This DBA.stackexchange.com post
- Dynamic table columns based on user preferences
- Should I place EAV values in a datatype table?
- How to represent many similar attributes of an entity in a database?
- Database design - should I use 30 columns or 1 column with all data in form of JSON/XML?
- What is the maximum number of columns in a PostgreSQL select query
The short version: EAV has its place, but it's often better to use json, XML, or hstore. PostgreSQL 9.4's enhanced json will probably become the most attractive choice, as it combines the advantages of json and hstore.
回答2:
First, you should start with a proper database schema (using standard data model patterns) so you can avoid this as much as possible.
Martin Fowler recommends using either a serialized LOB (such as JSON or XML), or allowing the user to edit their own database schema (which is my preferred method):
http://martinfowler.com/bliki/UserDefinedField.html
Bill Karwin has a post somewhere on creating a second table to index values in the blob field, but I can't find it right now. Will post when I do.
来源：https://stackoverflow.com/questions/21414092/storing-dynamic-properties-of-objects-in-sql