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?
|