Binary database vs. Project database

As you know, 4D now supports two ways to work with sources: binary and project databases. Binary databases are the 4D we all know and love, with source code in a binary file to allow team development with 4D Server, and all of the design elements (methods, forms, structure, etc.) gathered in a single, compact binary file, the “.4db” file. Project databases make it easier for distributed teams to work collaboratively by storing the source code in a source control system in separate, plain text files. Projects will not replace the 4DB, we have no plans to make the 4DB disappear. It’s about two different ways of working and developing. It’s up to you to choose what best suits your needs. Here’s a blog post to help you decide:

Binary database (.4DB)

Pros

• Multi-user development

Multiple users can simultaneously develop and design a database. The integrity of your database design is preserved through a built-in object locking system.

• Work on the same version

The database is hosted on the 4D Server. All developers work on the same version of the code.

• Directly view the work of the other developers

You’re able to see the latest development of another developer without modifying it (e.g., to check the entry and exit points of a method that you’ll need to call in your part of the code).

• Built-in backup system

4D Server includes a complete database backup and restore module. This module lets you backup a database during operation, without having to exit it. Backups can be launched manually or automatically, at regular intervals, and without user intervention.

Cons

• Online

Requires permanent access to the server.

• Complicated rollback
  

Tagging a customer version and being able to return to this version in case of customer feedback can be a challenge.

• Compilation

Only one 4D client at a time can compile.

• Complicated to test in compiled mode

Must restart the server for testing, so all other developers are impacted.

• Difficult to manage multiple versions

No automatic merge of patches from one version to another. Requires a manual report: find the modified lines and then integrate them into the other version.

Project database (.4Dproject)

Pros

• Offline

Able to develop everywhere (e.g., at the office, when traveling, etc.).

• History

By storing in a source control system, the ability to follow the evolution of modifications is greatly simplified: the date, the author, and the modified lines.

• Rollback a development
  

If a new integration destabilizes your version, it’s easy to go back to a previous version.

• Multi-version development

Easy to merge patches from one version to another thanks to the branch system of a source control system.

• Compile anytime

Ability to compile and test in compiled mode without limitations.

• Enhanced feature set

Simplification of deployment for users and groups, improvement of style sheets thanks to CSS, and so on (Read the posts dedicated to project databases to discover all of the new possibilities).

Cons

• Development with distributed source code

Each developer codes alone on their copy of the code. Need for organization and rules to facilitate the sharing of work.

• Access to the code from a client is read-only

Able to test and debug in Client/Server, but it is not modify the deployed code on the server. You must reopen the database with 4D Developer, make the modification, and restart the server.

To conclude

Project databases open up new perspectives and offer another way to work with 4D. But keep in mind, there is no best way. You’re free to choose what best suits your needs.