Binäre Datenbank vs. Projektdatenbank

Wie Sie wissen, unterstützt 4D jetzt zwei Arten, mit Quellen zu arbeiten: binäre und Projektdatenbanken. Binäre Datenbanken sind das 4D, das wir alle kennen und lieben, mit Quellcode in einer binären Datei, um die Entwicklung im Team mit 4D Server zu ermöglichen, und allen Designelementen (Methoden, Formulare, Struktur usw.) in einer einzigen, kompakten binären Datei, der „.4db“-Datei. Projektdatenbanken erleichtern verteilten Teams die Zusammenarbeit, indem sie den Quellcode in einem Quellkontrollsystem in separaten, einfachen Textdateien speichern. Projekte werden die 4DB nicht ersetzen, wir haben nicht vor, die 4DB verschwinden zu lassen. Es handelt sich um zwei verschiedene Arbeits- und Entwicklungsmethoden. Es liegt an Ihnen, zu entscheiden, was Ihren Bedürfnissen am besten entspricht. Hier ist ein Blogbeitrag, der Ihnen bei der Entscheidung helfen soll:

Binäre Datenbank (.4DB)

Vorteile

  • Multi-User-Entwicklung

Mehrere Benutzer können gleichzeitig eine Datenbank entwickeln und entwerfen. Die Integrität Ihres Datenbankentwurfs wird durch ein eingebautes Objektsperrsystem gewahrt.

  • Arbeiten Sie mit der gleichen Version

Die Datenbank wird auf dem 4D Server gehostet. Alle Entwickler arbeiten an der gleichen Version des Codes.

  • Direkte Einsicht in die Arbeit der anderen Entwickler

Sie können die neueste Entwicklung eines anderen Entwicklers sehen, ohne sie zu verändern(z. B. um die Ein- und Ausstiegspunkte einer Methode zu überprüfen, die Sie in Ihrem Teil des Codes aufrufen müssen).

  • Eingebautes Backup-System

4D Server enthält ein komplettes Modul zur Sicherung und Wiederherstellung von Datenbanken. Mit diesem Modul können Sie eine Datenbank im laufenden Betrieb sichern, ohne sie verlassen zu müssen. Backups können manuell oder automatisch, in regelmäßigen Abständen und ohne Benutzereingriff gestartet werden.

Nachteile

  • Online

Erfordert permanenten Zugriff auf den Server.

  • Kompliziertes Rollback

Die Kennzeichnung einer Kundenversion und die Möglichkeit, im Falle von Kundenrückmeldungen zu dieser Version zurückzukehren, kann eine Herausforderung darstellen.

  • Kompilierung

Es kann jeweils nur ein 4D Client kompiliert werden.

  • Kompliziert zu testen im kompilierten Modus

Der Server muss zum Testen neu gestartet werden, so dass alle anderen Entwickler davon betroffen sind.

  • Schwierig, mehrere Versionen zu verwalten

Keine automatische Zusammenführung von Patches von einer Version zur anderen. Erfordert einen manuellen Bericht: Finden Sie die geänderten Zeilen und integrieren Sie sie dann in die andere Version.

Projektdatenbank (.4Dproject)

Vorteile

  • Offline

Möglichkeit, überall zu entwickeln(z.B. im Büro, auf Reisen, etc.).

  • Verlauf

Durch die Speicherung in einem Versionskontrollsystem wird die Möglichkeit, die Entwicklung von Änderungen zu verfolgen, stark vereinfacht: das Datum, der Autor und die geänderten Zeilen.

  • Rollback einer Entwicklung

Wenn eine neue Integration Ihre Version destabilisiert, ist es einfach, zu einer früheren Version zurückzukehren.

  • Entwicklung in mehreren Versionen

Dank des Verzweigungssystems eines Versionskontrollsystems lassen sich Patches leicht von einer Version in eine andere einfügen.

  • Jederzeit kompilieren

Kompilieren und Testen im kompilierten Modus ohne Einschränkungen.

  • Erweiterter Funktionsumfang

Vereinfachung der Bereitstellung für Benutzer und Gruppen, Verbesserung der Stylesheets dank CSS usw. (Lesen Sie die Beiträge über die Projektdatenbanken, um alle neuen Möglichkeiten zu entdecken).

Nachteile

  • Entwicklung mit verteiltem Quellcode

Jeder Entwickler kodiert allein an seiner Kopie des Codes. Es bedarf einer Organisation und Regeln, um die Arbeitsteilung zu erleichtern.

  • Der Zugriff auf den Code von einem Client aus ist nur lesend möglich

Sie können in Client/Server testen und debuggen, aber der Code auf dem Server wird nicht verändert. Sie müssen die Datenbank mit 4D Developer neu öffnen, die Änderung vornehmen und den Server neu starten.

Zum Schluss

Projektdatenbanken eröffnen neue Perspektiven und bieten eine weitere Möglichkeit, mit 4D zu arbeiten. Aber denken Sie daran, dass es keinen besten Weg gibt. Es steht Ihnen frei zu wählen, was Ihren Bedürfnissen am besten entspricht.

Vanessa Talbot
Product Owner - Vanessa Talbot kam im Juni 2014 zum 4D Programmteam. Als Product Owner ist sie für das Schreiben der User Stories und deren Umsetzung in funktionale Spezifikationen zuständig. Ihre Aufgabe ist es auch, sicherzustellen, dass die Implementierung der Funktionen den Anforderungen des Kunden entspricht. Seit ihrer Ankunft hat sie an der Definition der wichtigsten Funktionen in 4D gearbeitet. Sie hat an den meisten der neuen Funktionen für präemptives Multi-Threading gearbeitet und auch an einem sehr komplexen Thema: der neuen Architektur für erstellte Anwendungen. Vanessa hat einen Abschluss von der Telecom Saint-Etienne. Sie begann ihre Karriere am Criminal Research Institute als Entwicklerin für die audiovisuelle Abteilung. Sie hat auch in den Bereichen Medien und Medizin als Expertin für technischen Support, Produktion und die Dokumentation neuer Funktionen gearbeitet.