LINUX.ORG.RU

[java]Библиотека генерации таблиц СУБД

 


0

1

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

Table t = new Table();
t.add(new Field(t, "id",Type.UUID));
t.add(new Field(t, "name",Type.STRING));
DB.create(t);

причем так как движок генерации запросов и из выполнения есть то особой сложности как бы и нет, но хотелось бы проверку субд на наличие таблиц (чтоб не удалять), проверка полей, т.е. анализ, так чтобы библиотека сама определила что нужно, например не создавать таблицу с нуля, а выполнить alter table и т.п.


Ответ на: комментарий от kifer

Это умеет hibernate (hbm2ddl) называется. В режиме update она как раз пытается сделать alter-ы.

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

dizza ★★★★★
()
Ответ на: комментарий от kifer

Нет. Зато умеют специальные примочки к хиберу. Но все равно все эти генераторы, как и любые генераторы кода - кал.

dizza ★★★★★
()
Ответ на: комментарий от dizza

Ты просто не представляешь что за система: разработчки не шарящий в SQL в гуйне рисует сущность, например «Работник» добавляет в него ссылки на другие сущности, и свойства, потом жмякает - ок, и сабж генериурет в базе соответсвующие таблицы. Причем оно уже работает.

kifer
() автор топика
Ответ на: комментарий от kifer

есть тонны тулзов, которые генерят sql код из uml. жаба-то тут нафига?

Rastafarra ★★★★
()
Ответ на: комментарий от kifer

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

Rastafarra ★★★★
()
Ответ на: комментарий от Rastafarra

н екоряво ненужно, коряво и без хибернейта можно. про хранимки народ забывать не хочет ибо масштабы таки шо хибернейт курит в сторонке :(

kifer
() автор топика
Ответ на: комментарий от Rastafarra

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

Примеры таких, что с ними нельзя работать без хибера, автогенеренных таблиц в студию!

Nagwal ★★★★
()
Ответ на: комментарий от kifer

Сочуствую. Затей провальна, увы. А вообще да, хибер прикрути и не парься. Только про not null поля нужго забыть. А сущность генерить придется через байткод. Пробегала статья от физтеховцев-теоретиков на эту тему: http://habrahabr.ru/blogs/java/91239/

Кстати, СУБД то хоть одна будет использоваться? Если да, то можно ввести такие ограничения:

* каждая таблица имеет сурогатный ключ id * нет not null полей * все текстовые поля типа text * в жопу индексы * в жопу FK

И тогда можно запросто сморганить генератор самому.

dizza ★★★★★
()
Ответ на: комментарий от Rastafarra

Каждый раз, когда слышу про хрнаимки, прозреваю, что в проекте нету юнит-тестов. В жопу хранимки. Только sql 92 для сложных селектов + hibernate. Все остальное ведет к неподдерживаемой лапше sql кода/

dizza ★★★★★
()
Ответ на: комментарий от dizza

Это хибернейт головного моска, если от него отказаться то внезапно ненужны извраты с байткодом, not null работать начинает, как и ключи.

Милок, яже сказал все это уже работает, причем давно.

kifer
() автор топика
Ответ на: комментарий от kifer

Это хибернейт головного моска, если от него отказаться то внезапно ненужны извраты с байткодом, not null работать начинает, как и кл

Извраты с байткодом не нужны, это все физтеховцы-задроты. Not null у меня тоже прекрасно работает. Только миграции нужно ручками делать. Короче ниосилятор хибернейта детектед.

dizza ★★★★★
()
Ответ на: комментарий от dizza

Следующий поворачивай детектор от себя, а пистолет тебе вотще низя давать - застрелишься.

kifer
() автор топика

Amazon Carbonado +немного кода ручками.

cnupm
()
Ответ на: комментарий от dizza

+1 только hibernate как и хранимки не нужен, он несколько упрощает жизнь на начальном этапе, но сильно усложняет на последующих.

Legioner ★★★★★
()
Ответ на: комментарий от dizza

> В жопу хранимки. Только sql 92 для сложных селектов + hibernate. Все остальное ведет к неподдерживаемой лапше sql кода

что потом делать с прикручиваем скажем веб-морды?

Rastafarra ★★★★
()
Ответ на: комментарий от Legioner

но сильно усложняет на последующих.

Тут скорее всего не хибернейт виноват. Неудобная работа с хибером vs неподдерживаемый sql - хорен редьки не слаще.

dizza ★★★★★
()
Ответ на: комментарий от dizza

SQL как раз поддерживаемый.

Попробую пояснить, что я имею в виду. Современные БД развивались десятки лет. Параллельно с ними развивалось знание о том, как БД использовать. Есть многие специалисты, которые могут «тюнинговать» запросы, знают как лучше оптимизировать БД.

А Hibernate это всё выкидывает и превращает SQL в примитивную лапшу одинаковых select-ов.

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

Видел неоднократно, когда приложение с Hibernate просто отвратительно работает с базой. Да, может быть гуру Hibernate сможет этого избежать. Но в итоге это получается очень сложный инструмент. Или всё тормозит.

В чём это похоже на спор Haskell vs C. Да, Hibernate удобен, более высокоуровневый. Но там, где нужна производительность, лучше писать на том, на чём проще оптимизировать.

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

Просто ессть крайности. И для разных крайностей нужен либо sql либо hibernate

dizza ★★★★★
()
Ответ на: комментарий от dizza

> А какие проблемы?

кроме того, что хранимки/триггеры/view сильно помогают наплодить толпу клиентов, проблем нет. но. хибернейт с хранимками и триггерами и иногда вью жить не хочет. хибернейт не нужен?

Rastafarra ★★★★
()
Ответ на: комментарий от Legioner

> А Hibernate это всё выкидывает и превращает SQL в примитивную лапшу одинаковых select-ов.

+1

Rastafarra ★★★★
()
Ответ на: комментарий от Rastafarra

Не понял про «хибернейт не хочет жить во вью»

У меня нормально живет.

Нужен, но аккуратно и со здравой долей sql.

dizza ★★★★★
()
Ответ на: комментарий от dizza

> Не понял про «хибернейт не хочет жить во вью»

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

Rastafarra ★★★★
()
Ответ на: комментарий от Rastafarra

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

kifer
() автор топика
Ответ на: комментарий от kifer

> за контекстозависимость результатов запроса надо бить кувалдой по рукам.

дада, расскажи мне больше. calcReport(id) — типичный контекстозависимый запрос.

Rastafarra ★★★★
()
Ответ на: комментарий от kifer

сгенерили, поменяли в БД записи (да хоть другим клиентом), перегенерили (типа). и видим, что нифига не поменялось.

собсно calcReport высосан конечно, у меня было как-то не так, но очень похоже.

Rastafarra ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.