Динамическое создание модели данных

Добрый день,у меня какая ситуация для работы с БД используется модель данных(других вариантов нет),всё бы хорошо,но я до конца не знаю какое количество у меня будет полей и какого они будут типа.Собственно вопрос как можно в нужный мне момент генерировать эти самые поля в модели для БД.Чтобы было понятнее попробую привести пример.
Происходят какие либо действия и нам становиться известно что поля будет 2 int id;String name;
и у нас есть модель
model.java

public class Model
{
public Model()
{
}

}
как мне привести её к виду
public class Model
{
int id;
String name;
public Model()
{
}
getter/setter
}
с учётом того что это должно происходить во время выполнения программы или подскажите альтернативу)За ранее спасибо,надеюсь понятно объяснил)

0

Хм..Задание, конечно, интересное. Ну, а как насчет такой структуры:

Допустим fields - это мапа Ваших полей(например, HashMap), в которой ключ - это имя поля, а значение это, собственно, значение
Можно добавлять, поля которые необходимо, получать их значение, изменять имя.

1

я рассматривал это как вариант,но тут есть кое какие нюансы а именно т.к используется noSql и происходит запись самой модели в бд(по другому нельзя только через модель,нет такой вещи как Insert table into() value(),а может и есть,но я как то не нашёл)то есть в бд будет находиться все мои данные в одной ячейки,записать я смогу,но вот как мне в последствие с этими данными работать)
Запись будет приблизительно такого вида
id= 1;
name = test;
помещаем это всё в мапу и отдаём модель на запись в бд
в бд:Название ячейки id;1;name;test
не уверен что именно такая будет запись,но потом доставать эти данные и парсить их через StringTokinaizer как вариант,но это если 2 поля,а если их 10 или больше

0

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

1

Конечно,есть интерфейс(настройки так называемые)там пользователь выбирает(создаёт) модель свой будущей базы данных\интерфейса,он выбирает какие поля будут использоваться и даёт им имена(указывает наличие валидаторов и т.д)вся эта информация храниться в мапе<Название(которое потом используется для css,Component)>дальше происходит инициализация интерфейса из мапы достаются значение и ключи и создаётся интерфейс(так же форма для добавления элементов и удаления и т.д)и теперь когда мне нужно добавить элемент в бд(форма отдаётся сервелету который создаёт экземпляр класса и его уже записывает с помощью менеджера в бд).Вот и остаётся лишь вопрос с моделью как мне её изменять в зависимости от конфигурации пользователя.Понятно объясняю?))

0

Сообщение от qwerty23_13 Конечно,есть интерфейс(настройки так называемые)там пользователь выбирает(создаёт) модель свой будущей базы данных\интерфейса,он выбирает какие поля будут использоваться и даёт им имена(указывает наличие валидаторов и т.д)вся эта информация храниться в мапе<Название(которое потом используется для css,Component)>дальше происходит инициализация интерфейса из мапы достаются значение и ключи и создаётся интерфейс(так же форма для добавления элементов и удаления и т.д)и теперь когда мне нужно добавить элемент в бд(форма отдаётся сервелету который создаёт экземпляр класса и его уже записывает с помощью менеджера в бд).Вот и остаётся лишь вопрос с моделью как мне её изменять в зависимости от конфигурации пользователя.Понятно объясняю?))

Да, вполне понятно. Окей, давайте попробуем разобраться в следующем: когда клиент выбирает модель своего интерфейса, то у него ограниченное количество вариантов или на клиентской стороне будут добавляться новые возможности? Если у него ограниченное количество вариантов и интерфейс генерируется исключительно на одном наборе, только с разным количеством, то мы можем использовать один класс, в котором буду все поля, удовлетворяющие предоставляемому нами выбору для клиента.
Пусть у нас 10 вариантов для интерфейса(имя, фамилия, ник, год рождения и т.д. что взудмается), тогда мы создаем соответствующий класс Interface, в которм присутствуют перечисленные поля. Когда мы получаем мапу(хотя, мне кажется, что здесь лучшим выбором будет JSON), то мы заносим данные по соответствующим полям и сохраняем в БД(неиспользуемые поля - null). Когда же мы будем доставать данные и строить соответствующий интерфейс для пользователя, то все нулевые значения будут игнорироваться, а на основании остальных будем отображать то, что необходимо. Неплохо было бы заюзать JAXB. Правда, большим минусом такого подхода является слишком большой класс при необходимости огромного интерфейса(затраты памяти на создание и хранение).
Возможно, использование варианта с мапой не самый плохой, но необходимо будет создавать дополнительный сервис, который будет сохранять в БД и парсить из нее для получения данных для конкретного пользователя.

1

Есть более простой способ,это отказаться от noSql и работать с SQL благодаря тому что я смогу установить связь с бд и выполнить query типа(Insert table into() value()) модель по факту мне не понадобиться и в последствие уже обращаться к самой бд и работать с данными полученными через запросы,мне кажется это самое рациональное решение,или я ошибаюсь?

0

Сообщение от qwerty23_13 Есть более простой способ,это отказаться от noSql и работать с SQL благодаря тому что я смогу установить связь с бд и выполнить query типа(Insert table into() value()) модель по факту мне не понадобиться и в последствие уже обращаться к самой бд и работать с данными полученными через запросы,мне кажется это самое рациональное решение,или я ошибаюсь?

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

0

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

1

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

0

Вы пока толком не рассказали про ТЗ, а уже ждёте советов.
Если вы про автоматическое создание таблиц по сущностям ORM, то это всё уже давно есть и задача заключается в маппинге типов java на соответствующие или близкие по значению типы из конкретной БД.
Но генерить связи, индексы и тд всё равно придётся с участием человека.
Обратная ситуация - генерация снизу вверх тоже уже реализована и тоже требует участия человека.
На сегодняшний день проблема вообще не в генерации, а в выборе оптимальной стратегии для ожидаемой производительности приложения.
То что вы смутно себе представляете на самом деле никому и близко не нужно.
Если бы можно было бы что нибудь подобное создать жизнеспособным, кто бы стал платить столько денег программистам за разработку типичных бизнес приложений по стандартной модели?

0