Lassen Sie zu, dass Ihre Datenbank tut, was sie am besten kann?wee dezign | shutterstock.com Es ist ein universeller Fakt: Code beginnt im Zeitverlauf irgendwann zu “faulen”. Dieser Alterungsprozess wird auch als “Code Rot” bezeichnet und schreitet langsam aber stetig voran – wenn nichts dagegen unternommen wird. Ein Bereich, der in diesem Zusammenhang regelmäßig wenig Beachtung findet, ist das Datenbankdesign. Es gibt diverse Dinge, die in Bezug auf Datenbanken im Entwicklungsumfeld zu beachten sind – in diesem Artikel fokussiere ich mich allerdings auf einige Database-Design-Tipps, die weniger bekannt sind. 1. ID-Feld für jede Tabelle Es ist zwar umstritten, aber meiner Meinung nach sollte jede einzelne Datenbanktabelle einen Primär-Key namens ID aufweisen. Nicht CustomerID und auch nicht OrderID – einfach nur ID. Dabei sollte es sich um einen automatisch inkrementierten ganzzahligen Wert handeln (oder eventuell eine UUID, falls es einen wirklich guten Grund dafür gibt – beispielsweise ein verteiltes System). Natürlich sollte zudem ein Index für das ID-Feld vorhanden sein. Ein Mehrfeld-Key für eine Tabelle (die nicht einen Querverweis auf eine Many-to-Many-Beziehung darstellt) sollte den absoluten Ausnahmefall darstellen. 2. Keine Leerzeichen in Tabellen- und Feldnamen Wer auch immer die initiale Idee hatte, Feld- oder Tabellennamen mit Leerzeichen zu versehen, hat der Entwickler-Community einen Bärendienst erwiesen. Leerzeichen in Benennungen zwingen Devs einfach nur dazu, Anführungszeichen zu verwenden – die dann vergessen werden. Sich ständig fragen zu müssen, ob in die Quey, die man gerade schreibt, nun ein Leerzeichen reingehört oder nicht, ist unglaublich nervig. Das Gegenmittel: Nutzen Sie keine Leerzeichen, dann bleibt Ihnen das erspart. Und um Gottes Willen – nehmen Sie in diesem Zusammenhang ebenfalls Abstand davon, Unterstriche zu verwenden. Beim Gedanken an Benennungen_wie_diese_hier, möchten meine Finger direkt eine Arbeitsunfähigkeitsbescheinigung einreichen. 3. Tabellen sind Plural Tabellen repräsentieren viele Dinge. Deshalb bin ich der Überzeugung, dass ihre Benennungen immer den Plural aufweisen sollten. So wissen Sie dann auch direkt, dass mit Orders eine Tabelle gemeint ist. Sie einfach nur Order zu nennen, kann hingegen für Verwirrung sorgen – es könnte schließlich auch nur ein Feld in der Tabelle gemeint sein. 4. Foreign Keys brauchen Label Verweist eine Zeile in der Orders-Tabelle auf einen Kunden – stellt also einen Foreign Key dar – sollten Sie sie mit CustomerID benennen. Jedes Feld, das mit ID benannt ist, stellt einen Foreign Key für die – Tabelle dar. Damit stets klar ist, welche Felder Foreign Keys sind und auf welche Tabelle diese verweisen, sollten Sie das für Ihr gesamtes Datenbank-Schema konsequent beibehalten. 5. Abfragen indizieren Indizieren Sie jedes Feld, das in einer WHERE-, JOIN– oder ORDER BY-Klausel vorkommt. Auch in diesem Fall empfiehlt es sich, sich strikt daran zu halten – ansonsten sind Performance-Probleme im Nachgang vorprogrammiert. Es kann Ausnahmen geben – allerdings sollten Sie diese über Over- statt Under-Indexing finden. Gehen Sie einfach davon aus, dass ein Index erforderlich ist und lassen Sie im Anschluss ihren Query Analyzer die Indizes “behandeln”, die Probleme verursachen. 6. Referenzintegrität ist nicht optional Dass die Beziehungen zwischen Tabellen intakt bleiben und die Datenbank keine verwaisten Datensätze enthält, ist für die Datenintegrität essenziell. Alle modernen relationalen Datenbanken verfügen über Referenzintegrität. Diese Funktion sollten Sie nutzen und von Anfang an konsequent durchsetzen – statt sich auf Ihren Code zu verlassen, um diese Beziehungen aufrechtzuerhalten. 7. SQL-Einbettungen vermeiden Falls Sie jemals SQL in Ihren Code einbetten, werden Sie es bereuen. Denn das verkompliziert Ihren Code und koppelt ihn in einer Weise an Ihre Datenbank, dass am Ende ein riesiger Haufen Spaghetti-Code steht. Auch hier gilt: Überlassen Sie die Arbeit der Datenbank. Wenn Sie SQL in Ihrem Code verwenden müssen, halten Sie es getrennt und verlangen Sie dem Compiler nicht ab, das zu verarbeiten. Speichern Sie das SQL in separaten Dateien, die eingebettet oder außerhalb des Codes genutzt werden können – und aktualisiert werden können, ohne die Codelogik verändern zu müssen. 8. Zusatztipps Wenn Sie jemals das Bedürfnis verspüren, Felder hinzuzufügen, die auf 1, 2, 3 und so weiter enden – geben Sie dem nicht nach. Informieren Sie sich stattdessen über Normalisierung. Nutzen Sie den richtigen Datentyp für Tabellenspalten, sehen Sie davon ab Zahlen für Boolesche Werte und Strings für Datumsangaben zu verwenden. Erwägen Sie, jede Tabelle um die Zeitstempel-Felder CreatedAt und UpdatedAt zu ergänzen. Das kann Ihnen die Arbeit im Nachgang wesentlich erleichtern. Die Timestamps mit Triggern zu automatisieren, erhöht ihren Nutzwert zusätzlich. Parametrisierte, gespeicherte Prozesse sind etwa Gutes. Verwenden Sie sie so oft wie möglich. Ihr Query Analyzer kann wesentlich besser als Sie “beurteilen”, wie Daten optimal abgefragt werden. Null verwandelt Boolesche Werte in Quantum States. Diese sind weder true noch false, bis jemand eine Abfrage ausführt. Booleans sollten Sie entsprechend nur einsetzen, wenn Sie genau wissen, was Null in diesem Zusammenhang bedeutet. Verlassen Sie sich nicht auf String-Werte, um einen State zu definieren. Verwenden Sie stattdessen einen Aufzählungswert. Das gewährleistet, dass die Daten niemals falsch sind. Lassen Sie nicht zu, dass ein Tippfehler wie status = ‚bananna‘ einen Fehler verursacht. (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!
Database-Design-Tipps für Entwickler
Lassen Sie zu, dass Ihre Datenbank tut, was sie am besten kann?wee dezign | shutterstock.com Es ist ein universeller Fakt: Code beginnt im Zeitverlauf irgendwann zu “faulen”. Dieser Alterungsprozess wird auch als “Code Rot” bezeichnet und schreitet langsam aber stetig voran – wenn nichts dagegen unternommen wird. Ein Bereich, der in diesem Zusammenhang regelmäßig wenig Beachtung findet, ist das Datenbankdesign. Es gibt diverse Dinge, die in Bezug auf Datenbanken im Entwicklungsumfeld zu beachten sind – in diesem Artikel fokussiere ich mich allerdings auf einige Database-Design-Tipps, die weniger bekannt sind. 1. ID-Feld für jede Tabelle Es ist zwar umstritten, aber meiner Meinung nach sollte jede einzelne Datenbanktabelle einen Primär-Key namens ID aufweisen. Nicht CustomerID und auch nicht OrderID – einfach nur ID. Dabei sollte es sich um einen automatisch inkrementierten ganzzahligen Wert handeln (oder eventuell eine UUID, falls es einen wirklich guten Grund dafür gibt – beispielsweise ein verteiltes System). Natürlich sollte zudem ein Index für das ID-Feld vorhanden sein. Ein Mehrfeld-Key für eine Tabelle (die nicht einen Querverweis auf eine Many-to-Many-Beziehung darstellt) sollte den absoluten Ausnahmefall darstellen. 2. Keine Leerzeichen in Tabellen- und Feldnamen Wer auch immer die initiale Idee hatte, Feld- oder Tabellennamen mit Leerzeichen zu versehen, hat der Entwickler-Community einen Bärendienst erwiesen. Leerzeichen in Benennungen zwingen Devs einfach nur dazu, Anführungszeichen zu verwenden – die dann vergessen werden. Sich ständig fragen zu müssen, ob in die Quey, die man gerade schreibt, nun ein Leerzeichen reingehört oder nicht, ist unglaublich nervig. Das Gegenmittel: Nutzen Sie keine Leerzeichen, dann bleibt Ihnen das erspart. Und um Gottes Willen – nehmen Sie in diesem Zusammenhang ebenfalls Abstand davon, Unterstriche zu verwenden. Beim Gedanken an Benennungen_wie_diese_hier, möchten meine Finger direkt eine Arbeitsunfähigkeitsbescheinigung einreichen. 3. Tabellen sind Plural Tabellen repräsentieren viele Dinge. Deshalb bin ich der Überzeugung, dass ihre Benennungen immer den Plural aufweisen sollten. So wissen Sie dann auch direkt, dass mit Orders eine Tabelle gemeint ist. Sie einfach nur Order zu nennen, kann hingegen für Verwirrung sorgen – es könnte schließlich auch nur ein Feld in der Tabelle gemeint sein. 4. Foreign Keys brauchen Label Verweist eine Zeile in der Orders-Tabelle auf einen Kunden – stellt also einen Foreign Key dar – sollten Sie sie mit CustomerID benennen. Jedes Feld, das mit ID benannt ist, stellt einen Foreign Key für die – Tabelle dar. Damit stets klar ist, welche Felder Foreign Keys sind und auf welche Tabelle diese verweisen, sollten Sie das für Ihr gesamtes Datenbank-Schema konsequent beibehalten. 5. Abfragen indizieren Indizieren Sie jedes Feld, das in einer WHERE-, JOIN– oder ORDER BY-Klausel vorkommt. Auch in diesem Fall empfiehlt es sich, sich strikt daran zu halten – ansonsten sind Performance-Probleme im Nachgang vorprogrammiert. Es kann Ausnahmen geben – allerdings sollten Sie diese über Over- statt Under-Indexing finden. Gehen Sie einfach davon aus, dass ein Index erforderlich ist und lassen Sie im Anschluss ihren Query Analyzer die Indizes “behandeln”, die Probleme verursachen. 6. Referenzintegrität ist nicht optional Dass die Beziehungen zwischen Tabellen intakt bleiben und die Datenbank keine verwaisten Datensätze enthält, ist für die Datenintegrität essenziell. Alle modernen relationalen Datenbanken verfügen über Referenzintegrität. Diese Funktion sollten Sie nutzen und von Anfang an konsequent durchsetzen – statt sich auf Ihren Code zu verlassen, um diese Beziehungen aufrechtzuerhalten. 7. SQL-Einbettungen vermeiden Falls Sie jemals SQL in Ihren Code einbetten, werden Sie es bereuen. Denn das verkompliziert Ihren Code und koppelt ihn in einer Weise an Ihre Datenbank, dass am Ende ein riesiger Haufen Spaghetti-Code steht. Auch hier gilt: Überlassen Sie die Arbeit der Datenbank. Wenn Sie SQL in Ihrem Code verwenden müssen, halten Sie es getrennt und verlangen Sie dem Compiler nicht ab, das zu verarbeiten. Speichern Sie das SQL in separaten Dateien, die eingebettet oder außerhalb des Codes genutzt werden können – und aktualisiert werden können, ohne die Codelogik verändern zu müssen. 8. Zusatztipps Wenn Sie jemals das Bedürfnis verspüren, Felder hinzuzufügen, die auf 1, 2, 3 und so weiter enden – geben Sie dem nicht nach. Informieren Sie sich stattdessen über Normalisierung. Nutzen Sie den richtigen Datentyp für Tabellenspalten, sehen Sie davon ab Zahlen für Boolesche Werte und Strings für Datumsangaben zu verwenden. Erwägen Sie, jede Tabelle um die Zeitstempel-Felder CreatedAt und UpdatedAt zu ergänzen. Das kann Ihnen die Arbeit im Nachgang wesentlich erleichtern. Die Timestamps mit Triggern zu automatisieren, erhöht ihren Nutzwert zusätzlich. Parametrisierte, gespeicherte Prozesse sind etwa Gutes. Verwenden Sie sie so oft wie möglich. Ihr Query Analyzer kann wesentlich besser als Sie “beurteilen”, wie Daten optimal abgefragt werden. Null verwandelt Boolesche Werte in Quantum States. Diese sind weder true noch false, bis jemand eine Abfrage ausführt. Booleans sollten Sie entsprechend nur einsetzen, wenn Sie genau wissen, was Null in diesem Zusammenhang bedeutet. Verlassen Sie sich nicht auf String-Werte, um einen State zu definieren. Verwenden Sie stattdessen einen Aufzählungswert. Das gewährleistet, dass die Daten niemals falsch sind. Lassen Sie nicht zu, dass ein Tippfehler wie status = ‚bananna‘ einen Fehler verursacht. (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!
Database-Design-Tipps für Entwickler Lassen Sie zu, dass Ihre Datenbank tut, was sie am besten kann?wee dezign | shutterstock.com Es ist ein universeller Fakt: Code beginnt im Zeitverlauf irgendwann zu “faulen”. Dieser Alterungsprozess wird auch als “Code Rot” bezeichnet und schreitet langsam aber stetig voran – wenn nichts dagegen unternommen wird. Ein Bereich, der in diesem Zusammenhang regelmäßig wenig Beachtung findet, ist das Datenbankdesign. Es gibt diverse Dinge, die in Bezug auf Datenbanken im Entwicklungsumfeld zu beachten sind – in diesem Artikel fokussiere ich mich allerdings auf einige Database-Design-Tipps, die weniger bekannt sind. 1. ID-Feld für jede Tabelle Es ist zwar umstritten, aber meiner Meinung nach sollte jede einzelne Datenbanktabelle einen Primär-Key namens ID aufweisen. Nicht CustomerID und auch nicht OrderID – einfach nur ID. Dabei sollte es sich um einen automatisch inkrementierten ganzzahligen Wert handeln (oder eventuell eine UUID, falls es einen wirklich guten Grund dafür gibt – beispielsweise ein verteiltes System). Natürlich sollte zudem ein Index für das ID-Feld vorhanden sein. Ein Mehrfeld-Key für eine Tabelle (die nicht einen Querverweis auf eine Many-to-Many-Beziehung darstellt) sollte den absoluten Ausnahmefall darstellen. 2. Keine Leerzeichen in Tabellen- und Feldnamen Wer auch immer die initiale Idee hatte, Feld- oder Tabellennamen mit Leerzeichen zu versehen, hat der Entwickler-Community einen Bärendienst erwiesen. Leerzeichen in Benennungen zwingen Devs einfach nur dazu, Anführungszeichen zu verwenden – die dann vergessen werden. Sich ständig fragen zu müssen, ob in die Quey, die man gerade schreibt, nun ein Leerzeichen reingehört oder nicht, ist unglaublich nervig. Das Gegenmittel: Nutzen Sie keine Leerzeichen, dann bleibt Ihnen das erspart. Und um Gottes Willen – nehmen Sie in diesem Zusammenhang ebenfalls Abstand davon, Unterstriche zu verwenden. Beim Gedanken an Benennungen_wie_diese_hier, möchten meine Finger direkt eine Arbeitsunfähigkeitsbescheinigung einreichen. 3. Tabellen sind Plural Tabellen repräsentieren viele Dinge. Deshalb bin ich der Überzeugung, dass ihre Benennungen immer den Plural aufweisen sollten. So wissen Sie dann auch direkt, dass mit Orders eine Tabelle gemeint ist. Sie einfach nur Order zu nennen, kann hingegen für Verwirrung sorgen – es könnte schließlich auch nur ein Feld in der Tabelle gemeint sein. 4. Foreign Keys brauchen Label Verweist eine Zeile in der Orders-Tabelle auf einen Kunden – stellt also einen Foreign Key dar – sollten Sie sie mit CustomerID benennen. Jedes Feld, das mit ID benannt ist, stellt einen Foreign Key für die – Tabelle dar. Damit stets klar ist, welche Felder Foreign Keys sind und auf welche Tabelle diese verweisen, sollten Sie das für Ihr gesamtes Datenbank-Schema konsequent beibehalten. 5. Abfragen indizieren Indizieren Sie jedes Feld, das in einer WHERE-, JOIN– oder ORDER BY-Klausel vorkommt. Auch in diesem Fall empfiehlt es sich, sich strikt daran zu halten – ansonsten sind Performance-Probleme im Nachgang vorprogrammiert. Es kann Ausnahmen geben – allerdings sollten Sie diese über Over- statt Under-Indexing finden. Gehen Sie einfach davon aus, dass ein Index erforderlich ist und lassen Sie im Anschluss ihren Query Analyzer die Indizes “behandeln”, die Probleme verursachen. 6. Referenzintegrität ist nicht optional Dass die Beziehungen zwischen Tabellen intakt bleiben und die Datenbank keine verwaisten Datensätze enthält, ist für die Datenintegrität essenziell. Alle modernen relationalen Datenbanken verfügen über Referenzintegrität. Diese Funktion sollten Sie nutzen und von Anfang an konsequent durchsetzen – statt sich auf Ihren Code zu verlassen, um diese Beziehungen aufrechtzuerhalten. 7. SQL-Einbettungen vermeiden Falls Sie jemals SQL in Ihren Code einbetten, werden Sie es bereuen. Denn das verkompliziert Ihren Code und koppelt ihn in einer Weise an Ihre Datenbank, dass am Ende ein riesiger Haufen Spaghetti-Code steht. Auch hier gilt: Überlassen Sie die Arbeit der Datenbank. Wenn Sie SQL in Ihrem Code verwenden müssen, halten Sie es getrennt und verlangen Sie dem Compiler nicht ab, das zu verarbeiten. Speichern Sie das SQL in separaten Dateien, die eingebettet oder außerhalb des Codes genutzt werden können – und aktualisiert werden können, ohne die Codelogik verändern zu müssen. 8. Zusatztipps Wenn Sie jemals das Bedürfnis verspüren, Felder hinzuzufügen, die auf 1, 2, 3 und so weiter enden – geben Sie dem nicht nach. Informieren Sie sich stattdessen über Normalisierung. Nutzen Sie den richtigen Datentyp für Tabellenspalten, sehen Sie davon ab Zahlen für Boolesche Werte und Strings für Datumsangaben zu verwenden. Erwägen Sie, jede Tabelle um die Zeitstempel-Felder CreatedAt und UpdatedAt zu ergänzen. Das kann Ihnen die Arbeit im Nachgang wesentlich erleichtern. Die Timestamps mit Triggern zu automatisieren, erhöht ihren Nutzwert zusätzlich. Parametrisierte, gespeicherte Prozesse sind etwa Gutes. Verwenden Sie sie so oft wie möglich. Ihr Query Analyzer kann wesentlich besser als Sie “beurteilen”, wie Daten optimal abgefragt werden. Null verwandelt Boolesche Werte in Quantum States. Diese sind weder true noch false, bis jemand eine Abfrage ausführt. Booleans sollten Sie entsprechend nur einsetzen, wenn Sie genau wissen, was Null in diesem Zusammenhang bedeutet. Verlassen Sie sich nicht auf String-Werte, um einen State zu definieren. Verwenden Sie stattdessen einen Aufzählungswert. Das gewährleistet, dass die Daten niemals falsch sind. Lassen Sie nicht zu, dass ein Tippfehler wie status = ‚bananna‘ einen Fehler verursacht. (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!