Максим НПрогресс не стоит на месте, расцветают kv-базы, документоориентированные, графовые и др. (не мне вам рассказывать). Вот я и подумал, что наверняка есть какой-либо другой способ решения данной проблемы.
Про плюсы и минусы EAV все прекрасно знают. А вот про минусы использования графовых баз (или других решений), что из этого вообще может получится, я пока информации найти не могу. Видимо придется пробовать самому.
...
Может глупость скажу, но все же: а как же тот самый Эксель, где пользователь сам описывает и заполняет таблчики, делает выборки над ними, имитирует связи между ними, расчеты и т.д.

Bogdanov AndreyДаже excel имеет слишком высокую для большинства пользователей сложность. Далеко не все осваивают создание формул, а уж про аналитику и говорить не стоит. Если же к нему навернуть еще и некое "описание модели данных", то это станет инструментом для совсем немногих (тот самый один из тысячи, о котором писал kdv). Но хитрость как раз в том, что для этих "избранных" уже существуют гораздо более удобные и функциональные инструменты.
В общем, прежде чем создавать новый конструктор надо четко понять целевую аудиторию. Если это будут программисты, то подходы используются одни, для менеджеров - совсем другие, а для бухгалтеров - третьи. А если использовать программистские подходы в инструменте для бухгалтера, то ни программист, ни бухгалтер нормально им пользоваться не сможет.


Максим, если речь идёт о создании некоего универсального конструктора, современного продвинутого экселя, причём в рамках какой-то своей тренировки, то рекомендую оценить такой подход.

Может есть смысл сделать продвинутые Mind map . Есть куча десктопных инструментов для их создания, и куча вэбсайтов для этого (возможно есть и готовые фреймворки) и т.д. Но вот продвинутых, для полноценного моделирования, что-то не видно. Возможно, они кому-то реально потребуются. Вот, к примеру, здесь можно посмотреть примеры того, что эти диаграммы вполне могут быть интегрированы и с другими элементами: с графиками, таблицами и пр. Рекомендую подкрепить эти карты памяти взаимосвязанными хотя бы таблицами, вики-текстом (причём с метаинформацией, т.е. понимать вики-текст как структурный документ, с разделами и идентификаторами и пр.), ну может и графиками и пр. Естественно, оперировать нужно не просто текстом (как обычно в диаграммах), а полноценными "эксель-данными". Для программистов можно дать возможность оперировать языком программирования. В проекте Анимотрон есть пример пролого-подобного языка. Вот здесь (или здесь презентация) - ещё один пример пролого-подобного - это инструмент для анализа кода, где тоже имеется понятие реляционных отношений. В проекте TinkerPop есть ещё один пример языка над графовыми данными.
Для рядовых пользователей можно дать визуальный инструмент для алгоритмов (или в дополнение к языку "формул"), в виде блок-схем или подобное, или что-то по мотивам Sctratch, например, взять гугловский Blockly .

Возможно в глобальном масштабе подобный сайт окажется востребован. Но будет ли эта задача просто для изучения, всё-таки неслабый функционал.


По поводу графовых баз и прочего NoSql. Я не эксперт в них, и у меня нет практического опыта их применения на серьёзном проекте (но кое-какой неуспешный опыт есть). У меня к ним сформировалось предостережение. Во-первых, нужно понимать риски и проблемы с надёжностью данных. Не забывать, что они специфично реализованы, якобы решая проблемы традиционных SQL-баз (повышая производительность, где может не быть журналов, транзакций, реализуют горизонтальное масштабирование, делают кэш базы в памяти с дампами на диск и т.д. и т.п.), и эта специфичность может вылезти боком иногда. Ну, например, манипулирование через memory map даёт выше производительность, но при глюках софта случайная запись в соответствующую область памяти кроме краха процесса или потока может дать и запись мусора в БД. Или если СУБД всю базу отражает в памяти, то можно эту память легко всю выжрать.
Во-вторых, нужно оценивать способы работы с данными на низком уровне. Например, если СУБД не предусматривает какое-то создание версий данных где-то рядом с исходной записью, то после модификаций данных или/и удаления (т.е. начинаются попытки использования СУБД как SQL-БД) картина уже не такая радостная (а по первой имеется бешеная скорость добавления даже огромного количества данных, мгновенные выборки и пр.). Или платой за schema less может послужить то, что внутри каждой записи имеются имена полей, кроме самих данных, и в какой-нибудь mongo это запросто может заставить создавать имена полей из пары символов.

Короче говоря, здесь могут реальные эксперты привести кучу проблем, так и успешное соответствующее применение. Единственно, что раздражает, это когда "эксперты" бросаются громкими словами, типа посмотрите на фейсбуки с твитерами, как-будто это их личный опыт и успех. В тоже время забывают про тот же скайп, который мучается на постгрессе, имея кучу распределенных баз (они, кстати, вроде как где-то делились своими разработками и расширениями для постгресса, включая, если не ошибаюсь, возможность выполнения распределенных sql-запросов).