Так, извиняюсь, был занят, вечером почитаю. Мне кажется вы недооцениваете сложность. Вариант с атрибутами в строке - вообще не вариант. Я не могу полностью раскрыть детали, но грубо говоря, все сводится к тому что

- пользователь системы будет создавать именно доменную модель, ни больше не меньше. То есть на скрине будет - создать Сущность, указываешь имя и можно добавлять поля, каждое поле может быть как примтивом так и другим объектом, в том числе возможны ссылки на саму себя. Также нужна возможность указывать констрейнты(реквайред, мин значение, макс, тд) Вторым шагом генерируется jar файл, который аплоадится в некий мавен репозиторий, что с ним дальше будет, это уже к делу не относится. Третьим шагом, пользователь может вставить конкретные записи в эти объекты, то есть нужен скрин, на котором будут указаны все поля и кнопка сохранить, валидаторы должны автоматически подхватываться, если реквайред и поле нулл - ошибка.
Также предполагается что будет персистент обертка, которую будут дергать через API, в основном для CRUD. Но репортинг также важен, правда не для пользователя а скорее администратора.

Вариант купить вполне возможно рассмотреть - просто купить что? Если есть что-то ложащееся на эти требования - с удовольствием рассмотрим.

ViPRos,

понял. обязательно посмотрю.

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

А джойны это как решит то?

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

ИМХО
А вообще система в которой пользователи создают тн бизнес логику - хороший маркетинговый ход, но по факту бесполезны в лучшем случае (за искл. каких-то экзотичных вариантов). Модно вот было BPM какое-то время, прямо пользователь взял так и нарисовал бизнес-процесс стрелочками и квадратиками - стухла тема. Легче взять еще программеров в штат, чем обучать экономиста этому всему и отвлекать ненужными знаниями, а зарплата бизнес-аналитиков сопоставима с прогерской, а то и выше, тоесть вообще убыток.

Вообще вот вопрос: как Вы себе это представляете чтобы пользователь сам там что-то делал? Джойны, констрэинты, примари кейз, отношения объектов, типы данных и т.д. ?

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

Насчет джойнов - ну идея в том, что после каждого обновления таблицы рефрешить view, благо число апдейтов не должно быть большим. NoSQL это же schemaless как он может тут помочь? Я не критикую, правда не понимаю.

maytonзабыл ник,

нарисуй нам пожалуйста интерфейс




так у нас будет предметный разговор. С именами методов. С аргументами. С retvalue.

Так а какой интерфейс я могу нарисовать, если еще даже не понятно будет это БД или нет. Если полностью абстрагироваться от технических деталей, задача в том, чтобы пользователь зайдя в систему мог создавать типы данных, добавлять удалять свойтсва и тд. После того как он закончил, он идет на форму, которая автогенерится на основе типа, и может создать конкретные инстансы, они должны быть персистентны. Ну допустим создать сущность Покупатель, с полями 1,2,3. Товар(4.5.6) Заказ(7, 8). Идет на форму и вносит значение для покупателя Васи, Товар Porsche, Заказ номер 7. С течением времени он понимает что у каждого покупателя должен быть телефон, он идет в админку и добавляет поле Телефон: String, required, pattern = ..., minLength=12. Идет на форму и она уже отражает что у этой сущности есть свойство телефон. Добавления должны происходить без каких-либо рестартов, и даже операционного вмешательства админа.

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

То есть на самом деле schema данных нужна, просто она должна быть relaxed as possible. Единственный вариант, который я вижу - это EAV, причем в крайнем случае БД будет состоять из всего 3 таблиц. Мне это все тоже очень не нравится, так как EAV имеет много негативной критики. но я не вижу альтернатив. Как говорится, надо выбрать менее пахучий сорт г..а

ViPRosзабыл ник,

то что ты описал - это генератор приложений (сервисов)
ВИПРОС и есть такой генератор
модельщик (пользователь с соответствующими правами) описывает домен, а ВИПРОС генерирует БД и UI

В общем-то, это действительно очень похоже на то что нужно, в концепции. Но покупка исключена как минимум по двум причинам. Заказчик англоязычный, и нужно веб-решение.
Хотя сама разработка меня реально заинтересовала, вы говорили что где-то приводили принципы построения таких систем - не можете предоставить ссылку? Ну а если у вас есть возможность поделиться опытом создания подобного, и костылями - вообще замечательно. С удовольствием обсудил бы с вами.

maytonА каким образом наличие/отсутствие БД влияет на интерфейс? Ты никогда не проектировал?

Моделирование предметной области - это лишь важная, но небольшая часть всей системы. После создания домена, будет автосгенерен jar, который будет использоваться.. ну не важно как в общем. Будет API на неком сервере, которое будет предоставлять REST HTTP интерфейс для CRUD вот этого счастья. Это общедоступная часть.

Проблема в том, что есть админская часть, которая в том числе будет делать репорты, довольно сложные по созданным сущностям.
Я не понимаю, какой интерфейс вы имеете ввиду.

Изопропилзабыл никчто есть админская часть, которая в том числе будет делать репорты

репорты ваять будут всё те же вислоухие пользователи,
что поля добавляют?

Честно говоря, нельзя отсеивать такой возможности. Я бы не стал доверять полностью заказчику, пока что говорит что не будут, но вы знаете как это бывает :) Проект очень мутный пока, именно поэтому нужен PoC, честно говоря уверенности никакой нет, но это наша работа)