softwarerhVosttМеня даже уже не великий и беспощадный смысл, который вкладывал автор в это. А как он к этому пришёл. Вот как рассуждал?

Да как обычно в таких случаях. Начинает знакомиться с предметной областью. Читает SQL. Думает: как бы круто программировать? Натыкается на EAV: о, круто. Особенно читая статью другого такого же ламера. Пробует. Плевать, что медленно и неудобно, зато один раз напишу крутой системный софт - это же интересно - и всё будет летать. Блин. Не летает. Тогда подрихтую модель, чтобы залетало. Совсем круто! Правда, не летает, но зато совсем своё, дайте мне нобелевку!
Что-то накал обсуждения ослаб. Подкину немного.

Когда-то, в 70-е, программное обеспечение часто разрабатывалось почти с нуля, а вычислительные мощности в принципе не позволяли создать конструктор, подобный IdeaV: он требовал бы на 3 порядка больше ресурсов. В 1000 раз больше ресурсов.

Потом, в 80-е, программисты стали использовать свои же, ранее написанные библиотеки программ. При этом для работы такие программы требовали в разы больше ресурсов на единицу полезного вычисления, чем написанные с нуля. Зато этот подход ускорял разработку также в разы. Конструктор требовал бы в 100 раз больше ресурсов , что было непозволительной роскошью.

Далее, в 90-е, программисты стали использовать, в основном, не свои наработки, а сторонние библиотеки и инструменты разработки. Чужой инструментарий часто был закрыт, решения работали медленнее, страдала совместимость. Тем не менее, использование библиотек ускоряло разработку на порядок-два. Вычислительные мощности росли, поэтому все легко мирились с тем, что их требуется также на 2 порядка больше. Теоретически, конструктор требовал бы в 10 раз больше ресурсов.

В 90-х были последние известные попытки создать нечто подобное моему конструктору, после чего идея, которая далеко не нова, была признана неработоспособной. Я внимательно изучил один из популярнейших эпизодов. Причина неудач: разработчик не опускался до низкого уровня написания программ, по привычке 80-90-х годов таща за собой библиотеки и стереотипы разработки. Вместо фундаментальной проработки ядра ставка была сделана на новейшие технологии.

В 2000-х мы наблюдали прежние темпы роста вычислительной мощности. Библиотеки программ стали шире, мощнее и устойчивее. При этом бесконечное богатство инструментария разработки сыграло с разработчиками злую шутку: выбор и овладение инструментом требовало столько же усилий, сколько тратили программисты из 90-х, при примерно одинаковом конечном результате. Скорость разработки уже не росла пропорционально накладным вычислительным расходам, как это было в 70-90-е годы.

Расчетная эффективность конструктора и традиционной разработки сравнялись в нулевых годах. В 2003 году мной, в качестве хобби, был спроектирован конструктор, а в 2006 запущен в реальном проекте (работает до сих пор). Конструктор использует простейшие технологии, основанные на наработках прошлого века, достаточно быстрые и надежные для своих задач.

На сегодняшний день, в 2019 году, при невероятной вычислительной мощности техники, мы можем секундами ожидать, когда на экране нашего монитора прорисуется web-страница (точно как в конце 90 х). Сервисы, которые мы используем, представляют собой сложный и многослойный пирог, который требует всё больше ресурсов и работает всё медленнее. Прогресс информационных технологий (IT) нивелируется их же сложностью и растущими требованиями программных продуктов. Ситуация как в постулате: «бюрократия расширяется, чтобы удовлетворить нужды расширяющейся бюрократии». Скорость разработки так и застыла на уровне 90-х годов.

hVosttdrynny,

Ваше видение истории доставляет, но как говорится, для кого-то Москва это сырой подвал, а для кого-то вид на Кремль с чашкой кофе.

Про квинтеты можете ответить? Не про конструкторы, не про скрытую магию для высшего существа, лениво двигающего мышкой.

Про реализацию. Какого хрена так всё усложнять? В чём смысл?
Где вы видите сложность и в чём её измеряете?

hVosttdrynnyГде вы видите сложность и в чём её измеряете?

Я вам уже показывал математику выше.

Там, где требуется 2 поля для хранения сущности, у вас 5.
Многосложная семантическая нагрузка на поля и комбинацию полей.

Какой профит? В чём смысл?
При чем тут семантическая нагрузка и какое отношение она имеет к пользователю, у которого визуальный редактор и всё просто?

Факт 2 против 5 вообще ни о чем.

Но давайте другие рассмотрим. По вашей методике — сравним числа :-)

1) Поскольку мы решили скрывать от пользователя все несущественные детали, такие как связующие ID, например, схема будет несколько упрощена: удалены упоминания ID и объединены названия сущностей и их ключевые значения.

Классическая схема:


В квинтетах:


Теперь мы видим 6 разных полей данных вместо 9, а вся схема предлагает нам прочитать и осмыслить 7 слов вместо 13.

2) Ядро для работы с квинтетной моделью состоит из 2300 строк кода и будет только сокращаться при написании нового ядра СУБД. Оно занимает пару мегабайт в оперативной памяти, оставляя много места под данные, кэш индексов и прочие полезные вещи.
Использование памяти можете посмотреть здесь: habr.com/ru/company/neoflex/blog/451218/#tests
(там в среднем 32 запроса в секунду занимают суммарно менее 100МБ памяти)
Сравните с вашими мелкосервисами на Java и предъявите сюда ваши картинки.