Ob es uns gefällt oder nicht, viele, wenn nicht die meisten von uns Entwicklern arbeiten entweder regelmäßig mit Datenbanken oder müssen eines Tages mit einer arbeiten. Angesichts des Ausmaßes an Missbrauch und Missbrauch in freier Wildbahn und der Menge an datenbankbezogenen Fragen, die jeden Tag auftauchen, kann man mit Recht sagen, dass es bestimmte Konzepte gibt, die Entwickler kennen sollten - auch wenn sie nicht entwerfen oder damit arbeiten Datenbanken heute. So:

Welche wichtigen Konzepte sollten Entwickler und andere Softwareprofis über Datenbanken wissen?

Richtlinien für Antworten:

Halte deine Liste kurz.
Ein Konzept pro Antwort ist am besten.

Sei genau .
"Datenmodellierung" mag eine wichtige Fähigkeit sein , aber was bedeutet das genau?

Erläutern Sie Ihre Gründe.
Warum ist Ihr Konzept wichtig? Sagen Sie nicht nur "Indizes verwenden". Fallen Sie nicht in "Best Practices". Überzeugen Sie Ihr Publikum, mehr zu erfahren.

Upvote-Antworten, denen Sie zustimmen.
Lesen Sie zuerst die Antworten anderer Leute. Eine hochrangige Antwort ist eine effektivere Aussage als zwei niedrigrangige. Wenn Sie weitere hinzufügen möchten, fügen Sie entweder einen Kommentar hinzu oder verweisen Sie auf das Original.

Stimmen Sie etwas nicht ab, nur weil es für Sie persönlich nicht gilt.
Wir arbeiten alle in verschiedenen Bereichen. Ziel ist es, Datenbankanfängern eine Anleitung zu geben, um ein fundiertes und umfassendes Verständnis des Datenbankdesigns und der datenbankgesteuerten Entwicklung zu erlangen, und nicht um den Titel des Wichtigsten zu konkurrieren.

Das allererste, was Entwickler über Datenbanken wissen sollten, ist Folgendes: Wofür sind Datenbanken gedacht ? Weder wie sie funktionieren, noch wie Sie eine erstellen oder wie Sie Code schreiben, um die Daten in einer Datenbank abzurufen oder zu aktualisieren. Aber wofür sind sie?

Leider ist die Antwort auf diese Frage ein sich bewegendes Ziel. In der Blütezeit der Datenbanken in den 1970er bis frühen 1990er Jahren dienten Datenbanken dem Datenaustausch. Wenn Sie eine Datenbank verwendet haben und keine Daten geteilt haben, waren Sie entweder an einem akademischen Projekt beteiligt oder Sie haben Ressourcen verschwendet, einschließlich sich selbst. Das Einrichten einer Datenbank und das Zähmen eines DBMS waren solch monumentale Aufgaben, dass die Amortisation in Bezug auf mehrfach genutzte Daten enorm sein musste, um der Investition zu entsprechen.

In den letzten 15 Jahren wurden Datenbanken zum Speichern der persistenten Daten verwendet, die nur einer Anwendung zugeordnet sind. Das Erstellen einer Datenbank für MySQL , Access oder SQL Server ist so routinemäßig geworden, dass Datenbanken fast zu einem Routineteil einer normalen Anwendung geworden sind. Manchmal wird diese anfänglich begrenzte Mission durch Mission Creep nach oben gedrückt, da der tatsächliche Wert der Daten offensichtlich wird. Leider scheitern Datenbanken, die für einen bestimmten Zweck entwickelt wurden, oft dramatisch, wenn sie in eine unternehmensweite und unternehmenskritische Rolle versetzt werden.

Das zweite, was Entwickler über Datenbanken lernen müssen, ist die gesamte datenzentrierte Sicht der Welt. Die datenzentrierte Weltanschauung unterscheidet sich stärker von der prozessorientierten Weltanschauung als alles, was die meisten Entwickler jemals gelernt haben. Im Vergleich zu dieser Lücke ist die Lücke zwischen strukturierter Programmierung und objektorientierter Programmierung relativ gering.

Das dritte, was Entwickler zumindest in einer Übersicht lernen müssen, ist die Datenmodellierung, einschließlich konzeptioneller Datenmodellierung, logischer Datenmodellierung und physischer Datenmodellierung.

Die konzeptionelle Datenmodellierung ist eine wirklich datenorientierte Anforderungsanalyse.

Die logische Datenmodellierung ist im Allgemeinen die Anwendung eines bestimmten Datenmodells auf die Anforderungen, die bei der konzeptionellen Datenmodellierung ermittelt wurden. Das relationale Modell wird weitaus häufiger verwendet als jedes andere spezifische Modell, und Entwickler müssen das relationale Modell auf jeden Fall lernen. Das Entwerfen eines leistungsfähigen und relevanten relationalen Modells für eine nicht triviale Anforderung ist keine triviale Aufgabe. Sie können keine guten SQL-Tabellen erstellen, wenn Sie das relationale Modell falsch verstehen.

Die Modellierung physischer Daten ist im Allgemeinen DBMS-spezifisch und muss nicht detailliert erlernt werden, es sei denn, der Entwickler ist auch der Datenbank-Builder oder der DBA. Was Entwickler verstehen müssen, ist das Ausmaß, in dem das physische Datenbankdesign vom logischen Datenbankdesign getrennt werden kann, und das Ausmaß, in dem die Erstellung einer Hochgeschwindigkeitsdatenbank nur durch Optimieren des physischen Designs erreicht werden kann.

Das nächste, was Entwickler lernen müssen, ist, dass Geschwindigkeit (Leistung) zwar wichtig ist, andere Messgrößen für die Designgüte jedoch noch wichtiger sind , z. B. die Möglichkeit, den Umfang der Datenbank später zu überarbeiten und zu erweitern, oder die Einfachheit der Programmierung.

Schließlich muss jeder, der mit Datenbanken herumspielt , verstehen, dass der Wert von Daten häufig das System überdauert, das sie erfasst hat .

Wütend!

Gute Frage. Das Folgende sind einige Gedanken in keiner bestimmten Reihenfolge:

1. Eine Normalisierung auf mindestens die zweite Normalform ist wesentlich.

2. Die referenzielle Integrität ist ebenfalls von entscheidender Bedeutung, da die Lösch- und Aktualisierungsaspekte ordnungsgemäß berücksichtigt werden.

3. Gute und ordnungsgemäße Verwendung der Prüfbedingungen. Lassen Sie die Datenbank so viel wie möglich arbeiten.

4. Verteilen Sie die Geschäftslogik nicht sowohl in der Datenbank als auch im Code der mittleren Ebene. Wählen Sie das eine oder andere aus, vorzugsweise im Code der mittleren Ebene.

5. Entscheiden Sie sich für einen konsistenten Ansatz für Primärschlüssel und Clusterschlüssel.

6. Nicht über Index. Wählen Sie Ihre Indizes mit Bedacht aus.

7. Konsistente Benennung von Tabellen und Spalten. Wählen Sie einen Standard und bleiben Sie dabei.

8. Begrenzen Sie die Anzahl der Spalten in der Datenbank, die Nullwerte akzeptieren.

9. Lassen Sie sich nicht von Auslösern mitreißen. Sie haben ihren Nutzen, können aber die Dinge in Eile komplizieren.

10. Seien Sie vorsichtig mit UDFs. Sie sind großartig, können jedoch Leistungsprobleme verursachen, wenn Sie nicht wissen, wie oft sie in einer Abfrage aufgerufen werden.

11. Holen Sie sich Celkos Buch über Datenbankdesign. Der Mann ist arrogant, kennt sich aber aus.

Zunächst müssen Entwickler verstehen, dass Datenbanken etwas zu wissen haben. Es sind nicht nur magische Geräte, auf denen Sie SQL eingeben und Ergebnismengen herausholen, sondern sehr komplizierte Softwareteile mit eigener Logik und eigenen Macken.

Zweitens, dass es unterschiedliche Datenbank-Setups für unterschiedliche Zwecke gibt. Sie möchten nicht, dass ein Entwickler historische Berichte aus einer Online-Transaktionsdatenbank erstellt, wenn ein Data Warehouse verfügbar ist.

Drittens müssen Entwickler grundlegendes SQL verstehen, einschließlich Joins.

Darüber hinaus hängt es davon ab, wie eng die Entwickler involviert sind. Ich habe in Jobs gearbeitet, in denen ich Entwickler und De-facto-DBA war, in denen die DBAs nur den Gang runter waren und in denen die DBAs in ihrem eigenen Bereich unterwegs sind. (Ich mag den dritten nicht.) Angenommen, die Entwickler sind am Datenbankdesign beteiligt:

Sie müssen die grundlegende Normalisierung verstehen, zumindest die ersten drei Normalformen. Alles darüber hinaus erhalten Sie einen DBA. Für diejenigen, die Erfahrung mit US-Gerichtssälen haben (und zufällige Fernsehsendungen zählen hier), gibt es die Mnemonik "Abhängig vom Schlüssel, dem ganzen Schlüssel und nichts als dem Schlüssel, also helfen Sie Codd."

Sie müssen eine Ahnung von Indizes haben, womit ich meine, sie sollten eine Vorstellung davon haben, welche Indizes sie benötigen und wie sie sich wahrscheinlich auf die Leistung auswirken. Dies bedeutet, keine nutzlosen Indizes zu haben, aber keine Angst zu haben, sie hinzuzufügen, um Abfragen zu unterstützen. Alles weitere (wie das Guthaben) sollte dem DBA überlassen werden.

Sie müssen die Notwendigkeit der Datenintegrität verstehen und darauf hinweisen können, wo sie die Daten überprüfen und was sie tun, wenn sie Probleme finden. Dies muss nicht in der Datenbank sein (wo es schwierig sein wird, eine aussagekräftige Fehlermeldung für den Benutzer auszugeben), sondern muss sich irgendwo befinden.

Sie sollten über die Grundkenntnisse verfügen, wie man einen Plan erhält und wie man ihn allgemein liest (zumindest genug, um festzustellen, ob die Algorithmen effizient sind oder nicht).

Sie sollten vage wissen, was ein Auslöser ist, was eine Ansicht ist und dass es möglich ist, Teile von Datenbanken zu partitionieren. Sie brauchen keine Details, aber sie müssen wissen, um den DBA nach diesen Dingen zu fragen.

Sie sollten natürlich wissen, dass sie sich nicht in Produktionsdaten, Produktionscode oder ähnliches einmischen sollen, und sie sollten wissen, dass der gesamte Quellcode in ein VCS eingeht.

Ich habe zweifellos etwas vergessen, aber der durchschnittliche Entwickler muss kein DBA sein, vorausgesetzt, es liegt ein echter DBA vor.

Grundlegende Indizierung

Ich bin immer schockiert, eine Tabelle oder eine gesamte Datenbank ohne Indizes oder willkürliche / nutzlose Indizes zu sehen. Auch wenn Sie die Datenbank nicht entwerfen und nur einige Abfragen schreiben müssen, ist es wichtig, zumindest Folgendes zu verstehen:

• Was ist in Ihrer Datenbank indiziert und was nicht:
• Der Unterschied zwischen den Arten von Scans, wie sie ausgewählt werden und wie die Art und Weise, wie Sie eine Abfrage schreiben, diese Auswahl beeinflussen kann.
• Das Konzept der Berichterstattung (warum Sie nicht einfach schreiben sollten SELECT * );
• Der Unterschied zwischen einem gruppierten und einem nicht gruppierten Index;
• Warum mehr / größere Indizes nicht unbedingt besser sind;
• Warum sollten Sie versuchen, das Umschließen von Filterspalten in Funktionen zu vermeiden?

Designer sollten sich auch der gängigen Index-Anti-Patterns bewusst sein, zum Beispiel:

• Das Access-Anti-Pattern (Indizierung jeder Spalte nacheinander)
• Das Catch-All-Anti-Pattern (ein massiver Index für alle oder die meisten Spalten, der anscheinend unter dem falschen Eindruck erstellt wurde, dass er jede denkbare Abfrage mit einer dieser Spalten beschleunigen würde).

Die Qualität der Indizierung einer Datenbank - und ob Sie sie bei den von Ihnen geschriebenen Abfragen nutzen oder nicht - ist mit Abstand der bedeutendste Teil der Leistung. 9 von 10 Fragen, die in SO und anderen Foren veröffentlicht wurden und sich über schlechte Leistung beschweren, sind ausnahmslos auf eine schlechte Indizierung oder einen nicht sargierbaren Ausdruck zurückzuführen.

Normalisierung

Es bedrückt mich immer, jemanden zu sehen, der Schwierigkeiten hat, eine übermäßig komplizierte Abfrage zu schreiben, die mit einem normalisierten Design völlig unkompliziert gewesen wäre ("Zeigen Sie mir den Gesamtumsatz pro Region.").

Wenn Sie dies von Anfang an verstehen und entsprechend gestalten, sparen Sie sich später viel Schmerz. Nach der Normalisierung ist es einfach, die Leistung zu denormalisieren. Es ist nicht so einfach, eine Datenbank zu normalisieren, die von Anfang an nicht so entworfen wurde.

Zumindest sollten Sie wissen, was 3NF ist und wie Sie dorthin gelangen. Bei den meisten Transaktionsdatenbanken ist dies eine sehr gute Balance zwischen dem einfachen Schreiben von Abfragen und der Aufrechterhaltung einer guten Leistung.

Wie Indizes funktionieren

Es ist wahrscheinlich nicht das wichtigste, aber mit Sicherheit das am meisten unterschätzte Thema.

Das Problem bei der Indizierung ist, dass SQL-Tutorials sie normalerweise überhaupt nicht erwähnen und dass alle Spielzeugbeispiele ohne Index funktionieren.

Noch erfahrenere Entwickler können ziemlich gutes (und komplexes) SQL schreiben, ohne mehr über Indizes zu wissen als " Ein Index macht die Abfrage schnell ".

Das liegt daran, dass SQL-Datenbanken als Black-Box sehr gute Arbeit leisten :

Sag mir was du brauchst (gib mir SQL), ich kümmere mich darum.

Und das funktioniert perfekt, um die richtigen Ergebnisse zu erhalten. Der Autor des SQL muss nicht wissen, was das System hinter den Kulissen tut - bis alles sooo langsam wird .....

Dann wird die Indizierung zum Thema. Aber das ist normalerweise sehr spät und jemand (eine Firma?) Leidet bereits unter einem echten Problem.

Aus diesem Grund glaube ich, dass die Indizierung das wichtigste Thema ist, das Sie bei der Arbeit mit Datenbanken nicht vergessen sollten . Leider ist es sehr leicht, es zu vergessen.

Haftungsausschluss

Die Argumente stammen aus dem Vorwort meines kostenlosen eBooks " Use The Index, Luke ". Ich verbringe viel Zeit damit, zu erklären, wie Indizes funktionieren und wie man sie richtig verwendet.

Ich möchte nur auf eine Beobachtung hinweisen - das heißt, es scheint, dass die Mehrheit der Antworten davon ausgeht, dass die Datenbank mit relationalen Datenbanken austauschbar ist. Es gibt auch Objektdatenbanken, Flatfile-Datenbanken. Es ist wichtig, die Anforderungen des jeweiligen Softwareprojekts zu bewerten. Aus Programmiersicht kann die Datenbankentscheidung bis später verzögert werden. Datenmodellierung hingegen kann frühzeitig erreicht werden und zu viel Erfolg führen.

Ich denke, Datenmodellierung ist eine Schlüsselkomponente und ein relativ altes Konzept, das jedoch von vielen in der Softwareindustrie vergessen wurde. Die Datenmodellierung, insbesondere die konzeptionelle Modellierung, kann das Funktionsverhalten eines Systems aufzeigen und als Fahrplan für die Entwicklung herangezogen werden.

Auf der anderen Seite kann der erforderliche Datenbanktyp anhand vieler verschiedener Faktoren bestimmt werden, darunter Umgebung, Benutzervolumen und verfügbare lokale Hardware wie Festplattenspeicher.

Vermeiden Sie SQL- Injection und wie Sie Ihre Datenbank sichern

Jeder Entwickler sollte wissen, dass dies falsch ist: "Das Profilieren eines Datenbankvorgangs unterscheidet sich grundlegend vom Profilieren von Code."

Es gibt ein klares Big-O im traditionellen Sinne. Wenn Sie einen EXPLAIN PLAN(oder einen gleichwertigen) Vorgang ausführen, wird der Algorithmus angezeigt. Einige Algorithmen beinhalten verschachtelte Schleifen und sind O ( n ^ 2). Andere Algorithmen beinhalten B-Tree-Lookups und sind O ( n log n ).

Das ist sehr, sehr ernst. Es ist von zentraler Bedeutung, zu verstehen, warum Indizes wichtig sind. Es ist von zentraler Bedeutung für das Verständnis der Kompromisse zwischen Geschwindigkeitsnormalisierung und Denormalisierung. Es ist von zentraler Bedeutung, zu verstehen, warum ein Data Warehouse ein Sternschema verwendet, das für Transaktionsaktualisierungen nicht normalisiert ist.

Wenn Sie sich nicht sicher sind, welchen Algorithmus Sie verwenden, gehen Sie wie folgt vor. Halt. Erläutern Sie den Plan zur Ausführung von Abfragen. Passen Sie die Indizes entsprechend an.

Auch die Konsequenz: Mehr Indizes sind nicht besser.

Manchmal verlangsamt ein Index, der sich auf eine Operation konzentriert, andere Operationen. Abhängig vom Verhältnis der beiden Vorgänge kann das Hinzufügen eines Index gute Auswirkungen haben, keine Gesamtauswirkung haben oder die Gesamtleistung beeinträchtigen.

Ich denke, jeder Entwickler sollte verstehen, dass Datenbanken ein anderes Paradigma erfordern .

Wenn Sie eine Abfrage schreiben, um an Ihre Daten zu gelangen, ist ein satzbasierter Ansatz erforderlich. Viele Menschen mit interativem Hintergrund haben damit zu kämpfen. Und doch können sie, wenn sie es annehmen, weitaus bessere Ergebnisse erzielen, auch wenn die Lösung möglicherweise nicht die ist, die sich zuerst in ihren iterativ fokussierten Köpfen präsentiert hat.

Ausgezeichnete Frage. Mal sehen, zuerst sollte niemand in Betracht ziehen, eine Datenbank abzufragen, die Joins nicht genau versteht. Das ist wie Autofahren, ohne zu wissen, wo sich Lenkrad und Bremsen befinden. Sie müssen auch Datentypen kennen und wissen, wie Sie den besten auswählen.

Eine andere Sache, die Entwickler verstehen sollten, ist, dass Sie beim Entwerfen einer Datenbank drei Dinge beachten sollten:

1. Datenintegrität - Wenn Sie sich nicht auf die Daten verlassen können, haben Sie im Wesentlichen keine Daten. Dies bedeutet, dass Sie die erforderliche Logik nicht in die Anwendung einfügen, da viele andere Quellen die Datenbank möglicherweise berühren. Einschränkungen, Fremdschlüssel und manchmal Auslöser sind für die Datenintegrität erforderlich. Versäumen Sie nicht, sie zu verwenden, weil Sie sie nicht mögen oder sich nicht die Mühe machen möchten, sie zu verstehen.

2. Leistung - Es ist sehr schwierig, eine Datenbank mit schlechter Leistung umzugestalten, und die Leistung sollte von Anfang an berücksichtigt werden. Es gibt viele Möglichkeiten, dieselbe Abfrage durchzuführen, und einige sind bekanntermaßen fast immer schneller. Es ist kurzsichtig, diese Methoden nicht zu lernen und zu verwenden. Lesen Sie einige Bücher zur Leistungsoptimierung, bevor Sie Abfragen oder Datenbankstrukturen entwerfen.

3. Sicherheit - Diese Daten sind das Blut Ihres Unternehmens und enthalten häufig persönliche Informationen, die gestohlen werden können. Erfahren Sie, wie Sie Ihre Daten vor SQL-Injection-Angriffen sowie vor Betrug und Identitätsdiebstahl schützen.

Bei der Abfrage einer Datenbank ist es leicht, die falsche Antwort zu erhalten. Stellen Sie sicher, dass Sie Ihr Datenmodell gründlich verstehen. Denken Sie daran, dass tatsächliche Entscheidungen häufig auf der Grundlage der Daten getroffen werden, die Ihre Abfrage zurückgibt. Wenn es falsch ist, werden die falschen Geschäftsentscheidungen getroffen. Sie können ein Unternehmen aus schlechten Fragen töten oder einen großen Kunden verlieren. Daten haben Bedeutung, Entwickler scheinen das oft zu vergessen.

Daten gehen fast nie verloren. Denken Sie daran, Daten im Laufe der Zeit zu speichern, anstatt nur zu erfahren, wie Sie sie heute erhalten. Diese Datenbank, die mit hunderttausend Datensätzen gut funktioniert hat, ist in zehn Jahren möglicherweise nicht mehr so ​​schön. Anwendungen dauern selten so lange wie Daten. Dies ist ein Grund, warum das Entwerfen für Leistung von entscheidender Bedeutung ist.

Ihre Datenbank benötigt wahrscheinlich Felder, die die Anwendung nicht sehen muss. Dinge wie GUIDs für die Replikation, Felder mit Datum eingefügt. usw. Möglicherweise müssen Sie auch den Verlauf der Änderungen speichern und angeben, wer sie wann vorgenommen hat, und in der Lage sein, fehlerhafte Änderungen aus diesem Lagerhaus wiederherzustellen. Überlegen Sie, wie Sie dies beabsichtigen, bevor Sie eine Website fragen, wie Sie das Problem beheben können, bei dem Sie vergessen haben, eine where-Klausel in ein Update aufzunehmen und die gesamte Tabelle zu aktualisieren.

Entwickeln Sie niemals in einer neueren Version einer Datenbank als der Produktionsversion. Entwickeln Sie niemals, niemals, niemals direkt gegen eine Produktionsdatenbank.

Wenn Sie keinen Datenbankadministrator haben, stellen Sie sicher, dass jemand Backups erstellt und weiß, wie diese wiederhergestellt werden, und dass die Wiederherstellung getestet wurde.

Datenbankcode ist Code. Es gibt keine Entschuldigung dafür, ihn nicht wie den Rest Ihres Codes in der Quellcodeverwaltung zu belassen.

Evolutionäres Datenbankdesign. http://martinfowler.com/articles/evodb.html

Diese agilen Methoden machen den Datenbankänderungsprozess überschaubar, vorhersehbar und testbar.

Entwickler sollten wissen, wie eine Produktionsdatenbank in Bezug auf Versionskontrolle, kontinuierliche Integration und automatisierte Tests umgestaltet werden kann.

Der Prozess des evolutionären Datenbankdesigns hat administrative Aspekte. Beispielsweise muss eine Spalte nach einer gewissen Lebensdauer in allen Datenbanken dieser Codebasis gelöscht werden.

Zumindest wissen, dass das Konzept und die Methoden des Datenbank-Refactorings existieren. http://www.agiledata.org/essays/databaseRefactoringCatalog.html

Die Klassifizierung und Prozessbeschreibung ermöglicht die Implementierung von Werkzeugen auch für diese Refactorings.

Aus meiner Erfahrung mit relationalen Datenbanken sollte jeder Entwickler wissen:

- Die verschiedenen Datentypen :

Die Verwendung des richtigen Typs für den richtigen Job macht Ihr DB-Design robuster, Ihre Abfragen schneller und Ihr Leben einfacher.

- Erfahren Sie mehr über 1xM und MxM :

Dies ist das Brot und die Butter für relationale Datenbanken. Sie müssen die Eins-zu-Viele- und Viele-zu-Viele-Beziehungen verstehen und sich dann gegebenenfalls bewerben.

- Das " KISS " -Prinzip gilt auch für die DB :

Einfachheit funktioniert immer am besten. Vorausgesetzt, Sie haben die Funktionsweise von DB untersucht, vermeiden Sie unnötige Komplexität, die zu Wartungs- und Geschwindigkeitsproblemen führt.

- Indizes :

Es ist nicht genug, wenn Sie wissen, was sie sind. Sie müssen verstehen, wann Sie sie verwenden müssen und wann nicht.

ebenfalls:

• Boolesche Algebra ist dein Freund
• Bilder: Speichern Sie sie nicht in der Datenbank. Fragen Sie nicht warum.
• Testen Sie DELETE mit SELECT

Ich möchte, dass alle, sowohl Datenbankadministratoren als auch Entwickler / Designer / Architekten, besser verstehen, wie eine Geschäftsdomäne richtig modelliert wird und wie dieses Geschäftsdomänenmodell in ein normalisiertes logisches Datenbankmodell, ein optimiertes physisches Modell und ein Modell abgebildet / übersetzt wird geeignetes objektorientiertes Klassenmodell, von dem jedes aus verschiedenen Gründen unterschiedlich ist (sein kann) und versteht, wann, warum und wie sie sich voneinander unterscheiden (oder unterscheiden sollten).

Ich würde sagen, starke SQL-Grundkenntnisse. Ich habe bisher viele Entwickler gesehen, die ein wenig über Datenbanken wissen, aber immer nach Tipps fragen, wie man eine recht einfache Abfrage formuliert. Abfragen sind nicht immer so einfach und unkompliziert. Sie müssen mehrere Joins (innere, linke usw.) verwenden, wenn Sie eine gut normalisierte Datenbank abfragen.

Über den folgenden Kommentar zu Walter Ms Antwort:

"Sehr gut geschrieben! Und die historische Perspektive ist großartig für Leute, die zu dieser Zeit keine Datenbankarbeit machten (dh ich)."

Die historische Perspektive ist in gewissem Sinne absolut entscheidend. "Diejenigen, die die Geschichte vergessen, sind dazu verdammt, sie zu wiederholen." Cfr XML, das die hierarchischen Fehler der Vergangenheit wiederholt, Graphendatenbanken, die die Netzwerkfehler der Vergangenheit wiederholen, OO-Systeme, die den Benutzern das hierarchische Modell aufzwingen, während jeder mit nur einem Zehntel Gehirn wissen sollte, dass das hierarchische Modell nicht für allgemeine Zwecke geeignet ist. Zweckdarstellung der realen Welt, etcetera, etcetera.

Was die Frage selbst betrifft:

Jeder Datenbankentwickler sollte wissen, dass "Relational" nicht gleich "SQL" ist. Dann würden sie verstehen, warum sie von den DBMS-Anbietern so miserabel enttäuscht werden und warum sie denselben Anbietern sagen sollten, sie sollten sich bessere Sachen einfallen lassen (z. B. DBMS, die wirklich relational sind), wenn sie weiterhin lustige Mengen davon saugen wollen Geld von ihren Kunden für solch beschissene Software).

Und jeder Datenbankentwickler sollte alles über die relationale Algebra wissen. Dann würde es keinen einzigen Entwickler mehr geben, der diese dummen Fragen "Ich weiß nicht, wie ich meinen Job machen soll und möchte, dass jemand anderes das für mich macht" zu Stack Overflow posten müsste.

Ich denke, viele technische Details wurden hier behandelt und ich möchte sie nicht ergänzen. Das einzige, was ich sagen möchte, ist eher sozial als technisch. Verlieben Sie sich nicht in die Falle "DBA kennt die besten" als Anwendungsentwickler.

Wenn Sie Leistungsprobleme mit der Abfrage haben, übernehmen Sie auch die Verantwortung für das Problem. Machen Sie Ihre eigenen Recherchen und fordern Sie die Datenbankadministratoren auf, zu erklären, was passiert und wie ihre Lösungen das Problem angehen.

Überlegen Sie sich auch Ihre eigenen Vorschläge, nachdem Sie die Recherche durchgeführt haben. Das heißt, ich versuche, eine kooperative Lösung für das Problem zu finden, anstatt Datenbankprobleme den Datenbankadministratoren zu überlassen.

Einfacher Respekt.

• Es ist nicht nur ein Repository
• Sie wissen es wahrscheinlich nicht besser als der Anbieter oder die Datenbankadministratoren
• Sie werden es nicht um 3 Uhr morgens unterstützen, wenn Führungskräfte Sie anschreien

Betrachten Sie Denormalisierung als einen möglichen Engel, nicht als den Teufel, und betrachten Sie NoSQL-Datenbanken auch als Alternative zu relationalen Datenbanken.

Ich denke auch, dass das Entity-Relation-Modell ein Muss für jeden Entwickler ist, auch wenn Sie keine Datenbanken entwerfen. So können Sie genau verstehen, worum es in Ihrer Datenbank geht.

Fügen Sie niemals Daten mit der falschen Textcodierung ein.

Sobald Ihre Datenbank mit mehreren Codierungen verschmutzt ist, können Sie am besten eine Kombination aus Heuristik und Handarbeit anwenden.

Abgesehen von der Syntax und den konzeptionellen Optionen, die sie verwenden (wie Verknüpfungen, Trigger und gespeicherte Prozeduren), ist Folgendes für jeden Entwickler, der eine Datenbank verwendet, von entscheidender Bedeutung:

Wissen Sie, wie Ihre Engine die Abfrage, die Sie schreiben, spezifisch ausführen wird.

Der Grund, warum ich das für so wichtig halte, ist einfach die Produktionsstabilität. Sie sollten wissen, wie Ihr Code funktioniert, damit Sie nicht die gesamte Ausführung in Ihrem Thread stoppen, während Sie auf den Abschluss einer langen Funktion warten. Warum sollten Sie also nicht wissen wollen, wie sich Ihre Abfrage auf die Datenbank, Ihr Programm und möglicherweise sogar auswirkt? der Kellner?

Dies ist tatsächlich etwas, das mein Forschungs- und Entwicklungsteam öfter getroffen hat als fehlende Semikolons oder ähnliches. Die Vermutung ist, dass die Abfrage schnell ausgeführt wird, da sie auf ihrem Entwicklungssystem nur wenige tausend Zeilen in den Tabellen enthält. Selbst wenn die Produktionsdatenbank dieselbe Größe hat, wird sie höchstwahrscheinlich viel häufiger verwendet und leidet daher unter anderen Einschränkungen, z. B. wenn mehrere Benutzer gleichzeitig darauf zugreifen, oder wenn bei einer anderen Abfrage an anderer Stelle etwas schief geht, was zu Verzögerungen führt das Ergebnis dieser Abfrage.

Selbst einfache Dinge wie die Auswirkungen von Verknüpfungen auf die Leistung einer Abfrage sind in der Produktion von unschätzbarem Wert. Es gibt viele Funktionen vieler Datenbank-Engines, die die Dinge konzeptionell einfacher machen, aber möglicherweise zu Leistungseinbußen führen, wenn nicht klar darüber nachgedacht wird.

Kennen Sie den Ausführungsprozess Ihres Datenbankmoduls und planen Sie ihn.

Für einen professionellen Entwickler mitten auf der Straße, der häufig Datenbanken verwendet (täglich oder fast täglich Abfragen schreiben / pflegen), sollte die Erwartung dieselbe sein wie in jedem anderen Bereich: Sie haben eine im College geschrieben .

Jeder C ++ - Geek hat im College eine String-Klasse geschrieben. Jeder Grafikfreak hat im College einen Raytracer geschrieben. Jeder Webfreak schrieb im College interaktive Websites (normalerweise bevor wir "Webframeworks" hatten). Jeder Hardware-Nerd (und sogar Software-Nerds) hat im College eine CPU gebaut. Jeder Arzt hat im College einen ganzen Leichnam seziert, auch wenn sie nur meinen Blutdruck messen und mir sagen wird, dass mein Cholesterin heute zu hoch ist. Warum sollten Datenbanken anders sein?

Leider scheinen sie heute aus irgendeinem Grund anders zu sein. Die Leute möchten, dass .NET-Programmierer wissen, wie Zeichenfolgen in C funktionieren , aber die Interna Ihres RDBMS sollten Sie nicht zu sehr betreffen .

Es ist praktisch unmöglich, das gleiche Maß an Verständnis zu erlangen, wenn man nur darüber liest oder sich von oben nach unten arbeitet. Wenn Sie jedoch ganz unten anfangen und jedes Teil verstehen, ist es relativ einfach, die Besonderheiten Ihrer Datenbank herauszufinden. Sogar Dinge, die viele Datenbankfreaks nicht zu verstehen scheinen, wie zum Beispiel die Verwendung einer nicht relationalen Datenbank.

Vielleicht ist das ein bisschen streng, besonders wenn Sie nicht am College Informatik studiert haben. Ich werde es etwas abschwächen: Sie könnten heute eine komplett von Grund auf neu schreiben . Es ist mir egal, ob Sie die Einzelheiten der Funktionsweise des PostgreSQL-Abfrageoptimierers kennen, aber wenn Sie genug wissen, um selbst einen zu schreiben, wird er sich wahrscheinlich nicht allzu sehr von dem unterscheiden, was sie getan haben. Und weißt du, es ist wirklich nicht so schwer, ein einfaches zu schreiben.

Die Reihenfolge der Spalten in einem nicht eindeutigen Index ist wichtig.

Die erste Spalte sollte die Spalte sein, deren Inhalt am unterschiedlichsten ist (dh Kardinalität).

Dies soll SQL Server dabei unterstützen, nützliche Statistiken zur Verwendung des Index zur Laufzeit zu erstellen.

Verstehe die Tools, mit denen du die Datenbank programmierst !!!

Ich habe so viel Zeit damit verschwendet, zu verstehen, warum mein Code auf mysteriöse Weise fehlgeschlagen ist.

Wenn Sie beispielsweise .NET verwenden, müssen Sie wissen, wie die Objekte im System.Data.SqlClientNamespace ordnungsgemäß verwendet werden . Sie müssen wissen, wie Sie Ihre verwaltenSqlConnection Objekte verwalten, um sicherzustellen, dass sie geöffnet, geschlossen und bei Bedarf ordnungsgemäß entsorgt werden.

Sie müssen wissen, dass es bei Verwendung von a SqlDataReadererforderlich ist, es getrennt von Ihrem zu schließen SqlConnection. Sie müssen verstehen, wie Sie Verbindungen offen halten können, um die Anzahl der Treffer auf die Datenbank zu minimieren (da diese in Bezug auf die Rechenzeit relativ teuer sind).

• Grundlegende SQL-Kenntnisse.
• Indizierung.
• Beschäftige dich mit verschiedenen Inkarnationen von DATE / TIME / TIMESTAMP.
• JDBC-Treiber für die von Ihnen verwendete Plattform.
• Umgang mit binären Datentypen ( CLOB , BLOB usw.)

Für einige Projekte ist ein objektorientiertes Modell besser.

Für andere Projekte ist ein relationales Modell besser.

Das Impedanzfehlanpassungsproblem und kennen die allgemeinen Mängel oder ORMs.

RDBMS-Kompatibilität

Überprüfen Sie, ob die Anwendung in mehr als einem RDBMS ausgeführt werden muss. Wenn ja, ist möglicherweise Folgendes erforderlich:

• Vermeiden Sie RDBMS SQL-Erweiterungen
• Auslöser beseitigen und Prozeduren speichern
• Befolgen Sie strenge SQL-Standards
• Felddatentypen konvertieren
• Ändern Sie die Transaktionsisolationsstufen

Andernfalls sollten diese Fragen separat behandelt und verschiedene Versionen (oder Konfigurationen) der Anwendung entwickelt werden.

Hängen Sie nicht von der Reihenfolge der Zeilen ab, die von einer SQL-Abfrage zurückgegeben werden.

http://www.reddit.com/r/programming/comments/azdd7/programmers_sit_your_butt_down_i_need_to_have_a/