Professionelle MySQL-Entwicklungsdesignspezifikationen und SQL-Schreibspezifikationen

Professionelle MySQL-Entwicklungsdesignspezifikationen und SQL-Schreibspezifikationen

Im Prozess der Teamentwicklung ist die Formulierung interner Entwicklungs- und Designspezifikationen für die Stabilität des Projekts, die Effizienz des Codes und die einfache Verwaltung von entscheidender Bedeutung.

Hier veröffentlichen wir eine Liste mit MySQL-Entwicklungsdesignspezifikationen, darunter Tabellendesignspezifikationen, Felddesignspezifikationen und SQL-Schreibspezifikationen.

Benennungskonventionen für Datenbankobjekte

Datenbankobjekte

Die Objekte der Benennungsstandards beziehen sich auf die Benennungskonventionen von Datenbank SCHEMA, Tabelle TABLE, Index INDEX, Einschränkung CONSTRAINTS usw.

Benennungsprinzipien für Datenbankobjekte

Verwenden Sie aussagekräftige englische Wörter im Namen und trennen Sie die Wörter durch Unterstriche.

In Namen dürfen nur englische Buchstaben, Zahlen und Unterstriche verwendet werden

Vermeiden Sie die Verwendung von reservierten MySQL-Wörtern wie „Anruf“, „Gruppe“ usw.

Alle Datenbankobjekte verwenden Kleinbuchstaben

Datenbank-Namenskonventionen

Der Datenbankname darf nicht länger als 30 Zeichen sein.

Der Datenbankname muss der englische Projektname oder eine aussagekräftige Abkürzung sein

Der Standardzeichensatz und die Sortierklauseln müssen beim Erstellen der Datenbank hinzugefügt werden. Der Standardzeichensatz ist UTF8 (der migrierte Dumbo verwendet utf8mb4)

Namen sollten klein geschrieben sein

Benennungskonventionen für Tabellen

Tabellen im selben Modul sollten möglichst dasselbe Präfix verwenden und die Tabellennamen sollten so aussagekräftig wie möglich sein.

Mehrere Wörter werden durch Unterstriche (_) getrennt.

Tabellennamen dürfen nicht länger als 30 Zeichen sein

Gewöhnliche Tabellennamen beginnen mit t_, was Tabelle bedeutet. Die Namensregel lautet t_Modulname (oder aussagekräftige Abkürzung)_+Tabellenname

Temporäre Tabelle (Zwischentabelle, die vorübergehend von Betriebs-, Entwicklungs- oder Datenbankpersonal zur Datenerfassung verwendet wird) Benennungsregeln: Fügen Sie ein temporäres Präfix und ein 8-stelliges Zeitsuffix hinzu (tmp_test_user_20181109).

Benennungsregeln für Sicherungstabellen (DBA-Sicherung wird als Zwischentabelle zum Speichern historischer Daten verwendet): Fügen Sie das Bak-Präfix und das 8-stellige Zeitsuffix hinzu (bak_test_user_20181109).

Namen sollten klein geschrieben sein

Konventionen für die Feldbenennung

Feldnamen müssen englische Wörter oder Abkürzungen sein, die ihre tatsächliche Bedeutung darstellen, und Wörter müssen mit Unterstrichen (_) verbunden sein.

Felder mit gleicher Bedeutung müssen in den Tabellen den gleichen Namen haben

Feldnamen dürfen nicht länger als 30 Zeichen sein.

Benennungskonventionen für Benutzer

Das in der Produktion verwendete Benutzernamensformat ist code_application

Die Benennungsregel für schreibgeschützte Benutzer lautet read_application

Spezifikationen für den Datenbankobjektentwurf

Auswahl der Speicher-Engine

Wenn keine besonderen Anforderungen bestehen, muss die InnoDB-Speicher-Engine verwendet werden

Zeichensatzauswahl

Wenn keine besonderen Anforderungen bestehen, muss utf8 oder utf8mb4 verwendet werden

Spezifikationen für das Tabellendesign

Die Verknüpfungen zwischen Datenbanktabellen, die verschiedenen Anwendungen entsprechen, sollten so weit wie möglich reduziert werden. Fremdschlüssel dürfen nicht zum Verknüpfen von Tabellen verwendet werden. Dies stellt die Unabhängigkeit der Tabellen, die Komponenten entsprechen, sicher und bietet die Möglichkeit zur Rekonstruktion des Systems oder der Tabellenstruktur.

Der Tabellenentwurf sollte nicht für das gesamte System erfolgen, sondern auf Grundlage der Komponenten in der Systemarchitektur und der von jeder Komponente gehandhabten Aufgaben.

Die Tabelle muss einen PK haben

Ein Feld hat nur eine Bedeutung

Die Tabelle darf keine doppelten Spalten enthalten

Komplexe Datentypen (Arrays, benutzerdefiniert usw.) sind nicht zulässig

Die Datentypen der zu verknüpfenden Felder (Join-Schlüssel) müssen absolut konsistent sein, um implizite Konvertierungen zu vermeiden.

Das Design sollte mindestens die dritte Normalform erfüllen und die Datenredundanz minimieren. Einige spezielle Szenarien ermöglichen ein denormalisiertes Design, aber das Design redundanter Felder muss während der Projektüberprüfung erläutert werden.

Das TEXT-Feld muss in einer separaten Tabelle platziert und über einen PK mit der Haupttabelle verknüpft werden. Wenn kein besonderer Bedarf besteht, sind TEXT- und BLOB-Felder verboten.

Tabellen, die regelmäßig abgelaufene Daten löschen (oder übertragen) müssen, können durch das Aufteilen von Tabellen gelöst werden

Die Anzahl der Felder in einer einzelnen Tabelle sollte nicht zu groß sein. Es wird empfohlen, dass die maximale Anzahl 50 nicht überschreitet.

Wenn MySQL große Tabellen verarbeitet, lässt die Leistung erheblich nach. Daher wird empfohlen, die physische Größe einer einzelnen Tabelle auf 16 GB zu begrenzen und die Daten in der Tabelle auf 20 Millionen zu begrenzen.

Wenn das Datenvolumen oder der Datenzuwachs bereits in der frühen Planungsphase groß ist, sollte die Strategie zur Tabellenaufteilung in die Entwurfsüberprüfung einbezogen werden.

Ohne besondere Anforderungen ist die Verwendung von Partitionstabellen strengstens verboten

Felddesignspezifikationen

INT: Wenn kein besonderer Bedarf besteht, verwenden Sie den Typ UNSIGNED INT zum Speichern ganzer Zahlen. Die Zahl nach dem Integer-Feld stellt die Anzeigelänge dar

DATETIME: Alle Felder, die auf die Uhrzeit (Stunde, Minute und Sekunde) genau sein müssen, sollten den Typ DATETIME und nicht TIMESTAMP verwenden.

VARCHAR: Alle Zeichenfolgen mit dynamischer Länge verwenden den Typ VARCHAR. Felder mit begrenzten Kategorien, wie z. B. Status, verwenden auch Zeichenfolgen, die die tatsächliche Bedeutung klar ausdrücken können, und sollten nicht durch Zahlen wie INT ersetzt werden; VARCHAR(N), N stellt die Anzahl der Zeichen und nicht die Anzahl der Bytes dar. Beispielsweise kann VARCHAR(255) bis zu 255 Zeichen speichern (einschließlich englischer Buchstaben, chinesischer Schriftzeichen, Sonderzeichen usw.). Allerdings sollte N möglichst klein sein, da die maximale Länge aller VARCHAR-Felder einer MySQL-Tabelle 65535 Byte beträgt und die Anzahl der gespeicherten Zeichen durch den gewählten Zeichensatz bestimmt wird. Beispielsweise erfordert UTF8 maximal 3 Bytes zum Speichern eines Zeichens. Daher sollte varchar beim Speichern von Zeichen, die 3 Bytes beanspruchen, 21845 Zeichen nicht überschreiten. Gleichzeitig wird beim Ausführen von Speicheroperationen wie Sortieren und Erstellen temporärer Tabellen die Länge N zum Anfordern von Speicher verwendet. (Sofern kein besonderer Bedarf besteht, darf ein einzelnes Varchar-Feld grundsätzlich nicht mehr als 255 Zeichen enthalten)

TEXT: Der Typ TEXT kann nur zum Speichern von Zeichendaten verwendet werden, wenn die Anzahl der Zeichen 20.000 überschreiten kann, da alle MySQL-Datenbanken den UTF8-Zeichensatz verwenden. Alle Felder mit dem Typ TEXT müssen von der Originaltabelle getrennt und zusammen mit dem Primärschlüssel der Originaltabelle in einer anderen Tabelle gespeichert werden. Sofern kein besonderer Bedarf besteht, ist Entwicklern die Verwendung der Typen MEDIUMTEXT, TEXT und LONGTEXT strengstens untersagt.

Für eine genaue Speicherung von Gleitkommadaten muss DECIMAL verwendet werden und FLOAT und DOUBLE sind strengstens verboten.

Sofern kein besonderer Bedarf besteht, ist Entwicklern die Verwendung von BLOB-Typen strengstens untersagt.

Wenn kein besonderer Bedarf besteht, wird empfohlen, das Attribut NOT NULL für das Feld zu verwenden. Anstelle von NULL kann der Standardwert verwendet werden.

Der Auto-Increment-Feldtyp muss eine Ganzzahl und UNSIGNED sein. Der empfohlene Typ ist INT oder BIGINT. Das Auto-Increment-Feld muss der Primärschlüssel oder ein Teil des Primärschlüssels sein.

Spezifikationen für den Indexentwurf

Der Index muss auf einer Spalte mit hoher Selektivität erstellt werden. Die Selektivität wird wie folgt berechnet: select count(distinct(col_name))/count(*) from tb_name; wenn das Ergebnis kleiner als 0,2 ist, wird nicht empfohlen, einen Index auf dieser Spalte zu erstellen, da dies sonst höchstwahrscheinlich die SQL-Ausführung verlangsamt.

Das erste Feld des zusammengesetzten Index muss in der Where-Bedingung stehen. Bei mehreren Feldern, die einen zusammengesetzten Index bilden müssen, empfiehlt es sich, das Feld mit der hohen Selektivität an den Anfang zu setzen.

Fremdschlüssel sind nicht erlaubt

Wenn Sie einen Index für ein Feld vom Typ „Text“ erstellen müssen, müssen Sie einen Präfixindex verwenden.

Theoretisch sollte die Anzahl der Indizes für eine einzelne Tabelle auf 5 begrenzt werden. Wenn Sie häufig und in großen Mengen Tabellen einfügen oder aktualisieren, sollten Sie so wenig Indizes wie möglich erstellen.

Die Felder ORDER BY, GROUP BY und DISTINCT müssen nach dem Index hinzugefügt werden, um einen abdeckenden Index zu bilden.

Versuchen Sie, Btree-Indizes anstelle anderer Indextypen zu verwenden.

Konstruktionsspezifikationen einschränken

PK sollte geordnet und bedeutungslos sein, von Entwicklern so weit wie möglich angepasst werden, so kurz wie möglich sein und eine automatisch inkrementierende Sequenz verwenden.

Wenn in der Tabelle zusätzlich zum PK ein Unique Constraint vorhanden ist, können Sie in der Datenbank einen Unique Constraint-Index mit „uidx_“ als Präfix erstellen.

PK-Felder können nicht aktualisiert werden.

Die Erstellung von Fremdschlüsseleinschränkungen ist verboten. Fremdschlüsseleinschränkungen werden von der Anwendung gesteuert.

Sofern nicht anders erforderlich, müssen alle Felder mit Einschränkungen ungleich NULL hinzugefügt werden, das heißt, not null .

Sofern nicht anders erforderlich, müssen alle Felder Standardwerte haben.

SQL-Schreibstandards

Vermeiden Sie möglichst die Verwendung select * . Die Verwendung von select * in Join-Anweisungen kann dazu führen, dass Abfragen, die nur auf den Index zugreifen müssen, um abgeschlossen zu werden, zur Tabelle zurückkehren müssen, um Daten abzurufen.

Es ist strengstens verboten, select * from table ohne Where-Bedingung zu verwenden.

Wenn Texttypfelder in MySQL gespeichert werden, werden sie nicht zusammen mit Datensätzen gespeichert, die aus Feldern anderer gängiger Feldtypen bestehen, und die Leseleistung selbst ist nicht so gut wie die von gängige Feldblöcke. Wenn Sie das Textfeld nicht abrufen müssen und select * verwenden, verbraucht das SQL, das dieselbe Funktion abschließt, viel mehr IO und die IO-Effizienz des hinzugefügten Teils ist ebenfalls geringer.

Sie können verwandte Funktionen auf die extrahierten Felder anwenden, Sie sollten jedoch die Verwendung von Funktionen mit unsicheren Ergebnissen wie now() , rand() , sysdate() , current_user() usw. vermeiden. Die Anwendung jeglicher Funktionen, einschließlich Datentypkonvertierungsfunktionen, auf die Filterbedingungsfelder in der Where-Bedingung ist strengstens untersagt.

Alle verbundenen SQL-Anweisungen müssen mit Join ... On ... verbunden werden und dürfen nicht direkt mit der normalen Methode der Where-Bedingung verbunden werden. Für äußere Verknüpfungen in SQL-Anweisungen können Sie die Verknüpfungsmethode Left Join On verwenden. Alle äußeren Verknüpfungen sollten als Left Join statt als Right Join geschrieben werden.

Alle Paging-Abfrageanweisungen müssen Sortierbedingungen enthalten, es sei denn, die Anwendung fordert ausdrücklich an, keine Sortierung zur zufälligen Anzeige von Daten zu verwenden.

Mathematische oder funktionale Operationen auf Indexspalten sind in WHERE-Bedingungen streng verboten.

Ersetzen Sie „oder“ durch „ in() / union und stellen Sie sicher, dass die Anzahl der „ins“ kleiner als 300 ist.

Es ist streng verboten, das Präfix % für Fuzzy-Präfixabfragen zu verwenden: wie etwa: select id,val from table where val like '%name'; Sie können %-Fuzzy-Suffixabfragen verwenden, wie etwa: select id,val from table where val like 'name%'

Es ist streng verboten INSERT ON DUPLICATE KEY UPDATE , REPLACE INTO und INSERT IGNORE zu verwenden.

Dieser Artikel ist nur ein Ausgangspunkt. Jedes Team hat seine eigenen Entwicklungs- und Designspezifikationen. MySQL-Entwicklungs- und Designspezifikationen sind nicht auf diese beschränkt. Ich hoffe, dieser Artikel wird Sie inspirieren.

Das könnte Sie auch interessieren:
  • Benennung und Designspezifikationen für MySQL-Datenbanken
  • Kennen Sie die häufigsten MySQL-Designfehler?

<<:  JavaScript, um das Bild mit der Maus zu bewegen

>>:  JavaScript generiert dynamisch eine Tabelle mit Zeilenlöschfunktion

Artikel empfehlen

Wissen Sie, wie Sie mit Vue-Cropper Bilder in Vue zuschneiden?

Inhaltsverzeichnis 1. Installation: 2. Verwendung...

Beispiel für den Aufbau eines Jenkins-Dienstes mit Docker

Ziehen Sie das Bild root@EricZhou-MateBookProX: D...

Detaillierte Erklärung des Sticky Position-Attributs in CSS

Beim Entwickeln mobiler Apps stoßen Sie häufig au...

Detaillierte Erläuterung der Javascript-Wissenspunkte

Inhaltsverzeichnis 1. Grundlegende Einführung in ...

So schreiben Sie den Nofollow-Tag und verwenden ihn

Das „nofollow“-Tag wurde vor einigen Jahren von G...

So installieren Sie MySQL 5.7 unter Windows

Laden Sie zuerst die komprimierte Version von MyS...

Stellen Sie IE8 so ein, dass Code im IE7-Stil verwendet wird

<meta http-equiv="x-ua-kompatibel" co...

Docker entfernt abnormale Containervorgänge

Dieser Neuling ist auf ein solches Problem gestoß...

Detaillierte Installation und Verwendung von RocketMQ in Docker

Um nach RocketMQ-Images zu suchen, können Sie auf...

JavaScript zum Erzielen eines einfachen Drag-Effekts

In diesem Artikel wird der spezifische JavaScript...

Detailliertes Tutorial zur MySQL-Installation und -Konfiguration

Inhaltsverzeichnis Installationsfreie Version von...

Docker-Konfiguration Alibaba Cloud Container Service-Betrieb

Konfigurieren des Alibaba Cloud Docker Container ...

Der Unterschied zwischen VOLUME und docker -v in Dockerfile

Es gibt offensichtliche Unterschiede zwischen der...