Database
 sql >> Datenbank >  >> RDS >> Database

Tabellenkalkulationen vs. Datenbanken:Ist es Zeit für einen Wechsel? Teil 2

Tabellen – Excel, Google Sheets oder ein Blatt mit einem anderen Namen – sind wirklich coole und leistungsstarke Tools. Aber Datenbanken sind es ja auch. Wann sollten Sie bei einer Tabellenkalkulation bleiben? Wann sollten Sie auf eine Datenbank umsteigen?

Dies ist die Fortsetzung meines vorherigen Artikels „Spreadsheets vs. Datenbanken:Ist es Zeit für einen Wechsel?“ wo wir die häufigsten Nachteile der Verwendung von Tabellenkalkulationen zum Organisieren vieler Daten besprochen haben. In diesem Artikel werden wir herausfinden, wie eine Datenbank diese Probleme löst.

Verwenden einer Datenbank zum Organisieren von Daten

Mein Motto lautet „Nutzen Sie die passende Technik für Ihre Bedürfnisse“. Wenn Sie Ihr Geschäft über Tabellen führen können, großartig! Wenn Sie eine einfache Datenbank benötigen, ist MS Access keine schlechte Option. Aber wenn diese Produkte für Sie nicht funktionieren, benötigen Sie wahrscheinlich eine angepasste Datenbank und eine Webanwendung. Die Datenbank speichert Ihre Daten; Die Web-App wird eine benutzerfreundliche Möglichkeit sein, mit der Datenbank zu interagieren und mit der Datenschicht zu kommunizieren.

Unser fiktives Dienstleistungsgeschäft war nicht sehr kompliziert, sodass wir es mit einem ziemlich einfachen Datenmodell betreiben konnten. Wenn Sie sich das Bild unten ansehen, sehen Sie, dass alles, was wir brauchen, in nur fünf Tabellen gespeichert ist:client_type , client , service , replacement und has_service .

Eine Schlüsselregel des Datenbankdesigns besteht darin, zusammengehörige Daten aus der realen Welt an einem Ort aufzubewahren . In diesem Fall behalten wir alle unsere client Daten in der Kundentabelle. Auf diese Weise vermeiden wir, dieselben Daten an mehreren Orten zu speichern (die zuvor erwähnte schlechte Art von Redundanz). Wenn wir etwas in Bezug auf einen Kunden ändern, tun wir dies nur einmal in dieser Tabelle. Dadurch wird die Datenqualität erheblich verbessert und die Leistung verbessert.

Die nächste Tabelle, die reale Daten enthält, ist der service Tisch. Auch hier können wir alle Details zu unseren Dienstleistungen speichern und sehr effizient Änderungen an den Daten vornehmen.

Der client Tabelle und den service Tabelle sind Entitäten der realen Welt, die ohne die anderen existieren könnten. Das Erstellen einer Datenbank mit nicht verwandten Entitäten ist jedoch nicht sehr sinnvoll – es ist, als hätte man Kunden ohne Produkte oder Dienstleistungen ohne Käufer. Also verknüpfen wir diese beiden Tabellen mit dem has_service Tisch. Um Informationen darüber zu speichern, welche Kunden welchen Dienst haben, verwenden wir Fremdschlüssel, die als Verweise auf diesen Kunden und Dienst dienen. Diese Fremdschlüssel verweisen auf Datensätze in den Service- und Client-Tabellen. Wir können in dieser Tabelle auch alle zusätzlichen Informationen zu jeder Kunden-Service-Beziehung aufbewahren.

Der client_type Die Tabelle wird wie ein Wörterbuch verwendet, in dem alle möglichen Clienttypen gespeichert sind. Es ist am besten, verschiedene Segmentierungen in separaten Wörterbuchtabellen zu halten (z. B. wenn wir Kundentypen und Mitarbeiterrollentypen hätten, würden wir sie in verschiedenen Tabellen speichern). Wir benötigen jedoch nur eine Tabelle, da dies ein einfaches Modell ist.

Die letzte Tabelle in unserem Modell ist die replacement Tisch. Wir verwenden es, um zwei Dienste in Beziehung zu setzen:einen Dienst, den wir ersetzen möchten, und den Ersatzdienst. Dies gibt uns die Flexibilität, Kunden Ersatz für bestehende Dienste anzubieten (ähnlich wie der Wechsel von einem Mobilfunktarif zu einem anderen).

Datenbankvorteile

Datenbanken sind komplizierter einzurichten als Tabellenkalkulationen, aber dies bietet ihnen tatsächlich einige erhebliche Vorteile in Bezug auf Datenintegrität und -sicherheit:

Schlüssel und Beschränkungen

Datenbanken verfügen über integrierte Regeln und Kontrollen, die bei richtiger Anwendung die meisten Datenqualitäts- und Leistungsprobleme verhindern. Primärschlüssel (Spalten, die jeden Datensatz in einer Tabelle eindeutig identifizieren) und Fremdschlüssel (Spalten, die auf einen Datensatz in einer anderen Tabelle verweisen) sind entscheidend für die Datensicherheit, definieren jedoch alternative oder EINZIGARTIGE Schlüssel (die Daten enthalten, die für jeden Datensatz in einer Tabelle eindeutig sind). ) ist auch sehr hilfreich.

In relationalen Datenbanken verknüpfen Schlüssel Daten aus verschiedenen Tabellen. Der Primärschlüssel der Tabelle ist immer EINZIGARTIG, während ein Fremdschlüssel auf den Primärschlüssel einer anderen Tabelle verweist. Diese Referenz bezieht sich auf Daten aus diesen beiden Tabellen (z. B. die Fremdschlüssel in has_service Tabelle Kundendaten mit den von ihnen angebotenen Dienstleistungen in Beziehung setzen). Es wird uns auch warnen, wenn wir im Begriff sind, einen Primärschlüssel zu löschen, auf den in einer anderen Tabelle verwiesen wird. Dadurch werden wir daran gehindert, noch benötigte Datensätze (als Referenzen) in einer anderen Tabelle zu löschen.

Einschränkungen definieren die Art von Daten, die in ein Feld eingegeben werden können. Wir können angeben, dass die Daten einen Wert haben müssen (NICHT NULL), ein Format für Telefonnummern definieren, nur Buchstaben enthalten und so weiter. Das bedeutet, dass wir Datenprobleme vermeiden können, wenn Personen die falschen Daten in ein Feld eingeben.

Sicherheit und Berechtigungen

Eine weitere sehr wichtige Datenbankfunktion ist die Kontrolle des Zugriffs auf Ihre Daten . Auf diese Weise können Sie nicht nur festlegen, wer auf Ihre Datenbank zugreifen kann, sondern auch steuern, was sie sehen oder ändern können. Dies ist ein großer Teil der Datensicherheit. Beispielsweise könnten Sie eine Benutzerrolle definieren, die es einem Mitarbeiter erlaubt, Kundendetails, aber keine Servicedetails zu ändern. Sie könnten auch Regeln festlegen, welche Mitarbeiter Daten ändern oder löschen dürfen. Es ist eine gute Standardpraxis sicherzustellen, dass Personen nur Zugriff auf die Daten haben, die sie für ihre Arbeit benötigen.

Natürlich könnten wir versuchen, diese Funktionalitäten in Tabellen nachzubilden (zumindest in gewisser Weise), aber das wäre definitiv „das Rad neu erfinden“.

Könnten wir nicht einfach eine Tabelle verwenden?

Natürlich könnten wir. Wir könnten Blätter erstellen, die demselben Muster folgen, das im Datenmodell verwendet wird. Das würde viele Datenprobleme lösen, aber…

Die Replikation des Datenmodells in Sheets ist definitiv keine ideale Option. Wir würden alle Vorteile verlieren, die uns das Datenbanksystem bietet, alle Regeln und Einschränkungen, die Daten „gesund“ halten, all die Dinge, die versehentliches Löschen und andere Fehler verhindern. Wir würden bei der Optimierung verlieren, und wenn der Datensatz groß genug wäre, würde die Leistung darunter leiden.

Selbst wenn wir das gelöst haben, was ist mit dem Teilen von Daten, z. mehrere Benutzer gleichzeitig dasselbe Blatt verwenden? Welche Datenintegritäts- und Leistungsprobleme würde dies verursachen? Das wäre das Gegenteil davon, die Dinge einfach zu halten.

Wenn Sie also der Meinung sind, dass Sheets Ihre geschäftlichen Anforderungen nicht erfüllen können, sind Sie wahrscheinlich bereits auf dem Weg zu einer Datenbank. Wenn Sie mit in Blättern gespeicherten Daten feststecken und zu einer Datenbank wechseln möchten, sollten Sie:

  1. Erstellen Sie ein Datenbankmodell, das Ihre Daten optimal speichert.
  2. Erstellen Sie eine Anwendung mit der Datenbank im Hintergrund.
  3. Löschen Sie Ihre Daten, transformieren Sie sie (falls erforderlich) und importieren Sie sie in die Datenbank.
  4. Nur mit der Datenbank weiterarbeiten.

Wofür sollten Sie sich entscheiden – Tabellenkalkulation oder Datenbank?

Im heutigen Artikel haben wir gelernt, wie eine Datenbank Probleme bei der Verwendung von Blättern zum Organisieren vieler Daten löst. Mein Rat ist, immer die einfachste Lösung für Ihr Problem zu wählen . Wenn Tabellenkalkulationen die Arbeit richtig erledigen, verwenden Sie sie. Wenn Sie jedoch ein datengesteuertes Unternehmen sind, sollten Sie so schnell wie möglich mit der Verwendung einer Datenbank beginnen. Je länger Sie mit der Bereinigung und Migration Ihrer Daten warten, desto schmerzhafter wird der Prozess.