Are lots of columns or joins better in Django I am writing a simple Django app that stores and displays user objects with lots of attributes.

The user may have up to three hundred attributes.

These attributes however, can be grouped off. 

For example, we can have one group for "Favourite Dish" and the attributes under that are cost, flavour, cuisine etc. and another group for "Favourite Dog" and under that are cost, flavour, breed etc.

I know that in normal circumstances, you would compartmentalise the data and store each group of attributes in its own table, however this app will display and query all of the data, most of the time. 

For example: the main page of this app will have a search box and users should be able to search any of the attributes in the entire model. This would involve a lot of joins if done the "usual" way, but would involve less joins if I just had a table of three hundred columns.

I have considered using NoSQL but there is other data that fits a relational schema much better.

What is the best practice for this?

Thanks :)
I'm not sure how to phrase this, but this type of application isn't what Django is made for.

Django is made for simple CRUD based websites, with an admin interface that comes for free, but I don't think trying to shoehorn a search engine in an MVC framework is going to work very well. (however there may be extensions by now, my Django experience is old and rusty)

Creating 300 columns, resulting in 300 ORs is impossible to index for, and neither is 30 tables with 10 columns each joined together, if all columns have to be search-able.

The only reasonable approach I can think of is going for an EAV pattern (for which there is an extension: django-eav), but that is going to create other issues in my opinion.

I also believe you are misunderstanding how Django is supposed to work, but you are supposed to define your data model in your model files and be able to sync it to any db. Since you are asking about a NoSQL database I suspect you are going to have to write custom code anyway. 

Depending on how much code you would have to write to shoe-horn your requirements in a framework that was never intended to do this, you might as well just write a custom application.

I think, depending on your requirements (which aren't necessarily all that clear) you should go for a full text index search or any indexing solution since searching 300 columns, or EAV values, whatever you pick as a solution to match your chosen framework, is still going to be a pain.

For an obviously data driven requirement the data should dictate the platform, not the other way around.

You are trying to desperately make a framework do something it wasn't designed for.