Base de données binaire vs. base de données de projet

Traduit automatiquement de Deepl

Comme vous le savez, 4D prend désormais en charge deux façons de travailler avec les sources : les bases de données binaires et les bases de données de projet. Les bases de données binaires sont le 4D que nous connaissons et aimons tous, avec le code source dans un fichier binaire pour permettre le développement en équipe avec 4D Server, et tous les éléments de conception (méthodes, formulaires, structure, etc.) rassemblés dans un seul fichier binaire compact, le fichier « .4db ». Les bases de données de projets facilitent le travail collaboratif des équipes distribuées en stockant le code source dans un système de contrôle de la source dans des fichiers séparés en texte brut. Les projets ne remplaceront pas la 4DB, nous n’avons pas l’intention de faire disparaître la 4DB. Il s’agit de deux façons différentes de travailler et de développer. C’est à vous de choisir ce qui convient le mieux à vos besoins. Voici un article de blog pour vous aider à décider :

Base de données binaire (.4DB)

Pour

  • Développement multi-utilisateurs

Plusieurs utilisateurs peuvent développer et concevoir une base de données simultanément. L’intégrité de la conception de votre base de données est préservée grâce à un système intégré de verrouillage des objets.

  • Travaillez sur la même version

La base de données est hébergée sur le serveur 4D. Tous les développeurs travaillent sur la même version du code.

  • Visualisez directement le travail des autres développeurs

Vous pouvez voir le dernier développement d’un autre développeur sans le modifier(par exemple, pour vérifier les points d’entrée et de sortie d’une méthode que vous devrez appeler dans votre partie du code).

  • Système de sauvegarde intégré

4D Server comprend un module complet de sauvegarde et de restauration de la base de données. Ce module vous permet de sauvegarder une base de données en cours de fonctionnement, sans avoir à la quitter. Les sauvegardes peuvent être lancées manuellement ou automatiquement, à intervalles réguliers, et sans intervention de l’utilisateur.

Inconvénients

  • En ligne

Nécessite un accès permanent au serveur.

  • Retour en arrière compliqué

Marquer une version client et pouvoir revenir à cette version en cas de retour du client peut être un défi.

  • Compilation

Un seul client 4D à la fois peut compiler.

  • Compliqué de tester en mode compilé

Doit redémarrer le serveur pour les tests, donc tous les autres développeurs sont impactés.

  • Difficile de gérer plusieurs versions

Pas de fusion automatique des correctifs d’une version à l’autre. Nécessite un rapport manuel : trouver les lignes modifiées puis les intégrer dans l’autre version.

Base de données du projet (.4Dproject)

Pour

  • Hors ligne

Possibilité de développer partout(par exemple, au bureau, en voyage, etc.).

  • Historique

En stockant dans un système de contrôle de source, la possibilité de suivre l’évolution des modifications est grandement simplifiée : la date, l’auteur, et les lignes modifiées.

  • Rollback d’un développement

Si une nouvelle intégration déstabilise votre version, il est facile de revenir à une version antérieure.

  • Développement multi-version

Il est facile de fusionner les correctifs d’une version à l’autre grâce au système de branches d’un système de contrôle des sources.

  • Compilation à tout moment

Possibilité de compiler et de tester en mode compilé sans limitations.

  • Ensemble de fonctionnalités améliorées

Simplification du déploiement pour les utilisateurs et les groupes, amélioration des feuilles de style grâce aux CSS, etc. (Lisez les billets consacrés aux bases de données des projets pour découvrir toutes les nouvelles possibilités).

Contre

  • Développement avec un code source distribué

Chaque développeur code seul sur sa copie du code. Nécessité d’une organisation et de règles pour faciliter le partage du travail.

  • L’accès au code depuis un client est en lecture seule

Possibilité de tester et de déboguer en Client/Serveur, mais il ne s’agit pas de modifier le code déployé sur le serveur. Vous devez rouvrir la base de données avec 4D Developer, effectuer la modification et redémarrer le serveur.

En conclusion

Les bases de données de projet ouvrent de nouvelles perspectives et offrent une autre façon de travailler avec 4D. Mais gardez à l’esprit qu’il n’y a pas de meilleure façon. Vous êtes libre de choisir ce qui convient le mieux à vos besoins.

Vanessa Talbot
- Product Owner -Vanessa Talbot a rejoint l'équipe du programme 4D en juin 2014. En tant que Product Owner, elle est chargée de rédiger les user stories puis de les traduire en spécifications fonctionnelles. Son rôle est également de s'assurer que l'implémentation des fonctionnalités livrées répond aux besoins des clients.Depuis son arrivée, elle a travaillé à la définition des fonctionnalités clés de 4D. Elle a travaillé sur la plupart des nouvelles fonctionnalités de multithreading préemptif et aussi sur un sujet très complexe : la nouvelle architecture pour les applications enginées. Vanessa est diplômée de Telecom Saint-Etienne. Elle a commencé sa carrière à l'Institut de Recherche Criminelle en tant que développeur pour le département audiovisuel. Elle a également travaillé dans les domaines des médias et du médical en tant qu'experte en support technique, en production ainsi qu'en documentation de nouvelles fonctionnalités.