Sollten erfahrene Programmierer Datenbankabfragen kennen? [geschlossen]

Es gibt so viele Programmierer, die auch ein Experte für das Schreiben von Abfragen und das Entwerfen von Datenbanken sind.

Sollte dies eine Grundvoraussetzung sein, um ein erfahrener Programmierer oder Softwareentwickler zu sein?

Obwohl es viele Ähnlichkeiten in der Art und Weise gibt, wie Abfragen und Codes entwickelt werden, scheint meine persönliche Meinung zu sein, dass Abfragen eine andere Struktur als Code haben und es aufgrund der unterschiedlichen Ansätze schwierig sein kann, beide gleichzeitig zu meistern.

Ob das Schreiben von Datenbankabfragen eine Kernanforderung sein sollte oder nicht, hängt vom Job ab, aber relationale Datenbanken sind in der aktuellen Technologie allgegenwärtig.

Wenn ich also einen Programmierer treffen würde, der nicht weiß, wie man Datenbankabfragen schreibt, würde ich eines von zwei Dingen erwarten:

1. Sie sind in der Regel unerfahren.
2. Sie sind hochspezialisiert auf einem anderen Gebiet (zB eingebettete Systeme) und mussten es nie lernen.

Datenbankabfragen unterscheiden sich grundlegend von Standardprogrammiersprachen. Sie sind algebraisch und für relationale Daten gedacht, während C # oder Java unbedingt erforderlich sind und für Festplatten, Speicher, Benutzereingaben usw. gelten.

EDIT: Wie in den Kommentaren von mir und anderen erwähnt, gibt es einige triftige Gründe, warum ein erfahrener Entwickler Datenbankabfragen möglicherweise nicht gut kennt:

• Ihr Team verwendete ORM / NoSQL
• Ihr Team hatte DB-Programmierer
• Die Komplexität der Anwendung lag in der Geschäftslogik, und die DB-Abfragen waren trivial
• Ihr Team hat die Arbeit so aufgeteilt, dass einige Programmierer keine Abfragen geschrieben haben

Obwohl gültig, sind diese Vorbehalte keine überzeugenden Gründe, warum ein erfahrener Entwickler Datenbankabfragen nicht kennt. Ein Programmierer sollte mit relationalen Datenbanken vertraut sein, es sei denn, er ist hoch spezialisiert.

Zusammenfassend sollten die meisten erfahrenen Entwickler Datenbankabfragen kennen .

Jeder Softwareentwickler sollte ein grundlegendes Verständnis für Datenbanken und das Speichern und Abrufen von Daten mit SQL haben, zumindest so weit, dass er versteht, wofür dies verwendet werden kann (und damit würde ich ein Verständnis für Schlüssel und Ansichten einschließen , gespeicherte Prozeduren und Trigger).

Nicht jeder Softwareentwickler muss ein Experte sein, und das erforderliche Fachwissen hängt wirklich von der Art der Software ab, auf die er sich konzentriert. Eingebettete Software, Hardwaretreiber und Betriebssysteme verwenden selten SQL, aber Anwendungssoftware (Web, Desktop oder Service / Daemon) verwendet ständig Datenbanken.

In einigen Fachgebieten (zum Beispiel eingebettete Systeme) sind keine Datenbankkenntnisse erforderlich. Bei den meisten Geschäftsanwendungen wird jedoch eine Datenbank verwendet. Wenn Sie die ordnungsgemäße Verwendung dieser Datenbank nicht genau kennen, können Sie eine Leistungsstörung verursachen, die nur schwer zu beheben ist. Das Umgestalten von Datenbanken kann ein komplexer und schwieriger Prozess sein, und viele Unternehmen entscheiden sich aufgrund dieser Schwierigkeit dafür, die strukturellen Probleme nicht zu beheben und sich nur tiefer in ein Loch zu graben. Wenn Sie über Datenbankkenntnisse verfügen, ist das Entwerfen viel einfacher und funktioniert mit der Zeit mit größerer Wahrscheinlichkeit.

ORMs sind kein Ersatz für Datenbankkenntnisse. Jeder, der eine Datenbank verwendet, ohne die Grundlagen der Datenbankabfrage und des Datenbankentwurfs zu kennen, ist dazu verdammt, eine schlecht funktionierende, schlecht entworfene Datenbank zu haben, die die Fähigkeit Ihrer Anwendung zur Bewältigung der Last auf lange Sicht beeinträchtigt. ORMs in den Händen von jemandem, der weiß, was er oder sie tut, sind in Ordnung; In den Händen von Leuten, die sich nicht die Mühe machen, etwas über Datenbanken zu lernen, sind sie normalerweise eine Katastrophe.

Wenn ich ein Projekt mit einem Datenbank-Backend hätte, wäre der Datenbankspezialist der zweite Entwickler, den ich einstellen würde (nach dem ersten Anwendungsentwickler). Datenbanken sind in der Regel kein Ausweg, da Daten auch nach 20 Jahren noch in etwa der gleichen Form vorliegen. Fachwissen in der Anfangsphase lohnt sich.

Projekte geraten häufig in Schwierigkeiten, weil sie diese Personen erst einstellen, wenn die Datenbank 100.000.000 Datensätze enthält und langsam ausgeführt wird. Oder sie beschuldigen das Tool, schlecht zu sein (kein SQL Server ist nicht langsam, wenn Sie richtig entwerfen), nicht ihre Entwurfsinkompetenz.

Die politisch korrekte Antwort: Es kommt darauf an. SQL-Kenntnisse haben überhaupt keinen Wert, wenn der Entwickler nie mit relationalen Datenbanken arbeitet (und in der heutigen Zeit von NoSQL-Anwendungen ist dies sehr wahrscheinlich).

Zweitens, wenn es einen DBA oder einen Vollzeitschreiber für Abfragen gibt (unabhängig vom Titel), ist das Verständnis ebenfalls von geringerer Bedeutung.

Es ist nur dann wirklich wichtig, wenn der Entwickler ein Alleskönner sein muss und in seinen Projekten die Verwendung einer relationalen Datenbank erforderlich ist (z. B. in altmodischen Webanwendungen oder beim Verbinden mit vorhandenen Datenbanken).

Meine persönliche Meinung: Nein. Ein erfahrener Softwareentwickler sollte in der Lage sein, eine neue Fähigkeit (z. B. SQL) zu erlernen, wenn und wann dies erforderlich ist, und nicht standardmäßig. Flexibilität und die Fähigkeit zu lernen und zu verstehen ist es, was einen guten Entwickler von einem guten unterscheidet. Die "Golden Hammer" -Regel gilt auch - wenn Sie einen Entwickler mit umfangreichen SQL-Kenntnissen haben, wird dieser Entwickler höchstwahrscheinlich das Tool herausholen, das er am besten kennt - relationale Datenbanken -, um zu versuchen, jedes Problem zu lösen, obwohl dies nicht unbedingt der Fall ist die beste Lösung sein. Dies gilt natürlich auch für NoSQL-Befürworter;).

Das richtige Werkzeug für den richtigen Job auszuwählen, ist das, was ein erfahrener Programmierer wissen sollte.

Schauen Sie sich diese Wikipedia-Einführung in die Computerprogrammierung an:

Computerprogrammierung (oft als Programmieren oder Codieren abgekürzt) ist der Prozess des Entwerfens, Schreibens, Testens, Debuggens / Fehlersuchens und Verwaltens des Quellcodes von Computerprogrammen. Dieser Quellcode ist in einer Programmiersprache geschrieben. Der Zweck der Programmierung besteht darin, ein Programm zu erstellen, das ein bestimmtes gewünschtes Verhalten aufweist.

Datenbankabfragen haben ihre eigenen Sprachen, sie können entworfen, getestet, fehlerbereinigt und verwaltet werden. Ziel einer Datenbankabfrage ist es, Ihnen zu ermöglichen, die benötigten Informationen so abzurufen, wie Sie sie benötigen.

Also ich denke, dass es definitiv programmiert.

Ein guter Softwareentwickler mit Hintergrund in Unternehmens- und Geschäftsanwendungen (EDIT: speziell in Projekten, die ein RDBMS verwenden) sollte über Expertenwissen zum Schreiben relationaler Datenbankabfragen im Standardformat verfügen. Außerdem sollten sie in der Lage sein, komplexe Schemata zu verstehen und Schemadesigns mit mindestens mäßiger Komplexität vorzuschlagen.

Extrem fortgeschrittenes oder kompliziertes Schema-Design sollte der Bereich eines Datenmodellierers oder funktionalen Architekten sein.

Dies bedeutet nicht, dass Datenbankprogrammierer auch keinen Platz haben. Komplexe gespeicherte Prozeduren, komplexe und effiziente Abfragen sowie das Design und die Architektur von Software auf Datenbankebene, die auf die einzigartigen Tools und Angebote eines einzelnen Datenbankanbieters (z. B. Oracle, MySQL, SQLServer usw.) ausgerichtet sind, sollten nach Möglichkeit professioneller Software überlassen werden Ingenieure, die Erfahrung mit diesen hochspezialisierten und komplizierten Angeboten haben.

Die überwiegende Mehrheit der Geschäfts- und Unternehmenssysteme rechtfertigt jedoch meiner Meinung nach nicht den Bedarf an Datenmodellierern und spezialisierten Datenbankprogrammierern, aber ich habe bereits an solchen Projekten gearbeitet, die GROSS von dem Wissen und der Sachkenntnis profitiert haben, die diese Leute an den Tisch gebracht haben.

Andere haben Ihre Frage zu Datenbankabfragen bereits beantwortet.

Datenbankdesign ist eine bestimmte Art von Design. Es ist nicht so schwer zu lernen, aber der typische Datenbankdesigner hat nicht so viele Möglichkeiten, eine Datenbank zu entwerfen.

Der Ort, an dem ich arbeite, hat jetzt das gleiche Datenbankdesign wie 1970. Wir haben die Datenbank von IDMS nach DB2 verschoben, aber es ist das gleiche Netzwerkdatenbankdesign. In den 9 Jahren, in denen ich hier gearbeitet habe, hatte ich die Möglichkeit, 5 neue DB2-Tabellen zu erstellen.

Ich vermute, dass es nur sehr wenige Arbeitsplätze mit einem dedizierten Datenbankdesigner gibt. Ich würde also zu dem Schluss kommen, dass Datenbankdesign als Teil des Repertoires eines Senior Analysten gilt.

Ich bin ehrlich gesagt erstaunt, dass so viele von uns denken, dass sich jede Entwicklung um eine Datenbank und eine SQL-Datenbank dreht.

Andere haben die vielen Möglichkeiten erwähnt, mit denen wir die Unübersichtlichkeit von SQL in unseren Jobs vermeiden können, selbst wenn wir (indirekt) mit Datenbanken arbeiten, aber was ist mit all den Entwicklern, die die Firmware für die 101 elektrischen Produkte schreiben, die wir beide besitzen? Was ist mit den Jungs, die sich auf Echtzeitüberwachung spezialisiert haben?

Ich würde vorschlagen, dass die Mehrheit der heutigen Entwickler SQL-Kenntnisse in unterschiedlichem Maße besitzt, aber es ist weit davon entfernt, ein Barometer für ihre Fähigkeiten zu sein.

Ich denke, Sie überschätzen die Bedeutung von Datenbanken in Software.

Viele Anwendungsklassen sind nicht datenbankzentriert.

Benötigen wir jetzt ein DBMS in Textverarbeitungsprogrammen und Bildbearbeitungsprogrammen? Was ist mit Spracherkennung und Computer-Vision-Systemen, die viele Datenbankabfragen enthalten?

Und was ist mit linearen Video-Editoren und Videospiel-Physik-Engines?

Ich würde von einem Generalisten-Entwickler erwarten, dass er zumindest ein Bewusstsein für Datenbanktechnologien (relational oder anderweitig) hat und in der Lage ist, die Vor- und Nachteile ihrer Verwendung zu diskutieren. Ansonsten fürchte ich, sie wissen nur, wie man Daten in flache Dateien packt.

Ich denke nicht, dass das Schreiben von Abfragen eine zentrale Anforderung für Programmierer sein sollte. Dennoch glaube ich, dass ein Programmierer, der Abfragen schreiben und Datenbanken entwerfen kann, für eine Organisation wertvoller wäre.

Wenn dieser Programmierer jedoch nur Abfragen vom Typ "select * from tblxxxx" schreiben kann, würde ich diesen Programmierer nicht als Experten betrachten. Ebenso würde ich diesen Programmierer nicht als Experten betrachten, wenn die von diesem Programmierer entworfene Datenbank Eins-zu-Viele-Beziehungen in eine Tabelle statt in zwei Tabellen legt.

Hier ist, wie ich dies Nicht-IT-Leuten erkläre. IT-Experten spezialisieren sich in bestimmten Bereichen ähnlich wie Tischler, Elektriker und Installateure in den dort angesehenen Bereichen. Sie neigen dazu, einige der Fähigkeiten zu überlappen, sind jedoch keine Experten in allen Bereichen. Ein Elektriker kann einfache Tischlerarbeiten mit Zuversicht ausführen, würde es aber nicht gutheißen, komplexe Strukturen in Angriff zu nehmen.

Ebenso kann und sollte ein Programmierer wissen, wie man einfache Abfragen und Datenbankentwürfe schreibt oder manipuliert, aber es wird nicht erwartet, dass er eine komplexe Datenstruktur entwirft.

Wenn Sie sich in unserer Abteilung umschauen, kommt es darauf an:

• Unsere Desktop- / Web- / Server-Entwickler . Zumindest erforderlich, um grundlegende bis fortgeschrittene rohe Aussagen je nach ihrer Spezialität zu schreiben. Zur Optimierung haben wir einige spezialisierte DB-Administratoren.
• Unsere Embedded-Programmierer . Nicht wenige kamen an "select * from mytable" nicht vorbei. Dies änderte sich jedoch auch in den letzten Monaten mit der Einführung von sqllite in ihren Projekten.