Professor sagte uns, wir sollten serialisierte Java-Objekte als Blobs speichern, anstatt relationale Tabellen zu definieren

Anstatt eine Tabelle mit den richtigen Attributen zu definieren, sagte mir mein Professor, wir könnten Objekte IDs wie folgt zuordnen:

id (int)  |   Serialized Object (blob)
   1               10010110110

Ich kann so viele Probleme damit sehen; Datenredundanz, IDs müssen separat nachverfolgt werden, die gesamte Tabelle muss in den Speicher gezogen werden, um nach etwas zu suchen, und ** wenn ich mein Modell im Java-Code ändern möchte, kann ich den im gespeicherten Blob nicht mehr deserialisieren Datenbank in dieses Modell.

Entweder bin ich für immer mit diesem Modell beschäftigt oder ich muss andere wirklich hässliche Dinge tun, um mein Modell zu ändern. Bin ich berechtigt, mit meinem Professor nicht einverstanden zu sein? Gibt es einen Vorteil, an den ich nicht gedacht habe? Wenn ich Recht habe, sollte ich meinem Professor etwas dazu sagen? Er predigte dies meiner ganzen Klasse und sagte sogar, dass er Projekte auf diese Weise gebaut habe. Eine zweite Meinung wäre toll.

Der Kurs heißt Software Design .

Mein Professor sagte nicht, dass dies der beste Weg sei, aber er sagte, dass dies eine legitime Alternative zur Definition relationaler Tabellen sei.

Das Modell ist in keiner Weise dynamisch.

1. Es ist an sich keine schlechte Sache - überhaupt nicht. Das Streiten über "Was ist besser" ohne einen angemessenen Kontext (= genaue Anforderungen) ist eine Übung der Sinnlosigkeit.

2. Der fett gedruckte Teil ist falsch. Sie können bereits serialisierte Objekte problemlos erweitern, um neue Felder hinzuzufügen und vollständige Binärkompatibilität mit den älteren Objekten zu erzielen. Sie können auch einfach neue Klassen erstellen, anstatt die ursprünglichen zu ändern.

Ihre Diskussion mit dem Professor sollte sich auf die Vor- und Nachteile von "relationalem" im Vergleich zu "Schlüsselwertspeicher" in verschiedenen Szenarien konzentrieren, nicht auf die abstrakte "Betterness". Oder Sie könnten auch darüber diskutieren, ob Weihnachten Thanksgiving überlegen ist.

- eine Bearbeitung nach dem Lesen anderer Antworten.

Eine der anderen Antworten besagt, dass "es schwer vorstellbar ist, dass die Vorteile die Nachteile überwiegen".

Da es sich bei der gesamten Diskussion um konkrete Probleme handeln muss (ansonsten können wir nicht einmal "besser" und "schlechter" definieren), möchte ich Ihnen ein konkretes Beispiel geben. Es ist komplett erfunden, aber ich habe versucht, so viele Details wie möglich zu präzisieren.

Stellen Sie sich vor, Sie haben eine Online-Spieleseite mit einer Datenbank, in der Statistiken von Spielern in verschiedenen Online-Spielen gespeichert sind (im Browser gespielt, in GWT geschrieben und in Javascript crosskompiliert). Einige der Spiele sind strategisch, andere sind Actionspiele, andere sind Plattformspieler. Die Datenbank ist relational und speichert die Spieler, die Spielgeschichte und die Punktzahl.

Eines Tages erhalten Sie eine zusätzliche Anforderung: Lassen Sie die Spieler den Spielstatus während des Spiels in der Cloud speichern, damit sie das Spiel später zum gleichen Zeitpunkt neu starten können. Es erübrigt sich zu erwähnen, dass der einzige Grund, diesen temporären Zustand zu speichern, darin besteht, zum Spiel zurückzukehren. Der Zustand selbst wird niemals in sich gekehrt.

Jetzt haben Sie zwei grundlegende Möglichkeiten:

• Da die Spiele in Java geschrieben sind, können Sie das Modell ganz einfach nehmen, an den Server senden, in einer Codezeile serialisieren und als Blob speichern. Der Tisch heißt "saved_games" und hat Fremdschlüssel für den Spieler und so weiter. Aus Sicht der Datenbank ist ein "Spiel speichern" ein undurchsichtiger, unteilbarer Fleck.

• Sie können für jedes Ihrer 100 Spiele ein eigenes relationales Modell erstellen (dies sind zehn Tische pro Spiel). Zum Beispiel müssen Sie für Pacman alleine eine Tabelle haben, in der die Positionen aller nicht gefressenen Pellets, Boni, Positionen und der aktuelle Zustand der Geister gespeichert sind. Wenn jemand eines Tages das Spiel auch nur geringfügig ändert, müssen Sie das relationale Modell aktualisieren. Außerdem müssen Sie für jeden Spieltyp eine Logik implementieren, um das Java-Modell in die Datenbank zu schreiben und zurückzulesen.

Die Antwort von Justin Cave besagt, dass Sie sich für die zweite Option entscheiden sollten. Ich denke, das wäre ein großer Fehler.

Ich habe auch die Vermutung, dass Justin Caves Wahrnehmung ist, dass das, was ich oben vorgestellt habe, ein "Rand" oder "seltener" Fall ist. Ich glaube, dass ich eine solche Meinung als klassischen Fall einer Projektion betrachten werde, wenn er nicht irgendeine Art von harten Daten präsentieren kann (basierend auf einer repräsentativen Stichprobe aller IT-Projekte in der Welt, beispielsweise Unternehmensanwendungen in den USA) vorspannen.

Tatsächlich ist das Problem serialisierter Java-Objekte in einer relationalen Datenbank weitaus größer als es scheint. Es berührt den Kern des 1NF, nämlich die Domäne eines Attributs. . Wenn Sie wirklich an dem Thema interessiert sind, gibt es einen großartigen Artikel von CJ Date in seinem Date on Database: Writings 2000-2006 .

Können (und können) Menschen erfolgreich Projekte durchführen, die so etwas tun? Leider tun sie dies ziemlich oft.

Ist das ein guter Ansatz? Nein, ist es nicht. Im Grunde genommen nehmen Sie Ihre relativ teure Datenbank und verwandeln sie in ein relativ langsames Dateisystem. Wenn Sie wirklich ein System erstellen möchten, das seinen Status durch Serialisieren und De-Serialisieren von Objekten speichert, können Sie auch ein Dateisystem anstelle einer Datenbank verwenden.

Wenn Sie Systeme erstellen, in denen Daten gespeichert werden, indem Sie Objekte in die Datenbank serialisieren, werden Sie sich mit Ihrem DBA nicht anfreunden. Sie werden am Ende redundante Daten speichern. Es kommt zu furchtbar inkonsistenten Daten. Jedes Mal, wenn freigegebene Daten aktualisiert werden, erhalten einige Objekte die neuen Werte und einige Objekte die alten Werte. Sie werden es unmöglich machen, irgendeine Art von Berichterstattung über die Daten zu erstellen - alles, was jemand mit den Daten machen möchte, erfordert, dass jemand zusätzlichen Code schreibt. In den meisten Unternehmen ist dies ein großes Problem, da sie beispielsweise Daten aus einem System extrahieren möchten, um sie in ein anderes System zu laden, oder über ein Berichtssystem verfügen möchten, das Berichte aus mehreren Front-End-Anwendungen bereitstellen kann. Außerdem müssen Sie sich, wie Sie betonen, ständig mit Problemen befassen, wenn Sie

Gibt es Vorteile für diesen Ansatz? Ich denke, Sie können argumentieren, dass es ziemlich einfach ist, die erste Version der App zu implementieren. Und der Entwickler kann alles, was mit der ordnungsgemäßen Interaktion mit einer Datenbank zusammenhängt, vollständig ignorieren. Es fällt mir schwer, mir viele Fälle vorzustellen, in denen diese Vorteile die zahlreichen Nachteile des Ansatzes überwiegen.

Wie Sie mit diesem bestimmten Professor umgehen sollten, ist ein separates Thema (und eines, das wahrscheinlich nicht in diesem Forum enthalten ist). Wenn Ihr Professor aktiv Projekte in der realen Welt entwickelt, ist er wahrscheinlich nicht besonders empfänglich für Argumente eines Studenten, dass sein Ansatz grundlegend falsch ist (auch wenn der Ansatz tatsächlich grundlegend falsch ist). Möglicherweise ist es besser, wenn Sie Ihr Projekt so durchführen, wie es der Professor wünscht, und lernen, wie Sie Daten auf eigene Faust (oder in einem anderen Kurs) speichern können.

Es gibt Situationen, in denen ein solches Design sinnvoll ist, ohne dass Sie beschreiben, worum es in Ihren Projekten geht und wie es verwendet wird. Es ist schwer zu sagen, ob dies angemessen ist oder nicht.

Ihr DBA mag Sie hassen, wenn Sie BLOBs speichern, aber in vielen Situationen besteht die einzige Alternative darin, die Tabellen in Entity-Attribut-Werte umzuwandeln, was den Hass von DBAs noch verstärkt. Die andere Alternative ist die Verwendung nicht relationaler Datenbanken, normalerweise objektbasierter oder wörterbuchbasierter Datenbanken, oder einer dokumentenorientierten Datenbank, die einige Datenbankadministratoren, insbesondere diejenigen, die nur relationale Kenntnisse haben, mit noch größerer Leidenschaft hassen würden. Nicht relationale Datenbanken haben ihre eigenen Probleme. Es kann jedoch durchaus vorkommen, dass die Verwendung der Objektdatenbank zum Speichern von Objekten andere Probleme aufwirft, die Sie in relationalen Systemen problemlos hätten lösen können.

Gibt es einen Vorteil, an den ich nicht gedacht habe?

Beim Speichern von serialisierten Objekten können Sie schemenlose Daten speichern (beachten Sie, dass schemenlose Daten trotz des Namens normalerweise nicht bedeuten, dass es überhaupt kein Schema gibt, sondern nur ein implizites Schema). Es gibt viele Problembereiche, in denen Sie das Schema möglicherweise nicht rechtzeitig zur Entwicklungszeit definieren können und in denen das Befolgen des traditionellen relationalen Datenbankdesigns bedeuten würde, dass Sie das Datenbankschema jede zweite Woche ändern müssen oder dass Sie eine Tabelle mit einer solchen Tabelle erhalten 80% der Spalten, die in 80% der Fälle nicht verwendet werden, oder Hunderte von verschiedenen Tabellen zum Speichern der tatsächlich gleichen Daten, von denen keine auf ein gutes Design hinweist. Die Ursache für dieses Problem liegt normalerweise darin, dass Sie eine nicht relationale Problemdomäne zwangsweise in eine relationale Datenbank einpassen.

Natürlich gibt es viele Projekte, bei denen die Leute glauben, sie müssten EAV, schemenloses Speichern oder Blob-Speichern verwenden, was unnötigerweise zu vermeidbaren Schmerzen geführt hätte. Sie sollten auf jeden Fall mit Ihrem Professor besprechen, was seine Argumentation ist, und Ihre eigenen Argumente vorbringen. Hören Sie sich die Argumente an und seien Sie darauf vorbereitet, dass Sie ihm zustimmen oder nicht, vielleicht liegt er falsch.

Ich habe dies bereits getan - es ist in bestimmten Szenarien eine nützliche Technik, hängt jedoch vom verwendeten Serialisierungsformat ab. In diesem Fall stelle ich sicher, dass ich ein Serialisierungsformat verwende, mit dem ich ältere Versionen meines Modells (z. B. XML) de-serialisieren kann.

Normalerweise würde ich dies in Szenarien verwenden, in denen das Datenformat ein kompliziertes relationales Modell ergeben würde, das keine Vorteile bietet (z. B. wenn die Geschäftsanforderungen keine Filterung usw. erfordern) und ich bereits eine Datenbank verwende (z andere relationale Daten). Ein solcher Fall war eine Anwendung mit Benutzerabfragen - das relationale Modell hatte eine Handvoll Tabellen zum Speichern von Dingen wie Bedingungen, verschachtelten Bedingungen (ODER / UND usw.), Sortieroptionen usw. Es war ziemlich kompliziert und so weiter Wir mussten eine neue Funktion hinzufügen, die eine Änderung an der Datenbank erforderte. Ich ersetzte das Ganze durch eine einzelne Abfragetabelle mit einem serialisierten Blob, der alle anderen Optionen darstellt.

Ein anderer Fall war ein System, das verschiedene "Jobs" verarbeitete. Es gab verschiedene Arten von Jobs und jeder Job hatte unterschiedliche Parameter, ohne dass geschäftliche Anforderungen bestanden, um Jobs basierend auf diesen Parametern suchen / filtern zu können. Das Speichern als relationale Datenbank hätte mindestens 1 neue Tabelle pro Jobtyp erfordert, was das Hinzufügen neuer Jobtypen erschwert. Stattdessen werden die Parameter als Blob in der Datenbank gespeichert. Jeder Auftragstyp ist für die Serialisierung und Deserialisierung seiner eigenen Parameter verantwortlich.

Es kommt nicht sehr oft vor, dass Sie auf solche Szenarien stoßen, doch hin und wieder taucht eine Situation wie die oben beschriebene auf, in der die Serialisierung von Blob-Daten eine Menge Aufwand spart, Ihre Anwendung wartungsfreundlicher macht und keine wirklichen Nachteile hat.

Justin Cave hat Recht, dass dies zu redundanten Daten führen kann, aber dies hängt wirklich davon ab, wie Sie Ihre Datenbank entwerfen.

Der Ansatz, ein ganzes Objekt in einen Blob zu serialisieren, ist nicht so empörend, wie die meisten Leute hier glauben. In der Tat kann dies für einige Anwendungen das beste Design sein, das Sie tun können, wie ich hier erklärt habe: /programming//a/12644223/1121352 .

Das Serialisieren eines Objekts bietet in der Tat mindestens zwei Vorteile:

1- Reduzieren von Impedanzfehlanpassungen : Einige Java-Typen sind in SQL einfach nicht verfügbar, insbesondere wenn Sie viele Klassen und benutzerdefinierte Typen verwenden. Daher kann das Konvertieren von Java-Objekten nach SQL ein großer Aufwand sein und sogar zu Mehrdeutigkeiten führen.

2- Mehr Flexibilität in Ihrem Schema . Relationale Schemata eignen sich in der Tat hervorragend für Daten mit derselben Struktur. Wenn jedoch einige Ihrer Objekte in einer einzelnen Klasse je nach den Bedingungen zur Laufzeit unterschiedliche Eigenschaften aufweisen können, können relationale Schemata Ihren Workflow erheblich beeinträchtigen.

Daher hat dieser Ansatz sicherlich Vorteile (zumindest diese beiden, aber sicherlich auch andere, die ich nicht angeführt habe), aber der enorme Kostenaufwand besteht natürlich darin, dass Sie fast alle Vorteile für relationale Schemata verlieren.

Sie können jedoch das Beste aus beiden Welten herausholen, wenn Sie Ihre Datenbank sorgfältig entwerfen: Sie können weiterhin ein relationales Schema (dh eindeutige Schlüsselspalten) festlegen, indem Sie die für jedes Objekt eindeutigen Attribute verwenden und das Objekt dann im Blob speichern . Auf diese Weise können Sie weiterhin einen schnellen Abruf Ihres Objekts mit einer eindeutigen Kennung sicherstellen, die durch die Attribute Ihres Objekts definiert ist, und außerdem die Redundanz verringern, während Sie die Impedanzinkongruenz aufheben und die volle Flexibilität von Java-Objekten beibehalten.

Als Randnotiz gibt es einige Versuche einiger DB-Hersteller, relationale und Objektmodelle zusammenzufügen, wie den JSON-Datentyp in PostSQL und PostgreSQL, damit Sie JSON wie jede relationale Spalte direkt verarbeiten können, sowie SQL3 und OQL (Object Abfragesprache), um (eingeschränkte) Objektunterstützung zu SQL hinzuzufügen.

Letztendlich ist dies alles eine Frage des Designs und des Kompromisses zwischen dem relationalen Modell und dem Objektmodell.

/ EDIT nach dem Lesen von Kommentaren: Wenn Ihre Daten durchsuchbar ("abfragbar") sein müssen, sollten Sie Ihre Daten NICHT als Blob speichern. Wenn jedoch einige Teile Ihrer Daten nicht durchsuchbar sein sollen , sondern eine Art von Metadaten, kann das Speichern dieses Datenteils als Objekt in einem Blob eine gute Lösung sein, insbesondere wenn diese Metadaten eine flexible Struktur aufweisen und kann sich von Objekt zu Objekt ändern.

Lassen Sie uns ein praktisches Beispiel dafür geben, wann ich dies in der Vergangenheit getan habe.

Wir haben eine Datenbank, die alle Daten für eine Multi-User-Anwendung enthält. Die Datenbank enthält auch eine Tabelle mit Benutzern mit ihren Zugriffsrechten. Alle diese Daten werden wie erwartet normalisiert.

Anschließend wird angefordert, dass sich die Anwendung merkt, welche Fenster ein Benutzer geöffnet hatte und was er gerade tat, damit der Status wiederhergestellt werden kann, wenn der Benutzer am nächsten Morgen mit der Arbeit beginnt.

• Erstens, wenn dies manchmal fehlschlägt, ist es nicht unverschämt

  • Wenn zum Beispiel jemand zum ersten Mal eine neue Version der Anwendung verwendet, werden die geöffneten Fenster vergessen, na und?

• Daher gibt es einen 100% igen Fallback, wenn sich die Objekte ändern und wir den Block nicht lesen können.

• Wir haben bereits eine zentralisierte Datenbank mit Zugriffskontrolle, Sicherung usw.
• Die Kosten für das Speichern der Daten in Dateien sind hoch, da die Dateien auf einem Dateiserver gespeichert werden müssen, auf den alle Benutzercomputer zugreifen können, oder es muss eine API geschrieben werden, um diese Dateien zu lesen.

Ein anderes Mal hatten wir eine Anwendung, die eine Menge lang andauernder Berechnungen durchführte, und die Benutzer wollten die Berechnungen ab dem letzten bekannten Punkt neu starten können, wenn es zu einem Stromausfall usw. kam. Eine andere Version von gibt es nicht Es war zu erwarten, dass die Anwendungen die Berechnungen neu starten, und da viele Objekte gespeichert werden mussten, wäre das Normalisieren der Daten teuer gewesen.

Da die Datenbank bereits vorhanden ist und für die wohldefinierten normalisierten Anwendungsdaten verwendet wird und es keinen wirklichen Grund gibt, sie nicht zum Speichern der Blogs zu verwenden, haben wir die sinnvolle und schnelle Option gewählt.

Ein sehr wichtiger Faktor: Die Java-Serialisierung (eine, die durch die Implementierung aktiviert wird Serializable) ist an sich ein sehr schlechtes Format, daher sollten Sie sie nicht wirklich für die dauerhafte Speicherung von Objekten verwenden.

Zu den Nachteilen der Java-Serialisierung gehören:

• Daten können in anderen Sprachen nicht wirklich gelesen werden.
• Es ist nicht sehr einfach, die Vorwärtskompatibilität von serialisierten Objekten aufrechtzuerhalten. Das heißt, wenn Sie Felder zur Klasse hinzufügen (oder daraus entfernen), ist es nicht so einfach, Objekte zu lesen, die mit früheren Versionen der Klasse erstellt wurden.
• Es ist nicht so schnell (aber Ihre Laufleistung kann variieren)

Wenn Sie also ein anderes Serialisierungsformat verwenden, erhalten Sie einen netten Key-Value-Speicher. Wenn Sie Java-Serialisierung verwenden, kommt es zu Problemen.

Dies ist ein interessanter Thread mit einigen gut durchdachten Antworten. Ich bin nicht mit allen Auswirkungen des Speicherns und Abrufens von serialisierten Objekten vertraut. Ich denke, es wäre interessant, die Antwort zu geben, die ich einem DBA-Team oder einem Entwicklungsteam geben könnte:

Der Schlüssel besteht darin, aktuelle und zukünftige Anforderungen zu erfüllen und die Lösung so einfach wie möglich zu halten, um zukünftige Supportarbeiten zu minimieren. Es müssen sowohl funktionale als auch nichtfunktionale Anforderungen (z. B. Infrastruktur und Datenbank) erfüllt sein. Erinnere dich an die 80/20 Regel. Verstehen Sie die Bedeutung der App für das Unternehmen und welche Entwicklungsanstrengungen angemessen sind.

Lassen Sie sich nicht vom Datenbankspeicher, der Geschwindigkeit und dem Arbeitsspeicher abhalten, wenn es keine Probleme gibt.

Wenn sich ein DBMS auf Ihrer genehmigten Liste befindet, können Sie es in einer Lösung verwenden, sofern die Kosten angemessen sind. Es ist kein Problem, eine relationale Datenbank zum Speichern einfacher Blobs zu verwenden, insbesondere wenn dies die Dinge vereinfacht.

Wenn die Lösung ein Prototyp oder eine frühe Phase / Version sein soll, muss noch mehr Wert darauf gelegt werden, die Dinge einfach zu halten. Sie können das Datenschema später jederzeit erweitern, solange Sie dies planen.

Denken Sie daran, dass relationale Datenbanken keine Integrität oder Konsistenz erzwingen, es sei denn, das Schema deckt einen eigenständigen Geschäftsbereich ab und die Geschäftsregeln sind streng. (Bei der Lösung der Frage nach dem serialisierten Objekt wird möglicherweise ein Repository im Wörterbuch- / Ontologiestil in Betracht gezogen, um Regeln durchzusetzen.)

Es ist zu berücksichtigen, dass alle relationalen Datenbanken keine reinen relationalen Datenbankschemata (z. B. Sterne, räumliche, nicht relationale) verwenden. Außerdem können Apps relationale Datenbanken wie in der vorliegenden Frage als nicht relationale Speicher verwenden. Viele Kerngeschäftsdatenbanken funktionieren auf diese Weise.