Critique my MySQL Database Design for Unlimited DYNAMIC Fields

Question

Looking for a scalable, flexible and fast database design for \'Build your own form\' style website - e.g Wufoo.

Rules:

1. User has only 1 Form they can build

Answer 1

You should really look into schema-free dbs like CouchDB, problems like this are exactly those these types of DBs want to solve.

Answer 2

At OSCON yesterday, Josh Berkus gave a good tutorial on DB design, and he spent a good fraction of it mercilessly tearing into such "EAV"il tables; you should be able to find his slides on the OSCON site soon, and eventually the audio recording of his whole tutorial online (the latter will probably take a while).

You'll need a join per attribute (multiple instances of the values table, one per attribute you're fetching or updating) so I don't know what you mean by "less join tables". Joining many instances of the same table isn't a particularly fast operation, and your design makes indices nearly unfeasible and unusable.

At least as a minor improvement use per-type separate tables for your attributes' values (maybe some indexing might be applicable in that case, though with MySQL's limitation to one index per query per table even that's somewhat dubious).

Answer 3

y'know, create table, alter, add a column, etc are operations you can do at run time in many modern rdbms implementations. Why be EAVil? Especially if you are using dynamic sql.

It's not for the fainthearted. I recall an implementation at Boeing which resulted in 70,000 tables in a database.

Obviously there are pitfalls in dynamic table creation, but they also exist for EAV tables. Things like two attributes for the same key expressing the same fact. Or transitive dependencies and other normalization gotchas. So why not at least leverage the power of the RDBMS on your behalf?

Answer 4

I agree with john owen.

dynamically creating a query from the schema is a small price to pay compared to querying EVA tables. Especially if the tables are large.

Usually table columns are considered an "interface". A design that relies on a dynamically changing interface is usually bad, but EAV data is a special case where you don't have many options. You have to choose between slow unintuitive queries or dynamic schema.