hibernate.hbm2ddl.auto consult and doubts

[dr_pompeii]

There are DB designer tools that like ErWin or PowerDesigner that can (and should) be used to design db schemas.

always i use the hbm files, the class diagram normally with hibernate should be the same
that ER for he DB

regards

[al0]

thats the problem the boss want the system to enter to production in a 95% and i am afraid to listen, "i want this....." and change the db schema


i will read carefully that, coz i dont how do that ,thanks for the tip


so you dont use your hbm mapping files to create the tables?

wooh, how you manage at least 50 tables with 20 fields ? manually?

regards and thanks for your time

Never was in position to do it - never have used Hibernate for such kind of applications. The biggest application that I have done with Hibernate had about 10 tables (w/o Hibernate - about 300 tables ).

First of all, I woul rather start from DB tables, then Java objects and only then - mappings. But in any case I would use a tool only for initial generation and not for the evolution (except validation mode of hbm2ddl).

Do not forget that data in DB have tendencies to outlive any given application (if not technology) and to be shared with many ones (even if it was not initially supposed). So DB data structures is of utmost importancy.

Regards,
Oleksandr

[al0]

There are DB designer tools that like ErWin or PowerDesigner that can (and should) be used to design db schemas. Anything else will, on any project of a decent size, sooner or later, end up as another IT disaster.

For me nothing is more clear and convinient as good old plain SQL scripts (with decent comments). Tools mentioned do not give clear overviewof any DB with more then, dare to say, 100 objects. Diagrams becomes ovecrowded and/or clottered.

[dr_pompeii]

The biggest application that I have done with Hibernate had about 10 tables (w/o Hibernate - about 300 tables ).

pretty number

First of all, I woul rather start from DB tables, then Java objects and only then - mappings.

right order, same approach i do

Do not forget that data in DB have tendencies to outlive any given application (if not technology) and to be shared with many ones (even if it was not initially supposed). So DB data structures is of utmost importancy.

thats right, the baseline of the rest of the layers

For me nothing is more clear and convinient as good old plain SQL scripts (with decent comments). Tools mentioned do not give clear overviewof any DB with more then, dare to say, 100 objects. Diagrams becomes ovecrowded and/or clottered.

lower programming is powerful always, Erwin for few tables is nice, but for a lot
is a wonderful hell



regards

[dejanp]

For me nothing is more clear and convinient as good old plain SQL scripts (with decent comments). Tools mentioned do not give clear overviewof any DB with more then, dare to say, 100 objects. Diagrams becomes ovecrowded and/or clottered.

For you perhaps, but you are not writing the application and documentation for yourself.

You should have many diagrams, showing different facets of the schema. One diagram representing all the tables of a non-trivial system is as usefull as reading a telephone book from cover to cover.

[al0]

For you perhaps, but you are not writing the application and documentation for yourself.

You should have many diagrams, showing different facets of the schema. One diagram representing all the tables of a non-trivial system is as usefull as reading a telephone book from cover to cover.

Documentation, first of all, shal lbe useful. To be useful it shall be concise, or nobody would read it And text is unbeaten in this area (save mathematical formulas, but htat another matter). And you would not believe how many peoples have started projects with me screaming for diagrams and ended with (almost) all diagrams in trash cans and (almost) all descriptions in text.

Diagrams are great for teaching purpose, for presentation to peoples that anyway would undestand nothing and for child-toy projects. In real life (from my experience) the do not pay for yourself.

But this, really, does not belong to this thread and even to this forum.

[al0]

pretty number

Really, it was very small number achived with very careful DB design as many applications with similar functionality (it was almost "all-in-one" banking system) use literally thousands of tables.

[dejanp]

Documentation, first of all, shal lbe useful. To be useful it shall be concise, or nobody would read it And text is unbeaten in this area (save mathematical formulas, but htat another matter). And you would not believe how many peoples have started projects with me screaming for diagrams and ended with (almost) all diagrams in trash cans and (almost) all descriptions in text.

Diagrams are great for teaching purpose, for presentation to peoples that anyway would undestand nothing and for child-toy projects. In real life (from my experience) the do not pay for yourself.

But this, really, does not belong to this thread and even to this forum.

Agreed, I'm not talking about ER diagrams as only documentation but ER designer tools as documentation managers - they allow you to add your free text comments to anything you want. You can always generate commented ddls from ER tools. You can not generate meaningfull ER diagrams from ddl.

[al0]

Agreed, I'm not talking about ER diagrams as only documentation but ER designer tools as documentation managers - they allow you to add your free text comments to anything you want. You can always generate commented ddls from ER tools. You can not generate meaningfull ER diagrams from ddl.

I (and my teams) have worked with them and have dropped them as absolutely unsatisfactory, their hottest proponents have completely resigned.

And yes, I can not generate meaningful ER diagrams from ddl, but I seriously doubt if such beast as "meaningful ER diagram" exists at all.

You know XP motto "code is a design". The same is applicable to the DB design.

And anyway those tools usually require some manual manipulation of generated scripts, as they do not support DBs 100% (a specially newest DB versions).

But to great extent it is matter of taste so no discussion point.

[dejanp]

You know XP motto "code is a design". The same is applicable to the DB design.

Yes, and I don't believe in XP.

But to great extent it is matter of taste so no discussion point.

Ok, agreed.