L_argoУверенная позиция в Gartner тоже прыщавый бред ?

в огороде бузина, а в киеве дядька


L_argoВы тупее, чем я думал.

вы переоцениваете свои способность по поводу "думал" :)

drynnyВам привели аргументы, ссылки на конкретные описания, тесты, замеры, работающие сервисы.
Где ваши аргументы? Не в виде летящих абстрактных какашек с нелепыми аллегориями, а нормальные доводы?

Доводы простые, я их уже приводил. Так как вы их не нашли, судя по всему вам не очень-то интересно.

1. С нормальной нормализованной БД работать может любой разработчик, аналитик, BI-щик и другие заинтересованные лица.
2. Нормальные таблицы хранят данные по колонкам с соответствующими типами, ограничениями, поддержкой целостности со стороны БД, это всё работает максимально быстро, оптимально, компактно, так как это заложено в самой природе СУБД.
3. В вашем случае более менее приемлемая производительность вытягивается индексами, в то время как те же индексы в нормальных таблицах, особенно если правильно расставлены, работать будут намного быстрее ваших костылей.
4. Как следствие, покрытие всё 100% индексами, ожидаемый результат архитектуры на костылях

Ваша архитектуры не может быть охарактеризована никак иначе, как костыли и подпорки в чистом виде. Переусложнённые кривые концепции, которые ничего не решают и не дают ничего.


drynnyНапример, покажите, что вы хоть сколько-нибудь понимаете о чем тут речь, ответьте: какая нормальная форма используется в этом решении?

Никакая. Но вы конечно можете думать иначе.

drynny,

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

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

рай для BI-щика. плюс к этому полноценные DSL для программирования бизнес-логики на самом высоком уровне (не требуются квалифицированные программисты) в терминах бизнеса. чистый DDD.

и всё это на CQRS, Event Sourcing.

никакого уродливого кривого EAV нам для этого не понадобилось. нет его даже в зачатках.

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

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

L_argoВ принципе так и есть, но есть нюанс: с такими метаданными трудно работать.
Нужно каждую таблицу/поле обернуть кодом, раздать права и т.д.
Добавление колонок в большую таблицу может привести к тяжелым последствиям в нагруженном проде.
Эти постоянно меняющиеся таблицы сложно реплицировать, мигрировать и репортить.
Система управления такими метаданными будет сложной. Таблиц и полей в общем случае будет эпично много даже в небольших проектах. Доработки потребуют больше времени.

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

просто дальше EAV многие не смогли продвинуться. каменный век в головах и неспособность находить качественные, эффективные, не обязывающие решения.

SiemarglКак решена задача - в программе получить объект (отчет, сущность) в версии структуры, которая была скажем 10 итераций изменений структуры ранее ?

подсказываю...

1. Event Sourcing -- вы можете вообще получить систему в идеальном состоянии на любой момент времени её существования без лишних артефактов.

2. Event Sourcing -- вы делаете сколько угодно проекций под разные задачи. идеально строго нормализованная структура БД -- это лишь одна из авто-проекций.

бизнесу часто требуются денормализованные данные. отдельные микросервисы могут создавать и вести свои проекции без зависимости от общих изменений модели данных.

SiemarglНа первый взгляд выглядит еще страшнее.

это сложнее. поэтому многие и не лезут дальше, чем могут осилить -- еав

drynnyСлив засчитан.
Данные в таблице по-любому в какой-то нормальной форме.

Нет, не по-любому, вы ошибаетесь.
Поэтому выглядите вы жалко со своим "сливом", чесслово.

Siemarglsoftwarerпропущено...

Да ну правда что ли? Да. Хотя бы в 1НФ

Ну ппц..