Let’s take for example a dating site with 100.000 users. Each users has about 30 attributes like hair color, smoking, age, city, gender, …Some attributes are bool, some int and some var or text.
About 20 of those attributes are searchable and half of users don’t fill data. All values are displayed on user profile page.
I was thinking about the following options:
- Split data into 4 tables. Table 1 is used for data that is searched mostly, table 2 for attributes that are mostly unfilled, table 3 for large data like about me, and for rest of table 4.
- Separate table for most attributes, so each attribute have own table.
- Using EAV model.
I think that the first option would be the best. Or is there any other better way?
Assuming you won’t have much need for adding new attributes, you’re probably best-off just placing everything in one big table. DBMSes are typically fairly efficient in storing NULLs. Indexing NULLs should also be reasonable, some DBMSes don’t even include NULLs in indexes (Oracle).
Don’t be afraid of BLOBs either – they will tend to “stretch” the rows (if portion of BLOB is placed in-line in the row, which can typically be controlled in DBMS-specific ways), lowering your “data clustering”, but this should not be too important for your purposes.
In any case, measure on representative amounts of data before deciding that the most natural solution is not performant enough.