Menu
I'm attempting to use Sparx Enterprise Architect to design a data model that will end up in a MySQL database.
My first approach was a Data Model diagram, which can be used to generate DDL (or the other way round by reverse engineering).
This works quite well but a colleague pointed out a snag: We're intending to use an ORM (almost certainly Hibernate) to map tables to Java classes. His comment was a "database first" approach would preclude the use of good OO techniques such as inheritance.
This seems a good point but I'm wondering if there are any limitations. If I started from scratch with a Class Diagram instead of a Data Model diagram, would there be a way of including all necessary Hibernate annotations, config etc. in this model? And if I later needed to model database-specific functionality such as constraints, triggers etc. would all this be possible in the model given that a Class Diagram isn't really aimed at this type of thing?
397
3)Database Version Control Versioning databases is hard, but with code first and code first migrations, it's much more effective. Because your database schema is fully based on your code models, by version controlling your source code you're helping to version your database.
What is the Difference Between Code First and Database First Approach in MVC. The main difference between code first and database first approach in MVC is that the code first allows the programmer to create entity classes with properties first, and then create the database and tables based on the defined entity classes ...
In code first approach we will first create entity classes with properties defined in it. Entity framework will create the database and tables based on the entity classes defined. So database is generated from the code. When the dot net code is run database will get created.
The only difference is that: using the designer you can do it graphically, and easyly set properties, column names, and so on. using Code First, you have to set these properties, columns names, data types and so on using conventions, Fluent API or attributes.
I prefer to model the database first. The database is the most valuable part of the business, the application logic being only an interface to manipulating the business data.
Since databases tend to outlive application technologies, it's better to design it upfront since the design is usually driven by data relationships and the data querying model.
Most ORMs were designed to model domain objects to existing schemas and it's the ORM tool task to cope with any possible DB schema mapping concerns.
For rapid prototyping, I might consider having my schema generating from the domain objects but when designing a large enterprise system architecture this approach is sub-optimal.
Hibernate only offers a limited number of DDL features and I don't like to loose extra DB specific features like PosgreSQL domains, instead-of triggers, materialized views or MySQL triggers.
A tool like Flyway is best to use to automate the schema migration process.
186
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
