Что первичнее: бины или бд

Может глупый вопрос, но я еще новичок:
-сначала пишешь базу, а потом по ней уже бины и как кстати - ручками или есть что автоматическое (хотя бы частично должно быть). Но тогда что отказаться от CMP или угадывать что сгенерит контейнер?
-или сначала продумать и написать бины а потом уже базу. Если CMP - то он сам наваяет, а если нет - то сам ручками.
-или эти процессы как то смешаны?

Вообщем, что первичнее - мысль или слово?

С уважением, oberon.

P.S. Насчет уважение это не просто присказка, я смотрю тут действительно такие спецы есть, наверно по EJB это самый представительный форум на русском. Спасибо что отвечаете.

0

Я скажу что я видел в Visual Age for Java. С теорией знаком слабо но практика такова, что в реальности внутри VAJ есть среда разработки схемы твоих бинов. То есть указываешь длину полей и их имена, ключи , зависимости по внешним ключам и если надо так называемы дополнительные ключи предикаты (обычно TimeStamp которые нужны для того что бы избежать гонок). После этого генерируещь бины с базовым набором методов для выбокри, создания ужаления и изменения. В последствии ты можешь ручками добавить какие то свои методы (Custom quireis которые обеспечиватют нестандартные SQL запросы) эти методы не трогаются при повторной регенерации бинов если ты поменяешь схему.
При желании схема на основе которой генерятся бины может быть импортирована из или экспортирована в СУБД. В первом случае бины будут созданы в соответствии с существующей базой. Во втором база будет соответствовать бинам. При желании можно связать бины с базой хитрыми всякими путями к примеру создать иерархию. Когда например бин будет связан с несколькими таблицми так называемая иерархия. Пример
1.) Таблица Клиент
2.) Таблица Иностранный Клиент (жёстко связано с Клиент 1-1)
3.) Таблица Локальный Клиент (жёстко связано с Клиент 1-1)
Бины для последних двух таблиц могут (если настроить) содержать (а также управлять то есть изменять) соостветствующую запись в Таблице Клиент. Типа какое то наследование получается.
И опять же такая схема может быть экспортирована в базу или настроена после импортирования.
Я очень извеняюсь если много наговорил. Может не всё по теме :-)

0

Да нет, немного. Затем и спрашиваю, чтобы ответы читать:-)

Но все что ты сказал, относится, я так понял, к VA, т.е. специфично, т.е. это скорее утилита IDE. Я хочу понять сам принцип без привязки к конкретной IDE или серверу (кстати, ни то ни другое пока еще не выбрал).
Хотя конечно очень интересно и заманчиво, хочу попробовать, кинь ссылку где скачать. Да, тут в форуме мелькало что VA заточен под соответсвующий сервер (или наоборот), раз уж ты работал, скажи - какой у тебя контейнер стоял и как с ним уживался.

Спасибо

0

Где скачать VAJ на халяву чесно не знаю да и 700 мег + FixPack это не мелко. И чесно говоря не советую тебе его изучать если нет прямой ориентации на IBM soft. Прелесть IBM в том что бы использовать все её продукты вместе. То есть DB2, VAJ(Websphere Test Environment встроено в него) и WAS (Websphere Advanced Server). Всё это удачно сочитается с друг другом. И как мы обсуждали преимущество этого всего в репутации IBM. То что через 6 лет фирма не пропадёт, все продукты хоть и не дешёвые но написаны (более или менее) надёжно. Для тестирования я сейчас сам в поиске сервера (думаю про resin или JBoss) вот тут мужчина расказывает как использовал WAS и JBoss
http://www2.theserverside.com/reviews/thread.jsp?thread_id=15053&article_count =33
А что касается сути вопроса в первичности и вторичности. Вот такие визарды для генерации бинов из базы и базы из бинов интегрированы в большинство сред разработки (хотя я точно не знаю)

0

Вопрос, на самом деле, простой и сложный.

В БД настраивались ограничения, присущие моделируемым объектам предметной обл. Все эти NOT NULL и CHECK CONSTRAINTS осуществляли очень серьезный контроль над непротиворечивостью данных. Хранимые процедуры выполняли бизнес-логику, как раньше обычные функции (чуствуешь, структурным программированием попахивает). А теперь бизнес логику выполняют компоненты и справляются с этим полнее, на более высоком уровне абстракции, скрывая детали реализации.

Поднятый вопрос уместно задавать, на мой взгляд, только когда речь идет о CMP. В этом контексте он, собственно, и задан, но, в отличии от вопроса, я бы делал акцент не на том, что раньше проектируется или создается, а на ослаблении ограничений уровня БД. Дело в том, что спецификация EJB определяет моменты времени, когда программист может устанавливать значения полей: в ejbCreate любым, не являющимся внешними ключами, а в ejbPostCreate созданная запись связывается с существующими. Более того, скрывая от программиста клиенсткой логики детали создания или обновления, запись может дополняться значениями уже после создания, хотя для клиента этот процесс неделим и выглядит как одно целое. Описанная вкратце модель вступает в противоречие с ограничениями на неопределенные значения (nullability). Может возникнуть конфликт с ограничениями проверки значений (check constraints). Конфликт с ограничением на внешние ключи (foreign key constraints) может возникнуть крайне редко, если рассматривать абстактную задачу.

Вывод: ограничения уровня БД перекладываются на уровень CMP EJB. СУБД начинает выполнять роль очень быстрого и надежного persistent storage.

Если CMP не использовать, то вопрос о конфликтах с ограничениями вообще отпадает. Говоря про то, что создавать раньше -- вопрос, который надо решать каждый раз заново. Лучше, конечно, если созданная БД будет правильно индексирована для уыеличения производительности. Это главное для CMP. Остальные ограничения, исключая nullability и местами check constraints, могут здорово помочь при отладке, хотя отлаженное приложение может в них и не нуждаться. Другой момент -- первичное наполнение БД. Если контейнер сможет, почему нет.

0

Говоря про модель EJB, ее проектировщики подразумевают, что созданное приложение будет использоваться в уже существующей enterprise системем, а значит и с существующей БД. В данном случае вопрос отпадает сам собой. А все потому, как мне кажется, что акцент, поставленный в вопросе, таковым не является.

0

если человек учится и он свободен от legacy DB (счастливчик , то вполне можно обойтись в процессе первичной разработки автоматическими значениями, что генерит контейнер (но тогда можно получить VARCHAR(255) вместо, скажем oracle's VARCHAR2(10) ). в процессе такой работы станут более явными все связи таблиц, и уже потом можно почистить толком схему базы, оптимизировать ее под загрузку, а в production mode промапить бины в базу.

по-моему, тоже есть смысл.

0

Согласен с отложенной оптимизацией. Я бы посоветовал тем, кто учится, делать так:

1) разработать схему бинов;
2) делегировать контейнеру создать схему БД.

Этот процесс будет повторяться многократно в процессе разработки, но в конце концов схема бинов и БД стабилизируется. Теперь самое время БД оптимизировать. Соптимизированную БД экспортировать в виде SQL-скрипта (он будет заточен под конкретную СУБД). В итоге имеем архив бинов и SQL-скрипт.

Теперь самое время разработать процесс deployment'а. Сначала на staging сервере, а потом, когда все утрясется, на production сервере.

Остается вопрос с первичным наполнением БД. Хочу уточнить, что здесь имеются в виду не какие-то эталонные или тестовые данные, а рабочие данные, являющиеся фундаментальными для решаемой задачи. Они формируют environment решения. Например, коды допустимых языков, первичные persistent разделы словарей и т. д. Так вот их надо иметь в БД на момент запуска приложения, и каким-то образом они туда должны попасть. Самое простое решение -- SQL-скрипт, но он заточен под конкретную СУБД. Можно попытаться использовать SQL-92, но он слабоват (как задать тип даты или времени или и того и другого для Oracle и MS SQL Server? как задать логический тип для тех же серверов? как вставить символьную строку туда же, если в одном случае она помечается кавыками, а в другом -- апострофами?). Можно сделать бин или standalone утилиту, выполняющую эту операцию. Но это сложнее. Ведь все равно есть SQL-скрипт создания БД, заточенный под СУБД.

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

0

Спасибо всем, особенно Danissimo и mr_dronski.
Вопрос о первичности разложили для меня почти по полочкам, во всяком случае для моего сегодняшнего уровня. Кстати, что такое 'staging' сервер?

0

2 Danissimo
Мне кажется что если первчичное наполнение выходит за рамки простого скрипта то это уже признак не совсем павильного дизайна. И в чём плохо если всё таки он будет заточен под конкретную СУБД. Мы же не дети и понимаем что все эти сказки про переносимость это для журналистов. На практике всё гораздо проще есть какая то база которую хочет клиент (хочет две базы... ну пусть платит за два скрипта :-)

0

2 simplepilot
Почему выходит за рамки простого скрипта? Не выходит. Я ж говорю, что можно написать sql-скрипт для первичного наполнения БД. Но его применимость ограничена СУБД. Чтобы обойти это ограничения можно написать простое jdbc-приложение, но это немного сложнее, только и всего.

А про переносимость и дополнительную стоимость могу сказать так: все это правильно, но опять-таки для журналистов :-) Заказчик всегда хочет съэкономить, а исполнитель обогатиться. Сотрудничество заказчика и исполнителя -- копромис, наденный первым (интерес исполнителя затрагивать не будем) между ценой и качеством (ну, в приближении к идеалу). У заказчика возникла идея, но он не знает, каков экономический эффект принесет ее реализация, поэтому он не желает вкладывать большие деньги: он берет бесплатные серверы (или почти бесплатные), минимальные требования и т. д. Если идея окажется достаточно рентабельной, то возникнет вопрос о переносе всей этой ботвы на мощьные и дорогостоящие серверы. Исполнитель тем больше выиграет (материально или косвенно материально), чем переносимее будет его код.

0

2 Danissimo
Просто по принципу нашей конторы могу сказать что у нас уже давно сформировался принцип работать только с IBM софтом и мы за рамки своей компетенции не лезем. Заказчик если он хочет что то ещё скорее всего будет искать других исполнителей, так как мы не компетентны. С другой стороны по этой же причине мы сейчас имеем ряд проблем с поиском новых заказчиков :-)

0