For instance:

@Table(name = "stock", catalog = "mkyong", uniqueConstraints = {
@UniqueConstraint(columnNames = "STOCK_NAME"),
@UniqueConstraint(columnNames = "STOCK_CODE") })

or

@Column(name = "STOCK_NAME", unique = true, nullable = false, length = 20)

Constraints like 'unique', 'nullable', even area length are core database features. Why include this here? Also (even though this may hurt some) I'd also wager that the database's implementation of these constraints, particularly mainstream commercial DBs like Oracle, is most likely much better than regardless of the OSS Hibernate devs can develop.

Could it be smart to make use of this kind of stuff in Hibernate, or perhaps is it a much better practice to place constraints and the like within the database? It appears that the use of these Hibernate features, you are practically dealing with the database like a file system, so what is the point? Use of this really is everywhere but I have yet to obtain the documentation explaining why you'd do that.

It doesn't implement them - it's the choice to validate the information model from the schema, or create it.

The hibernate.hbm2ddl.auto configuration rentals are the one which enables you to definitely produce the schema in line with the mappings.

Instantly validates or exports schema DDL towards the database once the SessionFactory is produced. With create-drop, the database schema is going to be dropped once the SessionFactory is closed clearly.

e.g. validate update create create-drop

This is helpful, if you would like your computer data model to stay in the central place, as opposed to the database structure

Hibernate can produce a database schema according to individuals annotations for you personally.