5

A lot of projects have a to be determined database model during early development. This could mean that a lot of SQL will have to be rewritten frequently. What is the recommended strategy to deal with this? Especially when you want to develop your application RAD-like and with the ultimate requirements not being set in stone at all? Mostly toy projects.

An ideal scenario would be that I can just not write any SQL at all at the start of the project, and only when the data model is more solidified, actually set up the database for the project and write SQL for it. During the initial development phase I just want to be able to alter my entity classes, without having to change my SQL over and over again.

(For the project I'm asking this, I'm working with Spring 4 and a MySQL database)

Kristof
  • 2,201
  • 3
  • 14
  • 13

2 Answers2

4

The technique we're using on my current project (which will probably work for you) is to use Liquibase. All database changes are made via configuration files, which are checked in to source control and run automatically at application startup. This helps to keep your database schema in sync with the code -- whenever you pull the latest revision to your branch, you get the latest database configuration with it. It gets a little cumbersome if you do much more than add tables or columns, but IME most of the changes made during new system development are just that.

I believe there are several other "code first"-style ORM products out there, but this is the only one I'm really familiar with. Well, that and the .NET Entity Manager, but since you're using Spring 4 I assume you're working with Java. Be aware that other code-first solutions may require you to entirely drop and re-create your database when the schema changes. Usually this isn't a problem during early development, but can become a hassle later on.

TMN
  • 11,313
  • 1
  • 21
  • 31
  • what happens when you revert your code and it deletes tables/columns (and hence the data)? Do you have to recreate/restore that data later, when you revert back to the latest version? – Dennis Dec 28 '16 at 18:20
  • 1
    Typically you wouldn't delete anything. It's not a problem because your older code won't reference any of the new tables/columns, so it doesn't matter if they're there or not. If you're going back several versions, it's usually a good idea to make a backup of the current database, then do whatever is necessary to make the old code work. Once you're ready to roll back to the current code, just restore your backup. – TMN Dec 28 '16 at 18:32
0

I prefer to work in vertical slices of functionality rather than keep the whole data layer uninmplemented until the end.

A lot of ORMs have a database generation feature. It doesn't need to be sophisticated and support DB schema diffs, since in development you often don't really care about your data and don't mind recreating the DB from scratch. However, that can be a nice asset for the future when your application goes in maintenance mode.

guillaume31
  • 8,358
  • 22
  • 33