Warum sagen die meisten Leute, dass Datendienste und die Datenbank die wichtigsten Teile eines Systems sind?
Nach allem, was ich gesehen habe, ist es die Frontend-Entwicklung: GUI, WEBUI, XAML ist das Wichtigste. Sicher wichtiger als die mittleren und Datenbankebenen.
Ich glaube nicht, dass es eine große Sache ist, die Datenbank einer Anwendung zu erstellen. Schließlich stammt das Datenschema aus der Geschäftsanalyse und es gibt sehr wenig "kreative" Arbeit seitens des Datenbankentwicklers. Dasselbe gilt für die Geschäftslogik (mittlere Stufe). Darüber hinaus tragen J2EE und das .NET Enterprise Framework dazu bei, die Geschäftslogik einfach zu entwickeln.
Was macht der Datenbankentwickler also so wichtig? Warum brauchen wir sogar einen eigenständigen Datenbankentwickler? Warum zahlen die meisten Unternehmen den Middle- / Backend-Entwicklern anstelle von Frontend-Entwicklern immer noch ein höheres Gehalt?
Ich glaube, dass Entwickler, die die Benutzeroberfläche (in Java oder C #) erstellen, über Datenbankkenntnisse verfügen sollten. Dadurch können sie die gesamte Anwendung erstellen. Meiner Ansicht nach ist es unmöglich, eine Nicht-Datenbank-Wissensperson die Anwendung trotzdem entwickeln zu lassen.
Bitte lassen Sie mich wissen, was ich hier vermisse.
Vielen Dank.
Das Frontend ist normalerweise viel einfacher zu ändern, während das Backend mehr Anforderungen und Designphasen benötigt. Wenn das Backend geändert wird, muss das Frontend höchstwahrscheinlich geändert werden, sodass Änderungsanforderungen, die mit den Backend-Services (db usw.) zu tun haben, häufig zu vielen Änderungen über das mittlere und das vordere Ende führen. Eine Änderung am Frontend hat normalerweise keinen Einfluss auf das Backend.
Das DBA-Problem hängt wirklich von der Größe Ihres Projekts ab. Wenn Sie über Projekte mit ein paar einfachen Tabellen und ein paar tausend Datensätzen sprechen, haben Sie wahrscheinlich recht. Ein echter DBA würde das wahrscheinlich unter seinem Wert sehen, trotzdem an diesem Projekt zu arbeiten. Ein echter DBA ähnelt eher einem Systemadministrator, der auf DBMS-Optimierungen spezialisiert ist. Fast jeder Programmierer kann Tabellen, Beziehungen, Ansichten, gespeicherte Prozeduren usw. erstellen. Und besonders mit einfach zu verwendenden ORMs wird vieles, was DBAs bisher verwendet haben, nicht wirklich benötigt. Ein DBA ist jedoch entscheidend, wenn Sie an großen Projekten und großen Datenbanksystemen für DBMS-Optimierungen, Systemkonfiguration, Failover-Konfiguration usw. arbeiten.
Ihre ursprüngliche Frage spricht nicht über den Projektumfang, und ich denke, dass Sie dort verwirrt sind oder die Bedeutung eines echten DBA nicht sehen (nicht mit jemandem zu verwechseln, der etwas SQL versteht oder Daten verarbeitet) Eintrag und nennen sich selbst einen DBA).
Ich glaube an die Frontend-Seite: GUI, WEBUI, XAML ist wichtiger als mittlere Ebene und Datenbankebene.
Das ist so, als würde man sagen, dass die Farbe eines Autos wichtiger ist als der Motor und die Reifen.
Es ist wahrscheinlich keine große Sache, eine Datenbank zu erstellen. Es ist jedoch eine große Sache, einen korrekt zu erstellen, einen vorhandenen zu optimieren und einen gut gestalteten Datenspeicher zu verwalten. IMO, das ist der Grund, warum Datenbank / Datenspeicher-Leute das große Geld bekommen.
Einige der anspruchsvollsten Arbeiten, die ich als Programmierer gemacht habe, beschäftigen sich mit Benutzeroberflächen (xhtml, xaml, servlets, mvc, asp.net usw.). Davon abgesehen denke ich, dass Sie zwei verschiedene Probleme haben. Auf der Datenbankseite, wie Mathew sagte, wird ein echter DBA in der Lage sein, eine große Datenbank (Millionen von Datensätzen) auf eine Art und Weise zu optimieren, wie sie einem normalen Entwickler nicht bekannt ist. Auf der mittleren Ebene denke ich, dass der Grund dafür, dass die Benutzeroberfläche oft so komplex ist, darin besteht, dass der Entwickler oft nicht wirklich eine echte mittlere / geschäftliche Logikebene erstellt. Also fügen sie am Ende die gesamte Logik in die Anwendung ein, was falsch ist. Gute Entwickler zu finden, die wissen, wie man eine solide, objektorientierte Business-Schicht aufbaut, die domänengestütztes Design und OO-Designmuster kennt, ist RARE. Erstellen Sie eine Reihe von Klassen mit nur GET / SETZER, die Ihre Datenbankobjekte entsprechen, ist kein objektorientiertes Design. Daher sind sie mehr wert.
Abgesehen davon stimme ich zu, dass UI-Arbeit immer noch eine sehr anspruchsvolle Programmierung ist und als wichtiger angesehen werden sollte, als sie es derzeit ist.
Für eine kleine App, die Sie zusammenschmeißen, scheint die Datenbank nicht so wichtig zu sein, aber lassen Sie diese App wachsen und entwickeln Sie sich im Laufe der Zeit und Sie stoßen aufgrund des schlechten Designs schnell in Fallstricke.
Die Datenbankebene und die mittlere Ebene sind die Schlüssel für die Langlebigkeit und Wartbarkeit Ihrer App.
Neben vielen anderen Gründen: Mit einer soliden mittleren Schicht können Sie je nach Bedarf von einer GUI auf eine andere umschalten (sagen wir von Pre Web 2.0 zu Web 2.0 Design). Also wird viel mehr Planung für das mittlere und das Backend benötigt Ebenen im Vergleich zu einem möglicherweise austauschbaren Frontend.
Es ist unmöglich, eine nicht datenbankexterne Person dazu zu bringen, eine Anwendung zu entwickeln.
Nicht, wenn Sie die Datenbanktabellen mit gespeicherten Prozeduren ausblenden, die in Web-Services eingebettet sind.
Das Frontend ist nur eine Haut über der realen Anwendung.
Die mittlere Business-Stufe ist am schwierigsten zu programmieren, da die Geschäftsleute selten wissen, was ihre Anforderungen sind, obwohl sie denken, dass sie es tun. Sie ändern ihre Meinung regelmäßig. Randkästen zerstören ein schönes Design und können sehr schwierig zu implementieren sein.
Es spielt keine Rolle, wie gut Ihr GUI-Entwickler ist, wenn er ein Frontend auf einer schlecht geschriebenen Business-Ebene schreibt. Und Sie können keine gute Geschäftsschicht auf einer schlecht entworfenen Datenbank schreiben.
Am Ende ist es viel einfacher, eine GUI neu zu schreiben, als die Datenbankschicht oder die mittlere Schicht zu ändern, da sich jede Änderung auf alle nachfolgenden Stufen des Programms auswirkt.
Es ist unmöglich, Ihre Frage zu beantworten.
Es basiert auf der Prämisse, dass jeder denkt, dass die Datenbank das Wichtigste in allen Systemen ist - was natürlich falsch ist - nicht nur, dass alle Menschen nicht denken, dass viele Systeme keine Datenbanken verwenden und viele erfahrene Leute zustimmen werden dass die wichtigsten Teile verschiedener Systeme von System zu System variieren.
In der Tat, bei der Definition eines Systems muss jeder Teil wichtig sein! Es ist möglich, dass einige Subsysteme teurer sein können als andere, einige fehlertoleranter als andere, andere modular austauschbar und andere nicht, aber alle sind Teil eines SYSTEMS und sind daher wichtig. Die Idee, dass man wichtiger ist, ist schwer zu quantifizieren. Es ist denkbar, dass einige Teile optional sind (wie "unfunktionale" Dekoration) und daher nicht als Teil des Systems betrachtet werden. In der größeren Ansicht des Systems nehmen die Benutzer jedoch teil und ihre effiziente und freudige Interaktion mit dem System ist entscheidend für den Erfolg.
Um eine Analogie zu benutzen, die schon hier gepostet wurde, ist die Farbe auf einem Auto vielleicht nicht so wichtig wie der Motor, aber würde jemand ein unbemaltes Auto verkaufen? - nicht wahrscheinlich (es sei denn, das war die Definition des Produkts - wie unfertige Möbel).
So wie ein Motor teurer ist als eine Lackierung, würde ich erwarten, dass wir die Menschen mehr für die Entwicklung von Motoren bezahlen als für die Auswahl der Farben.
Es gibt ein Spektrum von Spezialitäten und Komplexitäten in allen Systemen.
Die Logik des Geschäfts ist immer einfach mit Hilfe von J2EE oder DotNET Enterprise Framework.
Sicher, die Kodierung der Geschäftslogik tendiert dazu, einfach zu sein ... wenn Sie sich keine Sorgen machen müssen über Ausnahmen, Fehlerbehandlung, tatsächlich die richtigen Anforderungen aus dem Geschäft zu bekommen, etc. Fügen Sie die Fähigkeit hinzu (benötigt jetzt mehr als immer) für eine einzelne Anwendung, um mehrere Front-Ends (Web, Desktop, Mobile) zu unterstützen, und plötzlich, dass "einfache" Geschäftslogik zu einem kritischen Punkt wird.
Es bedeutet nicht, dass jeder in VC ++ gut programmieren kann, obwohl er in c ++ Kenntnisse hat.
In der heutigen technischen Welt hat jeder Entwickler Grundkenntnisse über die meisten der neuesten Technologien. Es bedeutet nicht, dass sie bereit sind, ein System mit allen Technologien zu entwerfen.
Alles kommt mit Erfahrung und Ihrer Spezialisierung. Denken Sie daran, dass sie gut dafür bezahlt haben, DBA zu machen, ohne UI-Design zu machen.
Es bedeutet nicht, dass UI-Entwickler keine DB entwerfen können. Sie können auch ein guter DB-Designer werden, wenn Sie genug Erfahrung mit dem Entwerfen einer Datenbank haben.
Tags und Links c# java-ee database-design backend