Skyline of Richmond, Virginia

Re: virtueller Speicher - Echter Rechtsstreit um virtuelles Spielz…

08.27.08

speicher Freundin lacht sich immer kaputt, wenn es um virtuellen
> Speicher geht.
> Mit der Erklärung das es eigentlich eine Auslagerungsatei ist, konnte
> sie schon eher umgehen.
> Wahrscheinlich hat sie Recht und das ganze virtuelle Zeugs ist purer
> Brainfuck.
Mich stört Virtualität nicht, sofern es Kommunikation erleichtert
oder überhaupt erst ermöglicht - aber einen Großteil meines Lebens in
einer virtuellen Welt verbringen wäre vergeudete Zeit.
Für manche ist ein virtuelles Leben wohl angenehmer, oder leichter.
Die persönlichen Defizite, ob nun körperlich oder sozial, lassen sich
leichter verstecken - sollen sie doch an ihren Tastaturen
festwachsen…ob das nun ein Brainfuck ist oder nicht…die sind in
ihrer virtuellen Welt schmerzfrei ;-) > Mal ehrlich, ich verachte solche Typen, die diese Konstrukte als real
> behandeln.
Das ist nur Mittel zum Zweck - wäre kein Geld im Spiel würde sich
wahrscheinlich niemand so sehr darüber aufregen und einen Prozess
anzetteln.
Es wird doch mittlerweile jeder Scheiss zu Geld gemacht.
Verzicht ist das wirkungsvollste Mittel solchen Bestrebungen das
Wasser abzugraben. Wo keine Nachfrage, da kein Angebot.
> Wo ist denn da noch der Unterschied zu einem, der auf LSD
> hängengeblieben ist?
Der erlebt die Welt ohne jeglichen Wahrnehmungsfilter.
Dr-Gonzo

Effizienz und Real-World-Daten - iX 8/2003, S. 42: XML-Speicher

08.27.08

> Das relationale Datenmodell ist IMHO wesentlich flexibler,
Das stimmt. Man kann damit alles abbilden (man kann übrigens auch
jedes Programm rekursiv implementiern).
> effizienter
Hast Du jemals darüber nachgedacht, was z.B. bei einem Join passiert?
Etwas ineffizienteres, als relationale Datenbankzugriffe gibt es gar
nicht. Die Hersteller der RDBMS stecken einigen Aufwand in
Optimierungen, damit die Sache erträglich wird.
> und näher dran an real-world-Daten.
Wohl kaum. Die “Real-World” ist objektorientiert, und
objektorientierte Strukturen lassen sich nicht vernünftig in
relationalen Datenbanken speichern.
> Hierarchische DBs
> sind sei ein paar Jahrzehnten out.
hierarchische Datenhaltung ist nach wie vor sehr üblich
(->Dateisystem). Nur weil es kaum explizite hierarchische DBMS gibt,
bedeutet das nicht, dass die entsprechenden Mechanismen nicht mehr
eingesetzt werden.
Mit dem XML-Hype (für dessen Sinn ich nicht unbedingt plädieren will)
kommen sie vielleicht zurück.
> XML ist was für Datenaustausch, als Speicherformat ist es eher
> ungeeignet.
Das ist ein wenig Paradox, denn das Speichern von Daten in einer
Datenbank besteht zu einem wesentlichen Teil aus dem Datenaustausch
zwische DBMS und Anwendung. Wenn sich XML für diesen Austausch eignet
(was Du ja behauptest), warum sollten die Daten vor der Speicherung
noch einmal umgeformt werden?
Abgesehen davon scheinen viele Leute zu meinen, dass XML-Datenbanken
intern ein XML-ASCII-Format benutzen. Ich gehe eigentlich davon aus,
dass sie irgendwelche Strukturen benutzen, die logisch dem XML-Format
entsprechen.
M.Z.H.

Re: XML: Mit Volldampf zurück in die Datenbank-Steinzeit? - iX 8/2003, S. 42: XML-Speicher

08.27.08

>
> > M.Z.H. schrieb am 9. Juli 2003 10:00
> >
> > > und dass (b) die Verknüpfung der Daten zur Laufzeit
> > > sehr aufwändig ist.
> >
> > Das trifft zwar auf die derzeitigen Implementierungen zu, ist aber
> > kein Problem des relationalen Modells. Nichts hindert ein RDBMS
> > daran, Sätze in Tabellen, die oft gejoint werden, intern mit
> > Datenbank-Pointern zu verknüpfen.
>
> Das passende Gegenargument an dieser Stelle lautet wohl eher:
>
> In RDBMS ist es wenigstens möglich eine valide und validierte
> Verknüpfung der Daten zur Laufzeit durch datenbank eigene Mechanismen
> herzustellen. Das Problem von Objektdatenbanken, wie auch von
> XML-Datenbanken ist doch, dass die Validität von Objektreferenzen
> nicht sichergestellt werden kann. Schon alleine deshalb nicht, weil
> Objektdatenbanken kein beweisbares mathemathisches Modell zu grunde
> liegt. Das aber ist mit der Mengenlehre bei den RDBMS grundsätzlich
> anders.
Nuja… so ganz kann man das wohl nicht gelten lassen. Natürlich kann
die Referenzierung geprüft und auch intakt gehalten werden.
>
>
> > Was sich zur Zeit abspielt, ist schon ziemlich verrückt:
> >
> > Der so ziemlich einzige Vorteil von XML (wenn es um Daten und nicht
> > um Dokumente geht) ist, dass es ein Format ist, auf das sich die
> > verschiedenen Hersteller einigen konnten.
> >
> > Weil nun Daten im - wie zu Recht bemerkt - hierarchischen XML-Format
> > ausgetauscht werden, sollen sie nun plötzlich wieder hierarchisch
> > gespeichert werden und wir sind was Datenmodelle betrifft wieder in
> > den 50ern angelangt.
Jein. Wenn Du auf CODASYL etc. ansprichst, so stimmt dies nicht ganz.
Der Vorteil von XML ist die Flexibilität und die Verfügbarkeit von
Tools. Ohne die Tools ist die Verpackung in XML kein Vorteil, sondern
ein Nachteil. Mit Tools und Libs kann ich aber automatisch
einkommende Daten validieren und darauf zugreifen. Das kann ich mit
allen idiotischen Binärformaten, die zu zehntausenden in den letzten
30 Jahren definiert wurden nicht.
> >
> > Da aber das hierarchische Modell schon früher nicht vernünftig
> > funktioniert hat, wird den XML-Datenbanken nach meiner Einschätzung
> > auch kein Erfolg beschieden sein. Allen Daten eine Hierarchie
> > überzustülpen und die übrigen Beziehungen mit Refernzen auszudrücken
> > ist nun mal kein brauchbarer Ansatz zur Datenmodellierung.
>
> full ack. Oder wie Date zu sagen pflegte, wer das relationale Modell
> verstanden hat, weiß, dass Objektdatenbanken überflüssig sind.
Auch wieder nur halb. Es geht ja auch um den Zugriff und die
Transformation. Zudem kann man in OODB rekursive Zugriffe machen. Das
ist ein Paradigma, welches relationalen Datenbanken fern ist.
Aktuell würde ich die Zukunft am Ehesten in Objektrelationalen DB’s
sehen, die mich genau dabei unterstützen. Auch das Benutzen von
DataBlades (oder wie sie auch in welchem Produkt auch heissen mögen)
erweitert die Möglichkeiten sehr.
Ich stimme Dir dahingehend zu, dass man mit RDBs garantiert weit über
95% aller Fälle ausreichend und genügend abdecken kann, aber eben
nicht allzuviel.
Der eigentliche Vorteil von XML ist einfach die Universalität. Mit
einem “Insert”-Statement-Dump kann ich nicht viel anfangen. SQL ist
auch viel zu verwässert für universelle Lösungen. Aber aus XML
(zusammen mit nem schönen Schema) kann ich nahezu alles machen.
Automatische Code-Generierung für Zugriffsklassen, einfaches
Validieren und Parsen etc.pp. (hier empfehle ich einen ausführlichen
Blick auf .NET), Transformation in andere Formate, ohne die Kodierung
der Daten selbst anzugreifen, die Möglichkeiten sind wirklich
enorm…
hedgens