I was developing my ORM and I found the next problem, should I allow code first or not? And it was my conclusion.

What is Code First anyways?

When we want to use an ORM (Object Relational Model) in our code, we have the next options:

• Create the database, then create the code and make it both work in synchronization. It is really prone to mistakes, for example, the code could understand that the "id" field is an int, and the database understands that the column "id" is an integer, but depending on the engine, it could not be completely exact and maybe the field "id" must be a long.

• Create the database, then self-generate the code that matches the database. It is called "Database First".

• Create the code, then it will create the database. It is called "Code First".

When we create code first, then the code is in charge to determine how the database will be created and populated.

For example, let's assume the next pseudo-code:

{
   "table":"Customers"
    ,"fields":[
         "id":"int"
         ,"name":"string"
         ]
}

This code will assume that we need to create a table called customer with two fields.

So, we run the generation of the database, and it will build the database, i.e. We are reinventing the wheel!!.

Now, let's say that the table is more complex.

A table could contain the next "components"

• the definition of the table

  • and it could contain a lot of stuff, from the tablespace, the type of database, etc.

• fields

  • And depending on the field, it could contain, validations, default value, auto-generate value, and several other definitions.

• indexes

• keys

• etc.

Some ORM allows a fine-grained definition of the database but it still could miss a lot of definitions (because the ORM is a generation of many databases, or it is compatible with some older version, etc.). But even if we could generate our definition in code, the task could be in some cases overwhelming. Most code-first code simply left the basic definition.

So, what is the alternative?

Database-First

Why? Simple, because most databases are harden-tested to do exactly that task. Do you want a GUI? well, there are many tools that do that.

Do you want to code, then SQL is decades old (and SQL is "standard").

CREATE TABLE `malibu`.`Customers` (
  `id` INT NOT NULL,
  `Name` VARCHAR(45) NULL,
  PRIMARY KEY (`id`));

There are some problems with Database-First but they have a solution

• Updating the database. If we change the database, then our code will need to be recreated. It is not a big deal since most of the code that we need to update is generated automatically.

• Code-first gives more control to the developer. That is true and false. True because it allows more customization on the side of the code. But false because the database does not change and finally the database is who does the job.

Let's say our database has a foreign key between two tables.

The database understands the concept of foreign keys, and "one to many" and "many to one" relations. But in code, we could understand more concepts such as "one to one", "many to many" and others.

However, the problem is not because database but the lack of some tools that convert the database into code and it doesn't allow configuring it manually.

So, the best of all worlds is Database-First AND a proper tool that does not simply take the database and creates the code but also allows some kind of customization.