Was sollte jeder Entwickler über Datenbanken wissen? [geschlossen]

206

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.

Aaronaught
quelle
15
Warum abstimmen, um dies zu schließen? Es ist ein Community Wikia und daher angemessen.
David
5
Ich werde für die Wiedereröffnung stimmen, wenn es geschlossen wird ... Ich würde auch gerne eine Liste der Dinge sehen, die DBAs über OOP und das Design von Anwendungs- / Systemsoftware wissen sollten (aber nicht wissen).
Charles Bretana
7
@gnovice: Das Wort "subjektiv" bezieht sich in diesem Zusammenhang auf Fragen, die ausschließlich Ansichtssache sind. "Was denkst du über Joe Celkos Buch?" - Das ist eine subjektive Frage. Diese Frage fordert objektive Informationen an, es kommt nur so vor, dass es keine einzige "richtige" Antwort gibt. Ich denke, es ist wichtig, einen Schritt zurückzutreten und zu fragen: "Ist das nur ein müßiger Scherz oder ist es für einige Entwickler nützlich?" Meine zwei Cent sowieso - es ist nicht so, als würde ich dafür Wiederholungspunkte verdienen. :-)
Aaronaught
6
Ich persönlich hasse diese Fragen. Sie belaufen sich fast immer auf persönliche Meinungen, enthalten nützliche Informationen und viele subjektive Erklärungen. Aber ich bin nicht bereit, es allein aus diesem Grund zu schließen; Es könnte halbwegs anständig sein, Aaron, wenn Sie einige Richtlinien für Antworten festlegen: Antworten zu einem Thema (was sollten Sie wissen und warum sollten Sie es wissen), keine Duplikate, Stimmen Sie ab, was Sie zustimmen ... und die meisten Bewegen Sie Ihre eigenen Meinungen in Antworten, die dies demonstrieren. So wie es aussieht, liest sich dies wie ein Blog-Beitrag oder eine Forumsdiskussion, von denen keiner etwas mit SO zu tun hat.
Shog9
4
Ich finde das ziemlich interessant: "Es ist ein Community-Wiki und daher angemessen." Wie um alles in der Welt kann ein CW es angemessen machen? Entweder ist eine Frage angemessen oder nicht, und ich denke, diese Frage ist viel zu subjektiv, um hilfreich zu sein, wenn jemand nach einer Antwort sucht. Es mag interessant sein, aber das ist nicht das einzige Merkmal, das eine Frage haben muss.
Georg Schölly

Antworten:

106

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!

Walter Mitty
quelle
Sehr gut geschrieben! Und die historische Perspektive ist großartig für Leute, die zu diesem Zeitpunkt keine Datenbankarbeit geleistet haben (dh ich).
Aaronaught
6
Schön geschrieben. Und ich denke, Ihr letzter Punkt wird viel zu oft von Leuten ignoriert, die versuchen, es einfach zu erledigen.
DaveE
1
Es gibt eine Verbindung zwischen dem, was ich geschrieben habe, und Themen wie Plan erklären, Indizieren und Datennormalisierung. Ich würde diesen Zusammenhang gerne in einer Art Diskussionsforum ausführlicher diskutieren. SO ist kein solches Forum.
Walter Mitty
1
Wenn Sie dieses Monster gefunden haben, stellen Sie sich vor, wie es sich anfühlte, es zu schreiben! Ich wollte keinen Aufsatz schreiben. Als ich anfing, schien es einfach zu fließen. Wer auch immer die Fettschrift hinzufügte, half den Lesern wirklich, IMO.
Walter Mitty
3
@Walter Sie haben alle Ihre Punkte mit Ausnahme dieses Punktes erklärt: "Das zweite, was Entwickler über Datenbanken lernen müssen, ist die gesamte datenzentrierte Weltansicht. 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. " Könnten Sie das näher erläutern? Sie haben angegeben, dass die Lücke groß ist, aber ich denke, ich möchte die datenzentrierte Ansicht und ihre Entkopplung von der Prozessansicht wirklich verstehen.
jedd.ahyoung
73

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.

Randy Minder
quelle
1
Ich möchte auf Punkt 4 näher eingehen. Dies ist ein Thema, das mich immer fasziniert hat.
Brad
9
@ David: Ich habe es immer vorgezogen, es an beiden Stellen zu platzieren. Auf diese Weise sind Sie sowohl vor Fehlern als auch vor Benutzerfehlern geschützt. Es gibt keinen Grund, jede Spalte auf Null zu setzen oder Werte außerhalb des Bereichs 1-12 in eine MonthSpalte einzufügen . Komplexe Geschäftsregeln sind natürlich eine andere Geschichte.
Aaronaught
1
@Brad - Die meisten unserer Anwendungen bei der Arbeit wurden lange vor der Einführung solider Programmierprozesse durchgeführt. Daher ist die Geschäftslogik überall verstreut. Einige davon befinden sich in der Benutzeroberfläche, andere in der mittleren Ebene und andere in der Datenbank. Es ist ein Chaos. IMO, Geschäftslogik gehört in die mittlere Ebene.
Randy Minder
2
@David - Wenn es absolut sicher ist, dass Datenbankänderungen nur in Anwendungen vorgenommen werden, haben Sie möglicherweise Recht. Dies ist jedoch wahrscheinlich ziemlich selten. Da Benutzer Daten wahrscheinlich direkt in die Datenbank eingeben, empfiehlt es sich, die Validierung auch in die Datenbank aufzunehmen. Außerdem werden einige Arten der Validierung in der Datenbank einfach effizienter durchgeführt.
Randy Minder
1
Punkt 8 ist in der Tat wichtig. Es ist sehr wichtig zu wissen, wie die Spaltentypen im Allgemeinen richtig eingestellt werden.
Chris Vest
22

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.

David Thornley
quelle
19

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.

Aaronaught
quelle
Können Sie die "Berichterstattung" näher erläutern? Ich kann sehen, warum SELECT * keine gute Angewohnheit ist, aber ich kenne die Bedeutung von "Berichterstattung" nicht und frage mich, ob es auf einen anderen Grund anspielt, SELECT * zu vermeiden.
Edmund
1
@Edmund: Ein Index deckt eine Abfrage ab, wenn alle Ausgabefelder Teil des Index sind (entweder als indizierte Spalten oder als INCLUDESpalten in SQL Server). Wenn der einzige verfügbare Index für eine bestimmte Abfrage nicht abdeckend ist, müssen alle Zeilen einzeln abgerufen werden. Dies ist eine sehr langsame Operation, und das Abfrageoptimierungsprogramm entscheidet in den meisten Fällen, dass dies nicht der Fall ist Es lohnt sich nicht und führt stattdessen einen vollständigen Index- / Tabellenscan durch. Deshalb schreiben Sie nicht SELECT *- es garantiert praktisch, dass kein Index die Abfrage abdeckt.
Aaronaught
Vielen Dank! Obwohl ich mich als PostgreSQL-Benutzer (noch?) Nicht um solche Dinge kümmern muss: Indizes enthalten keine Sichtbarkeitsinformationen, sodass Tabellentupel immer auch gescannt werden müssen. Im Allgemeinen scheint es jedoch ein ziemlich wichtiger Faktor zu sein.
Edmund
@Edmund: PostgreSQL hat möglicherweise keine INCLUDESpalten (ich kann nicht sicher sagen), aber das bedeutet nicht, dass Sie keine Spalten, die Sie abdecken möchten, in die tatsächlichen Indexdaten einfügen können. Das mussten wir in den 2000 Tagen von SQL Server tun. Die Abdeckung spielt immer noch eine Rolle, egal auf welchem ​​DBMS Sie sich befinden.
Aaronaught
16

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.

Aaronaught
quelle
14

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.

Markus Winand
quelle
12

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.

FernandoZ
quelle
Meinen Sie damit, Entitätsbeziehungsdiagramme zu erstellen?
Crosenblum
Ja ... habe ich vergessen, ERDs zu erwähnen? :-)
FernandoZ
+1 ... Aber Sie müssen erkennen, dass Sie sich auf SO befinden: Die Heimat der Klempner, die ihre Tage damit verbringen, die ORM-Impedanzfehlanpassung zu beheben, damit alles, was sie wissen, essen und denken, nicht nur relational, sondern "SQL" ist :)
SyntaxT3rr0r
11

Vermeiden Sie SQL- Injection und wie Sie Ihre Datenbank sichern

iChaib
quelle
9

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.

S.Lott
quelle
Ich hatte das Gefühl, dass es falsch verstanden würde. Was ich mit "traditionell" gemeint habe, war, dass Sie nicht wirklich die Kontrolle über die Algorithmen haben, sondern nur die Fähigkeit zu beeinflussen, welche verwendet werden. Wie auch immer, ich habe diese Sprache entfernt, da ich im Hauptbeitrag nichts übermäßig Kontroverses möchte.
Aaronaught
@ Aaron: Sie haben die Kontrolle über die Algorithmen. Dafür sind Indizes da.
S.Lott
Hmm, können Sie also ändern, welche Art von Sortieralgorithmus von der DE verwendet wird? Welche Datenstrukturen werden für den Index verwendet? Ich würde es vorziehen, nicht über diesen Punkt zu streiten, deshalb habe ich ihn herausgenommen, aber ich stehe zu der Grundidee, dass Sie beim Arbeiten mit Datenbanken im Vergleich zu Code viel weniger Kontrolle haben.
Aaronaught
@ Aaron: Weniger Kontrolle beseitigt nicht die Verpflichtung, tatsächlich zu verstehen, ob die Abfrage * O ** (* n ^ 2) oder * O ** (* n log n ) oder nur ** O ** (n) ist. Weniger Kontrolle beseitigt nicht die Verpflichtung, tatsächlich zu verstehen, was vor sich geht, und herauszufinden, wie man es kontrolliert.
S.Lott
@ S.Lott: Ich denke, wir sind hier auf der gleichen Seite, da ich eine größere Profilierungslast für Datenbanken vorgeschlagen habe - "Sie müssen wissen ... [wie] man einen Abfrageplan liest". Aber meine Bearbeitung scheint zurückgesetzt worden zu sein, also ... ich denke, sie gehört jetzt zur Community.
Aaronaught
8

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.

Rob Farley
quelle
Bitte klären Sie, was unter "satzbasiertem" Ansatz
Vivian River,
1
Sie sollten Daten als in Mengen befindlich betrachten und Ihre Probleme als potenziell durch Mengenarithmetik gelöst betrachten - bei Bedarf mit Rangfolgenfunktionen, Unterabfragen, Aggregaten usw. Viele Entwickler überlegen, was mit jeder Zeile zu tun ist, was iteratives Denken ist.
Rob Farley
8

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.

HLGEM
quelle
6

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.

George Polevoy
quelle
Ich liebe das Refactoring-Konzept, aber in Bezug auf DB sind persistente Daten das eigentliche große Problem. Das Refactoring von DB beinhaltet häufig eine Datenmigration, die in Wirklichkeit schwierig ist, insbesondere wenn Sie keine Ausfallzeiten des Systems haben. Auch Rollback ist nicht trivial. Meiner Ansicht nach sind Schwierigkeiten bei der ordnungsgemäßen / sicheren Einführung von Rollout- und Rollback-Strategien häufig ein Hindernis, um DB so leicht wie Anwendungscode umzugestalten. selbst ist es oft sinnvoll, Dinge umzugestalten, aber man muss immer Kosten / Nutzen überwiegen.
Manuel Aldana
Siehe auch Amblers 'Refactoring Databases' ( amazon.com/Refactoring-Databases-Evolutionary-Database-Design/… ).
Jonathan Leffler
5

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
Eine Axt
quelle
+1 für Bilder. Ich würde 'Bilder' durch 'BLOBs' ersetzen.
Agnel Kurian
Ich bin mir über den Teil "Einfachheit" nicht wirklich sicher. Die einfachste Datenbank ist eine riesige Tabelle mit einer Reihe von varchar(max)Spalten. Relationale Datenbanken sollten normalisiert und nicht vereinfacht werden .
Aaronaught
Ihre Bedenken werden bereits früher im Abschnitt "Datentypen" meines Beitrags behandelt. Ich bezog mich auf die (unnötige) Verwendung gespeicherter Prozeduren / Trigger / Cursor und so weiter.
Anax
5

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).

Charles Bretana
quelle
5

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.

MaxiWheat
quelle
5

Ü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.

Erwin Smout
quelle
1
Ich bin damit einverstanden, dass ein Entwickler wissen muss, wo SQL und RDM voneinander abweichen. Trotzdem kann die umsichtige Verwendung des RDM für den Datenbankdesigner von unschätzbarem Wert sein, selbst wenn die Implementierung SQL ist.
Walter Mitty
1
Falls Sie es vergessen haben, George Santayana, schrieb dieses klassische Zitat ...
Crosenblum
5

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.

HeretoLearn
quelle
gute Antwort. Wir haben jeweils einen eigenen Bereich, den wir zu jedem Problem oder jeder Lösung beitragen.
Crosenblum
5

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
gbn
quelle
3

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.

iChaib
quelle
3

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.

mikerobi
quelle
2
Was ist die "falsche Textcodierung" und wie passiert das?
Gennady Vanin Геннадий Ванин
1
@ vgv8, es passiert, wenn Ihr Client Benutzern erlaubt, Text in einer beliebigen Codierung zu senden. Sie speichern ihn blind. Wenn Sie dann eine Art Transformation oder Analyse durchführen müssen, wird Ihr Code unterbrochen, da Ihre Anwendung utf-8 annimmt, aber ein Idiot utf-16-Daten hinzugefügt hat und Ihr Programm Fehler macht oder Kauderwelsch ausspuckt.
Mikerobi
3

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.

TodPunk
quelle
3

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.

Ken
quelle
Aus dem verlinkten Joel-Artikel über C-Strings führt der folgende Ausschnitt nicht zu undefiniertem Verhalten: char * str = "* Hello!"; str [0] = strlen (str) - 1; str ist ein String-Literal und allgemein im Nur-Lese-Speicher. Sie können nicht darauf schreiben:?
HeretoLearn
Ein professioneller Datenbankexperte, gut, aber jeder Entwickler ?
Ben Aston
Ben: Jeder professionelle Entwickler, der häufig Datenbanken verwendet, ja. Sie sind wirklich nicht so schwer. Wenn Sie also nicht wissen, wie, bedeutet dies, dass Sie sich nicht einmal ein wenig Zeit genommen haben, um zu lernen, wie DBs funktionieren. Jeder Informatik-Major, mit dem ich meinen Abschluss gemacht habe, hat eine CPU entworfen und ein Betriebssystem implementiert. Eine Datenbank ist einfacher als eine dieser beiden. Wenn Sie also Zeit damit verbringen, eine zu verwenden, sehe ich keine Entschuldigung dafür, nicht zu wissen, wie sie funktionieren.
Ken
2

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.

Mike D.
quelle
-1 Ich habe keine gute Idee, Regeln wie "Die erste Spalte sollte die Spalte mit der größten Variabilität in ihrem Inhalt sein" zu befolgen. Wenn man Grundkenntnisse über die Funktionsweise von Indizes hat, ist es einfach zu sehen, wie die Reihenfolge wichtig ist und dass die Reihenfolge der Spalte von der Art und Weise abhängen sollte, wie die Tabelle abgefragt wird.
Wunder173
danke, aber wenn der Index für 3 Felder erstellt wurde, auf der Grundlage, dass eine bestimmte SQL-Abfrage diese 3 Felder in ihrer where-Klausel verwendet, kann die Reihenfolge signifikant sein und das Feld mit der höchsten Kardinalität, das zuerst \ früher erscheint, kann führen zu Leistungsverbesserungen ... oder zumindest das, was ich in einem Microsoft SQL Server-Handbuch zur Leistungsoptimierung gelesen habe. Ich habe es ausprobiert und es schien besser zu funktionieren (vor Jahren).
Mike D
2

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).

Daniel Allen Langdon
quelle
2
  • 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.)
JuanZe
quelle
1

Für einige Projekte ist ein objektorientiertes Modell besser.

Für andere Projekte ist ein relationales Modell besser.

Mark Lutton
quelle
1

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

Muhammad Soliman
quelle
1

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.

Juliano
quelle
1

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

Agnel Kurian
quelle
3
... es sei denn, es ist eine ORDER BYKlausel enthalten?
Aaronaught
Und verwenden Sie es nicht ORDER BYunnötig, da es den SQL-Server zusätzlich belastet
Vivian River