Wie könnten DBAs "programmiererfreundlicher" sein?

Die Antworten und Kommentare zur dba.se-Version und zur programmers.se-Version der Frage "Welche Argumente sprechen gegen oder für das Einfügen von Anwendungslogik in die Datenbankebene?" sind sehr aufschlussreich über die Kluft zwischen DBAs und Programmierern an einigen Arbeitsplätzen.

Was könnten DBAs anders machen, um in solchen Fragen besser mit Programmierern zusammenzuarbeiten?

Sollten wir:

• Lernen Sie die Tools und Sprachen kennen, mit denen unsere Programmierer ihre Schwierigkeiten verstehen, insbesondere wenn sie mit gut gestalteten Datenbanken arbeiten.
• Ermutigen Sie Programmierer, besser über Datenbanken und die Vorteile von Geschäftslogik auf Datenbankebene informiert zu sein?
• Ändern Sie die Art und Weise, wie wir Schnittstellen zu unseren Daten definieren - z. B. durch die Verwendung programmiererfreundlicherer Transaktions-APIs (z. B. für Probleme wie Abwärtskompatibilität)?

Vom Standpunkt eines Programmierers aus würde ich sagen, dass das, was wir am meisten wollen, konsistente, gut definierte und implementierte Standards für das Design und den Aufbau der Datenschicht sind. Ich bin bereit, so zu spielen, wie Sie es in Ihrer Sandbox wollen. Sie müssen mir nur sagen, was Sie wollen, und nicht die Regeln die ganze Zeit ändern. Es sollte für alle gleich implementiert werden, auch für Superprogrammierer. Wenn Sie Ausnahmen für ihn machen, möchten Sie, dass ich ihn unterstütze und ändere, aber ihn auf die richtige Weise wieder einsetze, die für mich nicht funktioniert.

Und bitte sag mir nicht, dass ich es nicht so machen soll und geh weg. Arbeite mit mir, um mir zu zeigen, was du willst und warum dein Weg besser ist. Wenn ich es verstehe, werde ich mich jedes Mal daran halten. Wenn ich es nicht verstehe, ist es schwieriger zu befolgen. Ich möchte kein DBA sein. Ich liebe das Programmieren. Ich will deinen Job nicht und wenn du ein guter DBA bist, werde ich dein größter Fan sein.

Ich bin seit 6,5 Jahren ein MySQL-DBA. Ich habe auch 16 Jahre als Entwickler gearbeitet und mit vielen DBAs interagiert. Viele von ihnen pragmatisch. Einige von ihnen sind widerlich. Einige haben keine Ahnung, was es bedeutet, ein DBA zu sein.

Ich bin zu folgendem Schluss gekommen:

Technisch gesehen sind DBAs mit einer oder mehreren der folgenden Eigenschaften am besten geeignet:

1. Verbrachte Jahre als Entwickler
2. Machen Sie sich mit der Datenbanktheorie vertraut
3. Verstehen Sie gut, wie das RDBMS intern funktioniert
4. Überlegene Kenntnisse des Betriebssystems

Sehr disziplinierte, sachkundige Datenbankadministratoren haben viel zu teilen und zu bieten. Sie können die Datenbankleistung aus einer Perspektive betrachten, die von Entwicklern nicht wirklich berücksichtigt wird. Entwickler wissen aus der Datenbank, was sie wollen. Datenbankadministratoren wissen, wie sie die Datenbank "höflich" behandeln.

Was die Persönlichkeiten betrifft, wird es immer Konflikte, Kleinigkeiten und vielleicht sogar Neid geben. Eines ist sicher: In keiner bestimmten Reihenfolge sind DBAs und Entwickler wie Ehemänner und Ehefrauen (ich bin seit 16 Jahren glücklich verheiratet und arbeite an Projekten [4 Kinder]).

Unabhängig davon, wer als Ehemann und wer als Ehefrau angesehen wird, gelten folgende Grundsätze:

1. man muss den anderen konsultieren
2. man muss die Perspektive des anderen schätzen
3. man muss Entscheidungen zum Wohl beider Parteien treffen
4. man muss die getroffene Entscheidung unterstützen und nicht sabatoge
5. Das eine darf das andere nicht verunglimpfen, wenn Entscheidungen schlimme Folgen haben
6. man muss sich über den beitrag beider parteien zum erfolg der entscheidungen freuen
7. Man muss eine höhere Behörde konsultieren, wenn eine Entscheidung nicht einvernehmlich getroffen werden kann

Diese sieben (7) Grundsätze gelten auch am Arbeitsplatz, insbesondere im IT-Bereich.

Durch die Kommunikation aller Schritte sollten alle:

1. Layout ihre Erwartungen
2. Respekt für die Fähigkeit der anderen Partei, ihren Beitrag auf der Grundlage vergangener Leistungen zu leisten
3. Vertrauen haben und darauf vertrauen, dass die andere Partei ihren Auftrag erfüllen kann
4. Erfüllen Sie unsere eigenen Erwartungen
5. Aciese unter der Anleitung der HA (siehe Prinzip # 7)

Hier ist kein Platz für Mikromanagement. DBAs SOLL NICHT SAGEN Entwicklern wie wie DBAs zu denken. Entwickler sollten DBAs nicht sagen, wie sie Entwickler sein sollen. Die endgültigen Entscheidungen zur Datenbankleistung und -nutzung müssen von den Datenbankadministratoren getroffen werden . Die endgültigen Entscheidungen über die Anwendungsanforderungen müssen bei den Entwicklern liegen . Diese Symbiose muss immer gewahrt bleiben.

ABSCHLIESSENDE GEDANKEN

Prinzip Nr. 7 erfordert die aktive Teilnahme und Überwachung durch die HOCHBEHÖRDE (HA), dh den Projektmanager, den Teamleiter und den leitenden Entwickler. Ihr HA weiß besser, wie beide Parteien individuell arbeiten und wie beide Parteien zusammenarbeiten sollten. Wenn die HA keine Grundregeln für beide Parteien festlegt oder die HA die Parteien nicht einzeln und gemeinsam anleitet, werden Projekte immer irgendwann zum Stillstand kommen und die Existenz (Beschäftigung) des Entwicklers, des DBA, gefährden. oder auch die HA.

Teams in verschiedenen Abteilungen / Etagen zu haben, scheint irgendwie die Mentalität von "uns gegen sie" zu fördern.

Wenn Sie einen DBA direkt in der Mitte des Entwicklungsteams sitzen, können Sie die Programmierer- / DBA-Mauer auf hervorragende Weise niederreißen. Sowohl der DBA als auch die Programmierer werden davon profitieren, wenn sie offen bleiben und ihr Ego beiseite legen.

Face-to-Face-Kommunikation, insbesondere beim Austausch von Ideen, ist weitaus effektiver als E-Mail und kann aufgrund von Missverständnissen weniger harte Gefühle hervorrufen.

So etwas ist von Ort zu Ort sehr unterschiedlich. An meiner aktuellen Site ist die Grenze zwischen Entwicklern und DBAs in der Tat sehr unscharf. Wir (DBAs) schreiben auch PL / SQL und sie (Entwickler) analysieren Abfragepläne. Wir alle sehen uns als Gleichaltrige, nur mit unterschiedlichen Fähigkeiten und Verantwortlichkeiten. Das ist sehr amüsant: Vor kurzem ist das Unternehmen in den DevOps- Zug gesprungen . Die Datenbank-Community versteht das überhaupt nicht. wir haben immer so gearbeitet. Unnötig zu erwähnen, dass wir so enorm produktiv arbeiten: Die Datenbankschicht ist bei weitemDer zuverlässigste Teil des Technologie-Stacks des Unternehmens ist seine einfache Bedienung (da wir die Fähigkeiten des DBA-Teams besitzen, um die Anwendung auf einer tiefen Ebene zu verstehen, und die Entwickler über die Erfahrung des DBA verfügen, um den 24/7/365-Betrieb und die Funktionsweise zu verstehen ihre Apps dafür zu strukturieren).

Aber ich weiß, was Sie meinen, wenn Sie über die "falsche" Art von Entwickler sprechen. Er ist Autodidakt, was an und für sich eine edle Sache ist, aber auf dem Weg dorthin hat er Misstrauen gegenüber jeglichen formalen Anweisungen auf sich gezogen. Er weiß nicht, was er nicht weiß , und er ärgert sich über jeden, der versucht, ihn aufzuklären, er sieht es als Beleidigung seiner Selbstlernfähigkeiten. Er hat den imperativen Stil des Programmierens gelernt, weil man ihn ohne all das theoretische Zeug lernen kann, über das CS-Typen immer plappern (na ja, schlecht, jeder muss Big-O kennenund ähnliche theoretische Aspekte). Er hat auch ein bisschen von OO gelernt, nur weil er Java benutzen muss. Ein guter Datenbankprofi - Entwickler oder DBA - muss sich jedoch in einem deklarativen Stil wohlfühlen, über Mengenlehre und Normalformen nachdenken und sogar die relationale Algebra und den Kalkül verstehen können. Es ist sehr, sehr schwierig, mit diesen Leuten zu kommunizieren, weil sie sich aktiv gegen alles wehren, was sie aus ihrer Komfortzone bringen könnte, die sich im Großen und Ganzen darauf beschränkt, etwas auf einer Webseite zu formatieren. Wenn sie überhaupt an Datenbanken denken, denken sie, dass eine Tabelle wie eine Klasse und eine Zeile wie ein Objekt ist. Diese Leute werden buchstäblich nur SELECT * FROM TABLEdie Ergebnisse in ihrem eigenen Code filtern und sortieren. Sie verstehen wirklich, wirklich nicht, warum eine Datenbank besser ist als eine flache Datei (und sie denken nicht so heimlich, dass jeder, der eine relationale Datenbank verwendet, ein Idiot ist).

Lassen Sie mich ein echtes Beispiel geben: Vor kurzem habe ich mit einem dieser Typen über die Probleme gesprochen, die mit dem Zurücksetzen einer Version unserer Software nach dem Produktionsstart verbunden sind, wenn eine Ausgabe die Qualitätssicherung überschritten hat. Ich erklärte, dass wir seine Anwendung zwar zurücksetzen könnten (eine von vielen, die auf die Datenbank zugreifen), sie jedoch mit der noch bereitgestellten Datenbank funktionieren muss. Er fragte, warum und ich sagte, nun, in diesen neuen Tabellen und Spalten werden echte Kundendaten stehen. Dann sagte er, kopiere es einfach in eine temporäre Tabelle, was das Problem ist. Ich starrte ihn ungläubig an: Wenn ein Kunde anruft und sagt, mein Geld sei von meinem Konto verschwunden, was sagen wir ihm, dass es in Ordnung ist, es in einem temporären Tisch? Er hat einfach nicht verstanden, dass man sich als verantwortungsbewusster Erwachsener verhalten muss, wenn man mit dem Geld anderer umgeht. Soweit ich weiß, tut er das immer noch nicht. er ist nicht mehr bei uns

Das MySQL-Camp war lange Zeit so; Sie sagten, Sie bräuchten keine Transaktionen, Fremdschlüssel usw., wenn Sie dachten, Sie hätten es nur getan, weil Sie keine Ahnung hatten, was Sie tun usw. usw. (dann, als sie aufwuchsen, fügten sie sie leise hinzu). Für diese Art von Personen wurden ORMs wie ActiveRecord oder Hibernate entwickelt, damit sie Datenbankanwendungen schreiben können, ohne jemals SQL berühren zu müssen. Die Verwendung dieser Technologien halte ich für eine rote Fahne - dies ist kein Unternehmen, das die DBA-Fähigkeiten schätzt. Was sie wirklich wollen, ist ein Babysitter ...

Als Programmierer hat mich das bessere Verständnis der Datenbank zu einem besseren Programmierer gemacht. Als ich Datenbankadministrator wurde, wurde dies noch wichtiger, daher glaube ich, dass Bildung der Schlüssel ist.

DBAs sollten Entwickler geduldig anleiten, sie als kompetente Fachkräfte zu behandeln. Wenige Programmierer, die den Unterschied zwischen einer festgelegten Operation und einer zeilenweisen Operation auf der Clientseite sehen, werden der Idee im Wege stehen. Wir teilen einige der gleichen Ziele - Anwendungsgeschwindigkeit, Datensicherheit, Wartbarkeit usw. Dies gilt nicht nur für die Frage der Anwendungslogik, sondern auch für alle Aspekte der Datenbankinteraktion. Programmierer möchten ihre Tools besser nutzen und je mehr der DBA ihnen zeigen kann, wie sie das Datenbank-Tool besser nutzen können, desto mehr profitieren sie beide.

Egal welche Infrastruktur wir unterstützen, wir müssen die Benutzer unterstützen. Viele Benutzer sind Entwickler, daher unterstützen wir die Entwickler, damit sie diese Infrastruktur optimal nutzen können. Um dies tun zu können, müssen wir uns gegenseitig verstehen und dabei die unterschiedlichen Ideen und Standpunkte berücksichtigen. Der Einblick in die Ansichten beider Seiten trägt dazu bei, das Geschäft zu verbessern, und das ist unser gemeinsames Ziel. Sorgen Sie dafür, dass die IT das Geschäft so effektiv wie möglich unterstützt.

In vielen Organisationen werden einige DBA-Typen im Gott-Modus ausgeführt. Meistens sind es nicht die, die sehr gut abschneiden, wenn die Kompetenz gemessen wird. Oft verstecken sie nur ihr - fehlendes - Wissen hinter einer Wand aus Wörtern.

Meiner Meinung nach hat es nichts damit zu tun, "programmiererfreundlich" zu sein, sondern eher damit, professionell zu sein. Für einen DBA bedeutet dies, dass wir in der Lage sein müssen, zu erklären, warum wir die Dinge tun, die wir tun, und bereit sind, Entscheidungen zu überdenken, wenn dies hilft, ohne die normalen Ziele wie Verfügbarkeit, Skalierbarkeit, Wiederherstellbarkeit und Leistung zu verlieren. Für den Programmierer bedeutet dies, dass er mit der DBA kommunizieren muss, manchmal um die DBA zu unterrichten, manchmal um von der DBA zu lernen. Mein Motto lautet: Lass den ersten Tag, an dem ich nichts lerne, der Tag sein, an dem sich der Sarg über meinem Kopf schließt. Eine normale Zusammenarbeit, die Teams mit Entwicklern und dba's kombiniert, erleichtert die Sache.

Ich denke, ein Teil des Problems ist die Perspektive. Dbas- und Datenanalysten sowie Datenbankentwickler müssen sich mit den Daten im Laufe der Zeit auseinandersetzen. Anwendungsentwickler befassen sich mit der Funktionsweise, wenn sie sie an die Produktion senden. Sie kümmern sich nicht so sehr darum, wie die Daten in sechs Monaten aussehen werden, solange bei der Bereitstellung keine Fehler auftreten.

Aber Datenleute müssen mit den Ergebnissen kurzsichtiger Entscheidungen leben, die dazu führen, dass die Daten ihre Integrität verlieren oder doppelte Datensätze eingefügt werden, und dann versuchen, zu erklären, warum die Daten schlecht sind. DBAs sind diejenigen, die sich mit dem Leistungsproblem aus dem Prozess befassen müssen, der einwandfrei funktionierte, als es nur tausend Datensätze gab, aber jetzt mit 100.000.000 Datensätzen Stunden dauert.

Da sich Datenbanken schwerer umgestalten lassen, sind Datenbankadministratoren bemüht, sie beim ersten Mal richtig zu machen. Entwickler sehen kein Problem in der Umgestaltung auf der Straße.

Entwickler sehen kein Problem darin, die Datenbank objektorientiert zu machen. Die Benutzer der Datenbank wissen, dass dies nicht die effektivste oder effizienteste Methode ist, um Daten zu speichern oder abzurufen.

Anwendungsentwickler beschäftigen sich häufig nur mit einer kleinen Teilmenge von Datensätzen, nicht jedoch mit großen Datenimporten / -exporten oder -berichten. Dinge, die gut funktionieren, um einen Datensatz einzugeben, funktionieren nicht, wenn Sie über den Import einer Million sprechen. Die Geschäftslogik in der Anwendung (auf die die Berichtsanwendung häufig nicht zugreifen kann) hilft dem Berichtsersteller nicht dabei, für eine Million Datensätze die gleichen Ergebnisse zu erzielen, die auf dem Bildschirm jeweils für einen Datensatz angezeigt werden.

Ein weiterer Teil des Problems ist die Missachtung auf beiden Seiten. Ich habe mehr als ein paar Anwendungsentwickler getroffen, die denken, dass Datenarbeit nicht schwer oder interessant ist und die glauben, dass Sie diese Arbeit nur tun würden, wenn Sie sie in ihrer Welt nicht hacken können. Menschen neigen dazu, nicht gut auf die Behandlung zu reagieren, als wären sie dumm und nutzlos. Auf der anderen Seite neigen einige Datenbankadministratoren dazu, Anwendungsentwickler mit Respektlosigkeit zu behandeln und ihre Aufgabe, zu überprüfen, was die Entwickler an der Datenbank tun, als niedrige Priorität zu betrachten (was bei großen komplexen Produktionsdatenbanken der Fall sein kann). Sie können sich weigern zu hören oder reagieren. Wer möchte sein gesamtes Projekt auf Eis legen, bis der DBA es zwei Wochen später überprüft? Und dann sagt er dir, dass es inakzeptabel ist und du die ganze Sache umschreiben musst?

In den vielen Jahren, seit ich mit SQL Server angefangen habe (1998), haben mir viele Entwickler gesagt, wie ich meinen Job machen soll. Es ist interessant, dass sie alle mehr als ich wissen und hervorragende .net-Entwickler sind. Tatsächlich sind sie auch Architekten und sollten mehr tun als Code Monkeying.

Vielleicht ist das die falsche Einstellung von mir: aber es ist eine in vielen Läden übliche Einstellung von Entwicklern. Sie tun es auch miteinander. Denken Sie daran: Sehen Sie zu, wie die Kämpfe beginnen, wenn Sie Peer Reviews vorschlagen.

Ich werde die Korrekturen anderen Antworten überlassen (ich stimme den beiden bisher zu 100% zu), füge jedoch hinzu, dass die Management- und Shopkultur auch die Zusammenarbeit unterstützen und fördern muss .

Als Entwickler muss ich nur wissen, wie ich mitteilen soll, was ich brauche. Wenn ich um etwas Lächerliches bitte, musst du es mir sagen - und wenn du es mir sagst, werde ich es glauben, weil du eine Erfolgsbilanz für Integrität hast. Wenn Sie nicht verstehen, wonach ich frage, nehmen Sie sich die Zeit, mir zu erklären, was Sie meinen - und ich werde mir die Zeit nehmen, zuzuhören.

... Gemeinsames Thema, richtig ... Kommunikation ... Kommunikation ... Kommunikation.

Es gibt wirklich keinen besseren Weg, es auszudrücken. Entwickler werden angekreuzt, weil "der DBA mir gesagt hat, dass dies nicht möglich ist - ich habe ihm beim letzten Mal sicher das Gegenteil bewiesen." DBAs werden angekreuzt, weil "dieser Entwickler nicht versteht, was ich jedes Mal tun muss, wenn er seine Spezifikationen ändert."

Entwickler und Datenbankadministratoren müssen sich, wie @Rolando feststellte, verstehen. Im Endeffekt sprechen wir beide "Ones & Zeros" - das wäre eine gute Übereinstimmung. Wir haben 2 Verantwortungsbereiche: DBAs haben Daten, Entwickler bekommen den Rest des Computers. Aber ohne Daten hätten Programmierer wirklich nicht viel zu tun.

Wir haben keinen DBA und es ist manchmal schmerzhaft. Das Stück von mir, das vor einem Jahrzehnt DBA werden wollte, wird zusammenzucken, wenn ich einige der Dinge sehe, die wir tun. Wenn wir morgen einen DBA anstellen würden, würde ich wahrscheinlich genau den Boden küssen, auf dem er / sie ging.

In einigen, vielleicht vielen Unternehmen tendiert die Produktentwicklung dazu, jeden zu ignorieren, der nicht in einer kompilierten Sprache schreibt. Kommen Release-Zeiten, gibt es Widerstand, weil Netzwerkadministratoren, Datenbankadministratoren, Systemadministratoren, Benutzer-Support usw. jeweils ihre Due-Diligence-Prüfungen durchführen müssen. Es gibt oft Kopfschmerzen, weil wichtige Aspekte der Umwelt nicht berücksichtigt wurden. Dies führt natürlich zu Spannungen zwischen den Mannschaften.

Wer ist hier schuld? Frau Mitteilung.

Entwickler müssen verstehen, in welcher Umgebung der Code implementiert wird. Die Benutzer müssen zur Anpassung angemessen gewarnt werden. Wenn sich die Umgebung aus irgendeinem Grund (Sicherheit, Ausrüstung, Richtlinien) nicht anpassen kann, muss sich die Software anpassen. Wenn dies während des Design- und Implementierungsprozesses passiert, sind alle glücklich. Wenn es erst zur Bereitstellungszeit startet, ist es eine Welt voller Verletzungen.

Ja, die Teams müssen miteinander reden (und zuhören), aber der Projekt- / Produktmanager muss eine Umgebung schaffen, in der dies passieren kann.

Ich hatte das Glück, an den meisten Orten, an denen ich gearbeitet habe, war gegenseitiger Respekt und Kommunikation Teil der Kultur.

Eine Sache, die ein guter DBA verstehen muss, ist die Politik der Daten. Ich unterrichtete erfahrene Programmierer und einige DBAs in Datenbankprogrammierung und -design. Eine Frage, die regelmäßig auftauchte, war: Wie kommt es, dass alle Datenbanken in meinem Shop so politisch sind?

Hier war meine Standardantwort: Wenn die Datenbank nützlich ist, teilen Sie Daten. Wenn Sie Daten teilen, teilen Sie die Energie. Wenn Macht geteilt wird, passiert Politik.

Es ist egal, ob Sie Politik lieben oder Politik hassen. Wenn Sie gute Datenbankarbeit leisten wollen, gewöhnen Sie sich daran.

Übrigens haben einige von Ihnen nur in einer Entwicklungsumgebung gearbeitet. Es gibt DBAs, die auf der Produktionsseite des Zauns arbeiten und nur wenig mit Entwicklern zu tun haben. Man könnte meinen, dass es in der Produktion weniger Politik gibt. Es gibt mehr. Die großen Produktionsdatenbanken sind in der Regel unternehmensweit und unternehmenskritisch.

Ein bisschen Demut könnte einigen von Ihnen helfen. ;)

Es gibt offensichtlich gültige Argumente für beide Ansätze. Ich schlage vor, Sie erkennen dies zunächst an. Bei der Softwareentwicklung dreht sich alles um die richtigen Kompromisse. Wenn es sich um eine Einbahnstraße handelt, sollten DBAs vielleicht auch offen sein.