Spezifikationen für das Datenbankdesign:
1. Tischdesign-Spezifikationen
1.1 Über Tischdesign
a) Tisch Namen und Spaltennamen müssen kommentiert werden.
b) Bei der Benennung sollten aussagekräftige englische Wörter oder Abkürzungen verwendet werden, die aus mehreren Wörtern bestehen, alle in Großbuchstaben, getrennt durch „_“, und es dürfen nur englische Buchstaben und Zahlen sowie Unterstriche verwendet werden , keine Leerzeichen. Beispielsweise erlaubt USER_DETALL nicht die Verwendung der Schlüsselwörter TYPE oder STATUS als Feldnamen.
c) Die Namenslänge sollte 15 Zeichen nicht überschreiten (vermeiden Sie mehr als 20) und sollte den Geschäftsumfang des Datensatzes oder Geschäftsfunktionen widerspiegeln, wie z. B. POWER_USER (Benutzercenter). , usw.
d) Wenn der Feldtyp eine Aufzählung oder ein Boolescher Wert ist, verwenden Sie den Typ CHAR(1) (oder CHAR(2)) und geben Sie den Standardwert ein Das Statusfeld darf im Allgemeinen nicht auf 0 oder -1 gesetzt sein und die Beschreibung des Statusfelds lautet: „Status des Gruppenkaufs: 1. Gekauft 2. Erstattet“;
e) Versuchen Sie, Datumsfelder während des Designs einzubeziehen: CREATE_DATE (Erstellungsdatum), UPDATE_DATE (Aktualisierungsdatum) usw. MySQL einigt sich auf eine Eingabemethode für Datumsangaben, beispielsweise „2014-12-31 00:00:00.0“
f) Der Standardwert ist 0 für numerische Typen und 0 für Zeichenfolgen Der Wert ist '' und der Standardwert für das Datum ist '1900-01-01 00:00:00.0'.
g) Verwenden Sie bigint für die Primärschlüsselfeld-ID. Wenn in der Erstellungsanweisung eine Markierung AUTO_INCREMENT=6653864 vorhanden ist, entfernen Sie diese bitte.
h) Der Standardwert des Datumsfelds darf nicht null sein und ist im Allgemeinen auf 1970-12-31 00:00:00.0 eingestellt.
i) Das Mobiltelefonfeld, das E-Mail-Feld usw., die abgerufen werden, dürfen nicht null sein und sind die Standardeinstellung Wert ist die leere Zeichenfolge ''. Numerische Felder dürfen nicht null sein und der Standardwert ist 0.
j) Die Standardzeichenkodierung ist utf8 und die Standardspeicher-Engine ist INNODB
PS: Jede Tabelle muss ein Primärschlüsselfeld haben und Datumsfelder und Werte dürfen nicht NULL sein.
1.2 Indexdesign
1) Gewöhnlicher Index, Feldnamen verbinden, die mit IDX_ beginnen.
2) Der Anteil des doppelten Wertebereichs ist gering und das Indexierungsfeld ist wie das Feld „Create_date“ (Eingabezeit) eingerichtet.
3) Das Primärschlüsselfeld muss keinen eindeutigen Schlüssel erstellen und das Primärschlüsselfeld muss nicht separat indiziert werden.
4) Die häufig abgefragten Felder hinter der WHERE-Bedingung müssen indiziert werden, z. B. ORDER_SN (Produktnummer) der Tabelle ORDER_GOODS usw.
5) Bereichsfelder müssen nicht indiziert werden, wie z. B. das Feld IS_DEL der Tabelle SHOP_MALL usw.
6) Die zu indizierenden Felder dürfen keine Nullwerte haben, da dies sonst die Effizienz des Index beeinträchtigt.
1.3 Beispiel für eine Tabellenstruktur
Beispiel für die Tabellenerstellung Anweisung:
CREATE TABLE `SHOP_GAY` (
`ID` BIGINT(20) NOT NULL AUTO_INCREMENT COMMENT ' SHOP-ID',
`SHOP_NAME` VARCHAR(50) DEFAULT '' COMMENT 'Store-Name',
`LEGAL_PERSON_MOBILE` VARCHAR(11 ) STANDARD NULL KOMMENTAR 'Mobiltelefon juristischer Person',
`SCORE` BIGINT(20) STANDARD 0 KOMMENTAR 'Punkte',
. .. ...
`MANAGER_NAME` VARCHAR(20) DEFAULT '' COMMENT 'Name des Filialleiters',
`BRIEF` VARCHAR (500 ) DEFAULT '' COMMENT 'Store-Einführung',
`HAS_WAREHOUSE` CHAR(1) DEFAULT '0' COMMENT 'Ob es ein Lager gibt, 0: Nein; ',
`DESCRIPTION_FIT` DECIMAL(3,1) DEFAULT 0 COMMENT „Die Beschreibung stimmt überein – sie wird durch Berechnung des Durchschnitts der Bewertung aller bestellten Artikel und Bildung einer Dezimalstelle ermittelt“,
`BACKGROUND` VARCHAR(200) DEFAULT '' COMMENT 'Titelbild speichern',
`CREATED_DATE` TIMESTAMP DEFAULT CURRENT_TIMESTAMP COMMENT 'Erstellungszeit',
`UPDATED_DATE` DATETIME DEFAULT '1970-12-31 00:00:00.0' COMMENT 'Update time',
PRIMARY KEY (`ID `),
KEY IDX_MOB(LEGAL_PERSON_MOBILE),
KEY IDX_CRETIME(CREATED_DATE),
KEY IDX_UPTIME(UPDATED_DATE) )
) ENGINE=INNODB DEFAULT CHARSET=utf8 COMMENT='GAY store'
Beispiel für das Hinzufügen von Feldern:
ALTER TABLE AUTH_MALL ADD COLUMN SHORT_NAME VARCHAR(20) DEFAULT '' COMMENT 'Abkürzung des quadratischen Namens' AFTER FULL_NAME ;
Beispiel für das Ändern von Tabellenfeldern:
ALTER TABLE GATEWAY_PAYMENT_ORDER MODIFY COLUMN STAT varchar(2) DEFAULT '0'
Kommentar „Transaktionsstatus 0: Ausstehende Zahlung/Rückerstattung, 1: Warten auf Rückruf des Drittanbieterkanals, 2: Zahlung/Rückerstattung erfolgreich, 3: Zahlung/Rückerstattung fehlgeschlagen, 4: Zahlungs-/Rückerstattungsbestätigung erfolgreich, 5 : Zahlungs-/Rückerstattungsbestätigung fehlgeschlagen, 6; Transaktion geschlossen, 7: Ausstehende Zahlung (wenn dies der Status ist, müssen Sie bestätigen, ob das empfangende Konto normal ist), 8: Zahlungs-/Rückerstattungsbestätigung erfolgreich – keine anderen Vorgänge sind zulässig, 9 : Verifizierung fehlgeschlagen, 10: Synchrone Bestätigung/Käufer hat bezahlt – wartet auf Versand durch den Verkäufer WAIT_SELLER_SEND_GOODS, 11: Synchrone Bestätigung/Verkäufer hat versendet, wartet auf Bestätigung durch den Käufer WAIT_BUYER_CONFIRM_GOODS' NACH BESCHREIBUNG;
2. SQL-Schreiben
2.1, versuchen Sie, eine einzelne Tabellenabfrage zu verwenden, Vermeiden Sie Multi-Table-JOIN. Die nachfolgenden ON-Bedingungen von JOIN können nicht durch ODER beurteilt werden, z. B. SELECT A.C1,B.C2 FROM A,B ON(A.ID=B.PID OR B.TAG=A.TAR_GET); die Leistung ist sehr gering , PS: Einige online geöffnete Funktionsmodule werden durch diese ODER-Schreibmethode verursacht.
2.2, schreiben Sie die SQL-Anweisung der Anwendung und verbieten Sie alle DDL-Vorgänge wie: Erstellen, Löschen, Ändern, Gewähren, entfernen ; Wenn Sie spezielle Anforderungen haben, wenden Sie sich bitte vor der Verwendung an den DBA.
2.3 Achten Sie beim Schreiben von SQL darauf, den Tabellennamen als Präfix für jedes Feld anzugeben. Wählen Sie beispielsweise ub.id,ub.name aus user_business ub aus, wobei ub.create_date > in der SQLMap-Datei von iBatis die Bindungsvariable durch „#var_name“ und die Substitutionsvariable durch „$var_name$“ dargestellt wird "; alle erfordern eine dynamische Reihenfolge. Wenn Ersatzvariablen für Abfragen mit By-Bedingungen verwendet werden, müssen die möglichen eingehenden Inhalte im Code als Aufzählungen fest codiert werden und es ist verboten, externe eingehende Inhalte zu akzeptieren.
2.4 Wenn Sie bei der Verwendung von innodb beim Herstellen einer Verbindung zur Datenbank zunächst die automatische Übermittlung deaktivieren : set auto_commit=0; Beim Schreiben von Java-Code muss nach dem Ausführen von Einfügen, Löschen, Aktualisieren und Festschreiben der Rollback-Vorgang geschrieben werden.
2.5, schreiben Sie keinen select * ähnlichen Code, Sie müssen den Feldnamen angeben.
2.6, das Datum und die Zeichen von MySQL sind gleich, sodass keine zusätzliche Konvertierung wie bei Oracle erforderlich ist, z :
wählen Sie e.username von Mitarbeiter e aus, wobei e.birthday>='1998-12-31 11:30:45' ist.
2.7, vermeiden Sie die Anwendung von Funktionen auf Felder in where-Klauseln, es sei denn, es handelt sich um eine Geschäftsanforderung, aber Sie müssen den DBA konsultieren beim Schreiben. Beispielsweise muss DATE_FORMAT(p.PAYMENT_DATE, '%Y-%m-%d') >= DATE_FORMAT('2014-10-01', '%Y-%m-%d') korrigiert werden.
2.8 Vermeiden Sie eine redundante Sortierung, wenn Sie „Gruppieren nach“ verwenden , Sie können order by null verwenden;
2.9 Wenn Tabellen verbunden sind, wenn die Datentypen der zum Verbinden verwendeten Felder Wenn zwei Tabellen inkonsistent sind, müssen Sie auf einer Seite eine Typkonvertierungsfunktion hinzufügen. Verhindern Sie, dass MySQL eine implizite Typkonvertierung durchführt.
2.10 Es ist verboten, in der Anwendung Batch-Update-Operationen für die Datenbank durchzuführen. Bitte senden Sie eine E-Mail Lassen Sie den DBA beurteilen, ob es angemessen ist. Innerhalb des Zeitraums wird es manuell in der IDC-Bibliothek ausgeführt.
3. Grundprinzipien
PS: Tabellenstrukturänderungen müssen von dem Team initiiert werden, zu dem die Datenbanktabelle gehört gehört.
1. Alle SQL-Anweisungen, die die in der Testumgebung ausgeführte Tabellenstruktur ändern, müssen vom DBA überprüft werden.
2, physisches Löschen ist nicht zulässig, gespeicherte Prozeduren, Trigger und Ansichten sind nicht zulässig, für DBA gelten besondere Umstände und Geschäftsszenarien
PS: Alle Spezifikationen werden an Ihre eigenen Geschäftsszenarien angepasst. Sie können gerne bessere Vorschläge machen. Ich werde auch weiterhin die am besten geeigneten Datenbankspezifikationen basierend auf der Geschäftsentwicklung zusammenfassen und erweitern.
Das Obige ist der Inhalt der vorläufigen MySQL-Datenbankdesign-Spezifikation V1.0, mehr verwandt Inhalt Bitte beachten Sie die chinesische PHP-Website (www.php.cn)!
