Ist das kontinuierliche Erstellen und Löschen von Tabellen ein Zeichen für einen Architekturfehler?

Kürzlich hatte ich eine Diskussion mit einem Entwickler, der erwähnte, dass während der Programmentwicklung regelmäßig Tabellen und Spalten regelmäßig erstellt und gelöscht werden, während an neuen Funktionen gearbeitet und begründet wird, dass dies bei Verwendung eines agilen Entwicklungsprozesses normal ist.

Da sich der größte Teil meines Hintergrunds in einer Wasserfallentwicklungsumgebung befindet, frage ich mich, ob dies in der agilen Entwicklung tatsächlich als richtig angesehen wird oder ob dies ein Zeichen für ein zugrunde liegendes Problem sein könnte, entweder mit der Programmarchitektur oder mit der Verfolgung des agilen Prozesses.

Es wird mir von Tag zu Tag klarer, dass "agil" zu einem Synonym für schlecht durchdachte, chaotische, eilige und hängende Hosen wird. Und keines dieser Dinge ist mit einem agilen Ansatz kompatibel, wie ich ihn verstehe.

Ein effektiver und wiederholbarer agiler Prozess ist nicht einfach, und ich glaube nicht, dass er den Gesamtaufwand für die von Natur aus zu erledigende Arbeit von Natur aus reduziert, obwohl dies sehr wohl zu besseren Produkten führen kann.

Wenn sie gesagt haben, dass sie keine Zeit haben, die Datenbank "umzugestalten", haben sie wahrscheinlich auch keine Zeit, die Versionierung und Migration für die Datenbank einzurichten. Sie haben sich wahrscheinlich nicht die Zeit genommen, eine Reihe von Funktionstests dafür zu erstellen. All diese Dinge sind das, woran ich denke, wenn ich an einen soliden agilen Prozess denke, der auf Erfolg zusteuert.

Am Ende ist Agile nur ein Wort. Was Sie täglich tun, entscheidet darüber, ob Sie erfolgreich sind oder nicht.

Während es nicht ungewöhnlich ist, Tabellen zu erstellen und zu löschen, während sich ein Design weiterentwickelt, kann eine Bereinigung durchgeführt werden, um sicherzustellen, dass Ihre Datenbank wirklich alle diese Tabellen verwendet.

Ja, bei Agile dreht sich alles um Refactoring, aber wenn sie jetzt sagen, dass das System zu groß für Refactoring ist, haben sie Agile eingestellt und programmieren jetzt nur noch Cowboy. Das Entwicklungsteam wird es nicht mögen, so genannt zu werden, aber genau das tun sie. Fahren Sie auf der Strecke und schießen Sie alles, was sich bewegt.

Ein DBA hilft, stellen Sie einfach sicher, dass Sie einen DBA erhalten, der sowohl die Entwicklung als auch die agile Entwicklung versteht. Ihr Entwicklungsteam muss eingeschränkt und nicht ins Gefängnis geworfen werden.

Im Allgemeinen ist das Erstellen neuer Tabellen und das Hinzufügen neuer Spalten in einem Prozess, in dem Programmierung und Datenbankverwaltung nicht streng voneinander getrennt sind, sehr normal. Eine neue Funktion kann neue Daten erstellen, die irgendwohin müssen. Versuchen Sie zu streng, dies zu vermeiden, und Sie erhalten ein Modell für die innere Plattform .

Gut geschriebene Software bemerkt diese neuen Datenbankobjekte kaum, sodass nur aufgrund einer neuen Spalte in einer Tabelle nichts kaputt geht.

Andererseits ist das regelmäßige Löschen von Spalten oder sogar Tabellen verdächtig. Bei einer neuen Funktion muss niemals eine Tabelle entfernt werden. Dies kann ein Zeichen dafür sein, dass Personen völlig planlos arbeiten.

Wenn Ihre Datenbank einfach versioniert und migriert werden kann und Sie die Tests haben, um zu beweisen, dass das Ändern von Dingen die Dinge nicht kaputt gemacht hat, dann haben Sie wahrscheinlich einen ziemlich agilen Prozess in Gang gebracht.

In Anbetracht der Kommentare - im Allgemeinen sind dies einige Cowboys, die sich als agil rechtfertigen - schreiend. Schnell. Und poste alles, was du kannst, auf thedailywtf.com, damit wir alle deinen Horror genießen können.

Wie die meisten Antworten hier auf StackExchange sollte die Antwort "es kommt darauf an" lauten. In der agilen Entwicklung werden Anforderungen und Spezifikationen während der Implementierung ermittelt.

Angesichts der agilen Entwicklung sollte das Hinzufügen neuer Attribute zu Beziehungen jedoch selten eine Notwendigkeit sein, wenn ein relationales Modell ordnungsgemäß normalisiert ist. Neue Entitäten sollten sich bei einem geeigneten Modell im Allgemeinen auf ältere beziehen .

Die meisten Entwickler normalisieren ihre DBs aufgrund von Zeitbeschränkungen, Faulheit, Inkompetenz oder Abfragekomplexität nicht. Die Renormierung erfordert die Übertragung vorhandener Daten, die Änderung der DAOs usw. usw., wodurch ein Risikofaktor entsteht.

Um Ihre Frage zu beantworten, nein, das ist in einem agilen Prozess nicht normal.

Wo es auf eine agile Haltung zurückzuführen zu sein scheint , liegt in Agiles Design- / Entwicklungs- / Testzyklus mit kurzer Iteration und in Agiles Schwerpunkt auf leichten Lösungen, die die bekannten Anforderungen erfüllen, aber gut strukturiert sind, um neue Anforderungen erfüllen zu können minimale Änderung. Angesichts dieser beiden Dinge könnte man sagen, dass ein Entwickler, der nicht weiß, was auf der ganzen Linie kommen könnte, aber weiß, dass seine Änderung die Datenbank nicht auf eine Weise beeinflussen sollte, die nicht rückgängig gemacht werden kann, einfach die erforderlichen Änderungen am Schema in der Datenbank vornimmt "leichtester" Weg möglich, und dann werden in Abständen mehrere Sätze von "leichten" Änderungen in etwas dauerhafteres und stabileres umgestaltet.

Trotzdem habe ich noch nicht mit einem Entwickler zusammengearbeitet, der sich der Theorie und Methodik von Agile angeschlossen hat, und dachte auch, dass das routinemäßige Erstellen und Löschen von Tabellen im Schema aus irgendeinem Grund notwendig ist. Agil bedeutet nicht Slap-Dash oder Bolt-On. Wenn Sie eine Story erhalten, für die ein neues Datenfeld zu einem bestimmten Datensatz hinzugefügt werden muss, fügen Sie das Feld der Tabelle hinzu. Wenn diese Änderung etwas kaputt macht, finden Sie heraus, warum und nehmen gegebenenfalls andere Änderungen vor (ich kann mir nur sehr wenige Dinge vorstellen, die durch Hinzufügen einer Spalte zu einer abgefragten Datenbank kaputt gehen würden; wenn sie mit dieser Art von Änderung bricht, werden Sie größere Probleme haben). Refactoring ist normalerweise auf Code beschränkt. Das Ändern des Schemas ist normalerweise ein aufwändigerer Prozess als das Ändern des Codes. Wenn also Schemaänderungen vorgenommen werden müssen, werden diese normalerweise mit größerer Sorgfalt vorgenommen. und zumindest ein wenig Aufmerksamkeit auf die Kenntnis der zukünftigen Richtung des Projekts. Die Notwendigkeit, einen Teil oder die gesamte Datenbank neu zu strukturieren, weist auf einen grundlegenden Entwurfsfehler hin. Agilität bedeutet nicht, dass es keinen "Masterplan" für grundlegende Architektur- und Entwurfsregeln gibt, der beim organischen Aufbau des Programms und der Datenstruktur befolgt werden muss.

Nun, es gibt Fälle in Agile, in denen das, was Sie jetzt "wissen", dem widerspricht, was Sie später lernen werden. Angenommen, Sie haben eine Anforderung, dass Ihr System für jede Person eine Adresse haben muss. Da es sich um eine 1: 1-Beziehung handelt und die Daten in den meisten Fällen benötigt werden, fügen Sie einfach die Adressfelder zur Personentabelle hinzu. Eine Woche später erhalten Sie die Anforderung, dass eine Person mehr als eine Adresse haben kann. Jetzt handelt es sich um eine 1: N-Beziehung. Um sie richtig zu modellieren, müssen Sie Ihre vorherigen Änderungen rückgängig machen und die Felder in eine neue Adresstabelle aufteilen. Dies ist keine Routine, insbesondere bei erfahrenen Entwicklern. Ein erfahrener Entwickler wird feststellen, dass eine Person eine Adresse hat, diese als konzeptionell getrennt betrachten und eine Personentabelle und eine Adresstabelle erstellen, die Person mit Adresse mit einem FK-Verweis auf eine Adress-ID verknüpft. Ein solches Schema lässt sich leichter ändern, wenn sich die Art der Beziehung ändert. Ohne ganze "breite" Datentabellen zu erstellen oder zu löschen, kann die Beziehung zwischen Person und Adresse ziemlich einfach von 1: 1 auf 1: N auf N: N geändert werden.

Bei der Arbeit unter Agile wird nicht so viel Wert auf Design gelegt, daher sehe ich dies nicht als großes Problem an, sicherlich nicht für die erste Veröffentlichung.

Es ist schwer, ein System mit 700 Tabellen zu kommentieren, die ich nicht gesehen habe. Möglicherweise werden alle benötigt, aber es kann auch vorkommen, dass die Datenbank nicht gut genug verwaltet wird.

Selbst unter Agilität ist es für ein großes System durchaus üblich, dass immer noch jemand / ein Team für das Schema verantwortlich ist.

Wenn sie solche Änderungen häufig vornehmen - insbesondere das Löschen von Tabellen und Spalten in Live-Anwendungen -, scheint dies ein Zeichen für Unerfahrenheit zu sein. Es hat nichts mit dem Prozess zu tun, den sie zu befolgen behaupten. 'Agil' ist keine Entschuldigung dafür, sich nicht hinzusetzen und über die Daten nachzudenken, die Sie speichern müssen, und wie sie sich darauf beziehen, bevor Sie anfangen, Code herauszuschlagen. Wenn sie feststellen, dass sie mehr als 10 bis 20% der ursprünglichen Struktur verändern, ist dies für mich ein Indikator, den sie entweder nicht durchdenken oder sie haben nicht viel Erfahrung darin, Anforderungen zu analysieren und Datenbanken zu entwerfen, und sie bekommen es einfach auch viel davon am Anfang falsch.

Während es so klingt, als ob Ihr Team in der Tat nur Cowboy-Codierung ist, sollte es wirklich nichts Falsches sein, Code ODER Datenbanken umzugestalten. Es ist keine verlorene Arbeit - es passt sich einer neu erlernten Realität an.

Ich würde vorschlagen, dass das Team eine Sandbox benötigt, um Änderungen auszuprobieren, einige Tests durchzuführen, sie von den Benutzern abzuprallen und zu entscheiden, ob sie sinnvoll sind. Zu diesem Zeitpunkt sollte es in Ordnung sein, die sinnvollen Änderungen - mit angemessenen Regressionstests - in Ihr Schema zu integrieren.

Bei Agile geht es um Codierung, Datenbanken sind kein Code. Das Ändern einer Datenbank sollte wie das Umbauen eines Hauses behandelt werden. Die Leute haben irgendwie den Glauben bekommen, dass agile Mittel handeln, um später zu planen, was völlig falsch ist. Auch bei agilen Methoden muss Zeit für die Planung eingeräumt werden, insbesondere für etwas so Wichtiges wie das Datenbankdesign.

Mein letzter Job war in einem solchen Team. Bei Verwendung eines agilen Prozesses ändern sich die Anforderungen. Manchmal bedeuten die Änderungen, dass eine vorhandene Entität ein neues Attribut benötigt, was zu einer neuen Spalte in einer vorhandenen Tabelle führt, oder dass eine ganz neue Entität erforderlich ist, was zu einer neuen Tabelle mit Beziehungen zu vorhandenen Tabellen führt. Diese Art von Änderungen hängt vom Gebiet ab und kann nicht ignoriert werden, nur weil Sie das Schema nicht berühren möchten. Der Erfolg wird durch die Aufrechterhaltung der Integrität Ihrer Daten bei der Migration von einer Datenbankversion zur nächsten und durch ordnungsgemäße Komponententests bestimmt.

Versuchen Sie einfach, keine unnötigen Änderungen an Ihrem Schema vorzunehmen. Wenn für eine Funktion beispielsweise eine neue Tabelle erstellt werden muss, stellen Sie sicher, dass Sie mit der Definition dieser Tabelle zufrieden sind, bevor Sie sie einchecken und in Ihrer Testumgebung bereitstellen. Das Rückgängigmachen einer Änderung an Ihrem Datenbankschema nach der Migration Ihrer Daten kann schmerzhaft sein.