Jede SQL-Anweisung muss von einem DBA überprüft werden - gemeinsam?

Ich meine alles, nicht nur Schemaänderungen. Selbst ein einfaches SELECT für einen Primärschlüssel kann nicht in die Produktion gehen, obwohl es von anderen Entwicklern (im Kontext) ohne eine DBA-Überprüfung jeder Anweisung, aus dem Code extrahiert und mit EXPLAIN-Ausgabe, Details, übermittelt wurde wie oft es aufgerufen wird, etc, etc.

Wenn Sie in einer solchen Umgebung waren, haben Sie festgestellt, dass dies ein Nettogewinn oder eine Belastung für die Entwicklung ist? Als jemand, der seit Jahren mit relationalen Datenbanken arbeitet, finde ich die Einstellung "Entwicklern kann nicht vertraut werden, Datenbanken zu verwenden" nicht gerechtfertigt, und ich bin gespannt, wie häufig diese Situation ist. Für das, was es wert ist, ist dies nur für die Webentwicklung, nicht etwas Kritisches.

Bei einem meiner vorherigen Jobs war ich (zusammen mit drei anderen Programmierern) dafür verantwortlich, jede gespeicherte Prozedur zu überprüfen, die erstellt oder aktualisiert wurde, bevor sie für mehr als 40 Programmierer in Produktion ging. Als Rezensent war es eine echte Belastung für meine Zeit, aber insgesamt war es immer noch nötig, da so viele Entwickler hin und wieder einen Fehler machen werden. Es kam zustande, weil wir Offshore-Programmierer hatten, die wirklich schlechte (effiziente) SQL-Anweisungen geschrieben hatten und sich rundweg weigerten zu lernen (dieses Team wurde schließlich geschlossen).

Insgesamt haben wir gesucht:

• Indexverwendung - Hat die Abfrage einen vollständigen Tabellenscan durchgeführt?
• Wartbarkeit - musste die Abfrage in ein paar Wochen geändert werden, weil etwas fest darin codiert war? Und ist die Abfrage lesbar?
• Gesamteffizienz - könnte eine innere Verbindung durch eine vorhandene ersetzt werden? Würde das Hinzufügen eines With-Blocks helfen?
• Probleme beim Sperren - Würde die Abfrage die Datenbank sperren und Aktualisierungen verhindern? Dies geschah mehr als ich denken möchte.

Meistens hatten die meisten Anfragen keine Probleme und wir haben sie weiter vorangetrieben. Jede Überprüfung dauerte jedoch je nach Abfrage zwischen 10 Minuten und zwei Stunden. Ein Teil von mir mochte die Idee, Überprüfungen durchzuführen, weil sie den gefürchteten Anruf um 2 Uhr morgens verhinderte, weil ein Bericht ein Problem mit einer anderen Anwendung verursachte. Gleichzeitig dachte ich, es sei ein bisschen übertrieben, weil wir alle erwachsen sind und die Person, die die Anfrage schreibt, all das selbst machen sollte.

Ich denke, komplexe Abfragen sollten Teil der Standard-Codeüberprüfung sein, müssen aber keinen DBA durchlaufen. Es ist auch nicht erforderlich, einfache Anweisungen zum Einfügen / Aktualisieren / Löschen zu überprüfen. Darüber hinaus sollten Sie als Verfasser einer Abfrage wissen, wann sie zu komplex geworden ist und wann Sie eine Überprüfung von einem DBA anfordern müssen.

Update In meinem allerersten Job wurden alle Abfragen von Datenbankadministratoren geschrieben, und das war ein großer Zeitkiller für die Entwicklung. Ich musste alle gewünschten Spalten einreichen, Tabellen, in denen sich die Spalten befanden, und schließlich meine Suchkriterien. Selbst grundlegende Anweisungen zum Einfügen / Aktualisieren / Löschen sind erforderlich, um einen DBA zu durchlaufen. Irgendwann kam ich an den Punkt, an dem ich das gewünschte SQL schreiben, es mir ansehen und alle erforderlichen Änderungen vornehmen und dann eine gespeicherte Prozedur darum wickeln konnte, aber das war nur ein paar Jahre her. Diese spezielle Firma stellte viele neue College-Absolventen ein und auf diese Weise stellten sie sicher, dass die neuen Leute keine Anfragen schrieben, die die Leistung beeinträchtigten.

Es kommt ganz auf die Umwelt, die Branche und das Unternehmen an.

Einige Beispiele:

• Bei der NASA sind mehrere Ebenen der Überprüfung und Überprüfung der Standard. Das bekannteste "hätte doppelt geprüft werden müssen" war, als eine Sonde zum Mars geschickt wurde und die USA Berechnungen in Fuß durchführten, die Europäer jedoch in Metern. Die Sonde ging verloren.

• Bei einem Startup ohne DBA (heutzutage üblich) gibt es keine DBA-Überprüfung und möglicherweise sogar keine Programmiererüberprüfung (z. B. wenn keine anderen Programmierer im Unternehmen vorhanden sind).

• In einem Unternehmen, dessen Produkt ein Data Warehouse mit Hunderten von Millionen Zeilen ist, kann die Sicherstellung, dass Abfragen effizient und korrekt sind, ein zentrales Thema im Kern des Geschäfts sein, das überprüft werden sollte.

Ein Unternehmen, dessen Hauptprodukt eine hauptsächlich statische Website mit einer geringen Anzahl von Datenbankinteraktionen ist, kann die Datenbank und ihre Effizienz als weniger relevant betrachten. Es kann sein, dass das Unternehmen sein Überprüfungsbudget für die statischen Seiten ausgibt, die als am kritischsten angesehen werden.

Ich habe noch nie in einer solchen Umgebung gearbeitet, ich bin sicher, ich würde es hassen. Es kommt mir der Gedanke, einige Kennzahlen zu verfolgen ...

• Wie viel Zeit verbringt ein Entwickler damit, SQL aus dem Code zu ziehen und es für die Übermittlung an einen DBA vorzubereiten?
• Wie lange dauert es, bis der DBA die SQL überprüft?
• Wie oft werden vom DBA Änderungen angefordert? Aufgeschlüsselt nach Abfragetyp
  ?

Wenn Sie dies nur für eine kurze Zeit verfolgen, wird dies wahrscheinlich zeigen, wie stark der Widerstand ist und wie effektiv er ist.

Die meisten Entwickler sind absolut unwissend, wenn es um Datenbanken geht. Sie sind sich ihrer Unwissenheit nicht einmal bewusst. Ich war selbst ein ignoranter Entwickler.

Entwickler leben in einer Welt, in der Optimierung böse ist. Diese Einstellung funktioniert nicht, wenn Sie Vorgänge für eine Festplatte ausführen. Diese Einstellung funktioniert nicht, wenn Sie einen Datentyp auswählen, der achtmal größer ist als er sein muss, was dazu führt, dass der Index achtmal größer ist als er sein muss, sodass er nicht mehr in den Speicher passt. Diese Einstellung funktioniert nicht, wenn Sie gegen eine generische API programmieren, die alle Spalten in einer Tabelle redundant aktualisiert (nein, danke Java Beans).

Sie wissen nicht, was ein vollständiger Tabellenscan ist. Sie wissen nicht, wie Daten in einem einzigen Satz verarbeitet werden sollen, anstatt einen Cursor zu öffnen. Schlimmer als ein Cursor fragen sie Daten ab und verarbeiten sie dann zeilenweise hin und her zur Datenbank, wenn ein einzelnes einfaches Jane-Update ausreichen würde. Das Ergebnis ist eine schreckliche Leistung.

Sie kennen die schwerwiegenden Auswirkungen der Berichterstellung für große Tabellen nicht. Möglicherweise müssen für die Erstellung von Berichten ein Sternschema und ein Datenfeed erstellt werden. Ihr durchschnittlicher Entwickler fragt nur die vorhandenen Tabellen ab und fragt sich, warum die Ausführung der Abfrage 3 Stunden dauert (dies ist eine echte Zahl).

Das Wissen, über das Ihr durchschnittlicher Entwickler verfügt, reicht für "durchschnittliche" CRUD-Apps aus, bei denen ein Benutzer einfach einen Datensatz bearbeitet. Es wird nicht ausreichen, wenn sie aus der Ruby-on-Crack-Blase in die reale Welt ausbrechen.

Hängt davon ab, wie groß die Datenbank ist und ob sie von mehreren Anwendungen gemeinsam genutzt wird. Oft möchte das DBA-Team wissen, welche Abfragen ausgeführt werden, um sicherzustellen, dass die richtigen Indizes vorhanden sind, oder um zu wissen, wen es benachrichtigen muss, wenn eine Tabelle partitioniert werden muss. Und sie sind in der Regel etwas besser als der durchschnittliche Entwickler beim Lesen von Abfrageausführungsplänen und beim Erkennen von Stellen, an denen Hinweise zur Verbesserung der Leistung angegeben werden könnten. Es ist auch eine Chance für sie, sich ein Bild davon zu machen, dass in der nächsten Version einige wichtige Abfragen auftauchen werden, damit sie verschiedene Statistiken für den Optimierer sammeln können.

Ich habe weder in einer solchen Umgebung gearbeitet, noch würde ich.

Es gibt einen Unterschied zwischen Teamwork und feindlicher Bürokratie. Als Entwickler würde ich gerne DBA-Input für schwierige Abfragen haben. Aber ich weiß, wann ich um Hilfe bitten muss.

Wenn ich für einfache SELECTFragen nicht kompetent genug bin , sollte ich entlassen werden.

Ich habe das an verschiedenen Orten gesehen. Theoretisch ist es großartig, aber ich habe selten gesehen, dass es effektiv ist. Hier ist der Grund. Erstens, wenn Sie ein Team von Datenbankadministratoren (oder anderen Personen) haben, habe ich im Allgemeinen festgestellt, dass die am wenigsten kompetente oder am wenigsten geliebte Person der Gruppe die Hauptlast der Überprüfungsarbeit erhält. Warum sagst du? Das liegt daran, dass niemand anderes es tun möchte und alle anderen damit beschäftigt sind, andere Dinge zu tun, die wahrscheinlich dringlicher sind. Ich habe jemals einen DBA gesehen, der herumgesessen hat und gesagt hat: "Mann, alles läuft perfekt. Ich kann mich einfach zurücklehnen und im Internet surfen. Ich wünschte, ich hätte etwas zu tun." Ich auch, zumindest nicht die Guten. Sie sind genauso beschäftigt oder geschäftiger als alle anderen. Dies bedeutet, dass die Person, die am wenigsten fähig ist, höchstwahrscheinlich die Überprüfung durchführt, und dies ist genau die Person, die Sie nicht möchten. Der Code, den Sie überprüfen möchten, ist der wirklich sehr harte Code, den die Leute betrachten und als eine Art schwarze Magie ausgeben. Junior-Datenbankadministratoren oder einfach nur schlechte DBAs werden niemals in der Lage sein, die Feinheiten der Funktionsweise einer wirklich harten Abfrage zu erfassen. Selten, wie nie, sagt jemand jemals: "Mann, ich habe nicht daran gedacht, eine einzelne Zeile aus einer Tabelle mit dem Primärschlüssel auszuwählen! Danke, DBA, du bist ein Lebensretter." In diesem Szenario schaffen Sie also wirklich nur viel Arbeit für wenig Wert. Denken Sie nicht daran, mit dem Primärschlüssel eine einzelne Zeile aus einer Tabelle auszuwählen! Dank DBA sind Sie ein Lebensretter. "In diesem Szenario schaffen Sie also wirklich viel Arbeit für wenig Wert. Denken Sie nicht daran, mit dem Primärschlüssel eine einzelne Zeile aus einer Tabelle auszuwählen! Dank DBA sind Sie ein Lebensretter. "In diesem Szenario schaffen Sie also wirklich viel Arbeit für wenig Wert.

Zweitens ist es einfach mehr Arbeit für die DB-Gruppe. Was wahrscheinlich passieren wird, selbst wenn sie sich andere Dinge ansehen, ist, dass sie einen kurzen Blick darauf werfen und etwas übersehen wird. Sie sind vielbeschäftigte Leute, und das Überprüfen von Code ist sehr zeitaufwändig. In Wahrheit ist es nicht fair, dass sie damit beauftragt werden, denn es ist eine Ausrede für alle anderen, faul zu sein und sie als Out zu benutzen, was letztendlich passiert. In der Produktion bricht etwas zusammen, und der Entwickler weist schnell darauf hin: "Nun, der DBA hat es überprüft." Jetzt ist dies die ganze Zeit wahr, nein, aber es ist ein Teil der Zeit und oft von den Leuten, die ihren Code wirklich überprüfen lassen müssen. Sie haben also den DBA mit zusätzlicher Arbeit begraben und diese Person gezwungen, für die Fehler einer anderen Person verantwortlich zu sein, wenn diese Person dies wahrscheinlich nicht tut.

Die einzige Möglichkeit, das Problem wirklich zu lösen, besteht darin, dass Leute, die wissen, wie man SQL-Code schreibt, ihn schreiben. Sollten sie von Zeit zu Zeit Eingaben von den Datenbankadministratoren erhalten? Natürlich sollten sie das, aber ich habe immer festgestellt, wenn Sie beim ersten Mal keine Zeit haben, es richtig zu machen, wann werden Sie Zeit finden, es zu beheben.

Ich habe in einer solchen Umgebung gearbeitet. Alle Systemänderungen wurden von geeigneten Peers begutachtet. Für mich bedeutete das nur, dass ich einige Tage im Voraus planen und meine Änderungen einreichen musste. SQL ging an die Datenbankadministratoren, die das SQL letztendlich für die Produktion freigeben würden.

Mein SQL ist normalerweise in Ordnung, sie haben ein paar dumme Fehler entdeckt. Es fühlt sich anfangs zu bürokratisch an, aber ich arbeite im Finanzbereich. Sie haben vor einigen Monaten gesehen, was passiert (wenn Sie in Großbritannien sind), als eine große Bank hier ein routinemäßiges Upgrade durcheinander gebracht und alle Transaktionen durcheinander gebracht hat, die dazu geführt haben, dass Millionen (mindestens Hunderttausende) Menschen nicht in der Lage waren, diese zu erhalten an ihrem Geld.

Ich würde sogar noch weiter gehen. Ich würde den umgebenden Code überprüfen und sehen, wie Variablen an die Abfrage übergeben werden. Es ist oft zu sehen, wie Entwickler ihre Anwendung aufgrund ihres Mangels an Grundkenntnissen SQL-Injection-Angriffen aussetzen (falsche Annahmen "Dies kann nicht gehackt werden").

Auch unerfahrene Entwickler können die Datenbank mit einem Missbrauch von ORM oder einer Abfrage, die alles andere als optimal ist, auf die Knie zwingen.

In dem letzten Projekt, an dem ich arbeite, darf kein Front-End-Entwickler direkt auf die Datenbank zugreifen. Sie fordern eine Funktion, die einen bestimmten Datensatz zurückgibt, und die Back-End-Entwickler bereiten ihn für sie vor. Es funktioniert ganz gut, Front-End-Entwickler schreiben die Benutzeroberfläche und verarbeiten Daten, die von Funktionen bereitgestellt werden, die von Back-End-Entwicklern geschrieben wurden.

In unserem Entwicklungsteam gibt es ein Subteam von 4 Datenbankentwicklern, die Erfahrung mit der von uns verwendeten DBMS-Plattform haben. Sie schreiben alle SQL- oder zumindest Überprüfungen und nehmen Änderungen vor, um die von .NET-Entwicklern geschriebenen SQL-Standards zu erfüllen. Sie sind Teil des Projektteams. Die Produktions-Datenbankadministratoren gehören einer völlig anderen Abteilung an und sind betriebsbereit. Sie überprüfen unseren SQL-Code oder unser SQL-Schema nicht und selbst die Bereitstellung erfolgt per Skript. Sie führen lediglich das Skript aus. Sie helfen am meisten bei der Leistungsoptimierung.