sql - Alternatives to the EAV model vs Hybrid Strategy vs simplifying and improving builds -

i've been doing ton of research on database design upcoming project.

this classic inner platform problem, our client wants infinite customization , ability create forms , attributes on entity, collect them values end users, , able display collected information on graphs.

in used clinicians monitor patients, , why using eav thought we'll need collect different information different trial runs. might ate day. others might blood sugar, or blood pressure(which 2 numbers), , othertimes might multiple questions (how pain today 1-10?), idea we'll never know in advance end client asking for, or accepted values be.

we'll graphing data consistently throughout program, , generating larger reports on less regular basis.

ideally i'd able hard code of possible, using sql, , sticking relational database best practices simplify both database design , application design (both of i'm writing).

we're doing few trial runs, , first inclination information possible cients, hard code tables in database, , build there. if discover need use attribute table , attribue_value table collect attributes (along fun-to-implement form builder things dropdowns - , dropdown menu options , validation/required), later launches.

i've gone through every relevent stack overflow post; avoid eav, better understanding of requirements of application, and, @ point, if customer needs eav implementation, go ahead , then.

• has ever used hybrid model? can discuss it?

• has ever implemented eav model, , can discuss it?

• has been in similar decision, decided not implement eav project seemed might have been candidate? how did turn out?

here interesting reads i've found along way:

http://decipherinfosys.wordpress.com/2007/01/29/name-value-pair-design/ storing time-series data, relational or non? database eav pros/cons , alternatives alternatives entity-attribute-value (eav)?

and link gave me ton of insight.

after thought, , considering clients needs/requests, using eav model correct answer here.

after doing more research decided use postrgresql , make full use of hstore data type, allows storing, searching, , indexing of key value pairs in single field.

here paper benchmarking hstore vs eav: http://wiki.hsr.ch/datenbanken/files/benchmark_of_kvp_vs.hstore-_doc.pdf

the paper above benchmarks hstore vs eav table, , hstore came out way ahead.

another option considered having task table covered bases:

id, name, value_1, value_2... note_1, notes_2

obviously thought of killed me inside bit, either going use task_type attribute table:

a task prescribed administrator user , has task_type, task_type_attributes tasks of type (ie, define exercise task, want able store information intensity of exercise, time exercise took etc).

once user brings task, see task_attributes fields fill out. enter these fields, , attribute_value enter associated task_entry of patient (which states if completed it, skipped it, etc)

task_attributes

• id
• task_type_id
• attribute
• attribute_value_type (for generating desired fields on app side - ie, knowing have dropdown vs text input)
• min_value
• max_value
• required

task_entry_values

• task_entry_id
• task_type_attribute_id
• value

hope might of use someone. i'd interested in , criticism/feedback design.