speicheren Kosten der Forschung und Entwicklung beeinträchtigen die
> Bilanz schon gewaltig. Und ob das Teil dann ein Erfolg wird, ist ja
> längst nicht sicher. Da müsste also schon im Voraus klar sein, dass
> diese und jene Partner bei diesem neuen “Standard” mitziehen
> werden.
Das kann man verhandeln.
> > Intel ist aber auch nicht DIE Marktmacht. Wenn Intel sagt ich
> will
> > DRDRAM und die Speicherhersteller sagen “iss nich” dann iss nich.
>
> Sicher wahr, aber die Macht von Intel sollte wahrlich ausreichen,
> um
> einen Einstieg möglich zu machen. Intel hat die nötigen
> Marktanteile,
*g* Stimmt, wenn schon eine Softwarefirma den Hardwareherstellern
vorschreibt: “Hey wir brauchen da ein paar Zusatztasten auf der
Tastatur” und heute bekommt man keine Tastatur mehr ohne.
> Intel. VIA selbst wird allerdings sicher kein Speicherinterface
> entwickeln, das ist nicht ihr Ding, selbst wenn sie mit PC133 Intel
> zuvorkamen (eine Weiterentwicklung bzw. Ausdehnung ist noch lange
> keine
> Eigen-Neuentwicklung)
VIA alleine sicherlich nicht, aber in einem großen Konsortium schon.
> Hehe, die sich zusammenschließen und vereint gegen den bösen Feind
> stellen. Da glaub ich nicht dran, da will doch jeder das größte
> Stück
> vom Kuchen.
Haben aber nicht die ganzen großen Firmen JEDEC gemeinsam
verabschiedet? Warum nicht nocheinmal gegen einen gemeinsamen
Ausbeuter?
Farnsworth

> wenn Samsung die billigeren NAND-flashs schon mit 17MByte beschreiben
> kann….
Schneller Flash-Speicher mit 2 GBit
http://www.heise.de/newsticker/meldung/74785
…
Gängige SLC-Chips erlauben etwa 100.000 Löschzyklen, MLC-Speicher nur
10.000.
Samsung setzt MLC-Technik ein, wie Intel STRATAFLASH…
Genusion setzt wahrscheinlich die von AMD/Spansion bekannte
Mirrobit-Technik ein, lizensiert von Saifun:
GENUSION serves as a representative for Saifun NROM Technology

>
> > 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.
Kannst ja mal einen Join auf einem hiearchischen System machen, das
die entsprechenden Indizes etc. nicht hat. Da musst du die ganze
Logik clientseitig implementieren, incl. linearer Suche statt
indexbasierter, und tausender Roundtrips zum Server statt eines
einzigen. Wie macht man denn bei XML-Datenbanken Joins? Mit XSLT?
> 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.
Klar. Die Frage ist, ob das soviel ändert. Kann man in
XML-Datenbanken Primärschlüssel, Sekundärindizes etc. anlegen?

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

> 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.

>
> > 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

speicher..legen länger?
> >
> > In meiner IT-Frühzeit, wusste man noch, dass es verschiedene
> > Datenbankparadigmen gibt: Netzwerk-BDs, hierarchische und
> > relationale. Letztere haben dabei den großen Nachteil, dass sie (a)
> > keine Strukturinformationen in der datenbank haben (heute nicht mehr
> > ganz richtig)
>
> Seit eh und je ist ein Katalog Bestandteil einer relationalen
> Datenbank, und der enthält alle Strukturinformationen.
Hier muss ich Dir leider widersprechen. Für die sogen. RDBMS trifft
das vollumfänglich zu. Leider sind aber auch Produkte wie dBase,
Foxpro, MS Access, MySQL u.v.a.m zu den relationalen Datenbanken,
wenn auch nicht zu den Client/Server basierten Systemen sondern eher
zu den File-Server-basierten Systemen zu rechnen. Keine der genannten
hat seit jeher einen Katalog. IBMs erste Referenzimplementierung RDB
und die Nachfolger bis hin zum DB/2 allerdings haben seit jeher einen
Catalog.
> > 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.
> Auch kann ein RDBMS eine interne Denormalisierung durchführen.
> Leider können die heutigen DBMS das nicht. Die Folge ist, dass man
> beim Datenbankdesign der Performance wegen eine Denormalisierung
> macht und sich damit dann Probleme mit der Datenintegrität
> einhandelt.
Das die heutigen RDBMS keine interne Denormalisierung der Daten
durchführne können ist (so wie ich die behauptung vom Lesen her
verstehe) schlicht und einfach “Unsinn”. Man schaue sich nur z.B.
Oracles Materialized Vews an.
> > Für viele Anwendungen sind RDBMS nicht geeignet, da sie jedoch gut
> > auf die “klassischen” Datenbankanwendungen passen, haben sie sich so
> > weit durchgesetzt, dass heute jeder mit “Datenbak” “relationale
> > Datenbank” meint. Bei der Persistenz von Objekt- und XML-Strukturen
> > kommen aber alte Bekannte wieder zum Vorschein: ein OODBMS ist
> > nämlich nichts weiter, als eine Netwerk-DB mit speziellen
> > Mapping-Mechanismen, eine XML-DB ist eine hierarchiche DB.
> >
>
> 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.
>
> 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.
masltov

> > Ich vermute, die Bezeichnung bidirektional wurde verwendet, um zu
> > betonen, dass die 3.2 GB/s sowohl für Lese- als auch für
> > Schreibzugriffe gelten.
>
> Nein, das wäre Asynchrone Datenübertragung
Tja, das war wohl ein Griff in’s Klo:
Synchrone Ãœbertragung bedeutet, daß Empfänger und Sender von Daten im
gleichem Takt sind und somit keine Taktinformation mit den Daten
übertragen wird.
Asynchrone Ãœbertragung bedeutet, daß der Sender mit den Daten
zusätzlich eine Taktinformation an den Empfänger überträgt.
Im übrigen beinhalten viele asynchrone Datenübertragungen in der Praxis
auch synchrone Elemente (robuster). Nämlich immer dann wenn der Takt
übertragen wurde, läuft der Empfänger eine bestimmte Zeit synchron zum
Sender.
Z.b. bei RS232: Das Stopbit kann jederzeit gesendet werden, also
asynchron, danach folgen im festgelegtem Zeitraster die 8 Datebits und
das Stopbit, also syncrone Ãœbertragung.
Alles klar?

> …legen länger?
>
> In meiner IT-Frühzeit, wusste man noch, dass es verschiedene
> Datenbankparadigmen gibt: Netzwerk-BDs, hierarchische und
> relationale. Letztere haben dabei den großen Nachteil, dass sie (a)
> keine Strukturinformationen in der datenbank haben (heute nicht mehr
> ganz richtig)
Seit eh und je ist ein Katalog Bestandteil einer relationalen
Datenbank, und der enthält alle Strukturinformationen.
> 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.
Auch kann ein RDBMS eine interne Denormalisierung durchführen.
Leider können die heutigen DBMS das nicht. Die Folge ist, dass man
beim Datenbankdesign der Performance wegen eine Denormalisierung
macht und sich damit dann Probleme mit der Datenintegrität
einhandelt.
> Für viele Anwendungen sind RDBMS nicht geeignet, da sie jedoch gut
> auf die “klassischen” Datenbankanwendungen passen, haben sie sich so
> weit durchgesetzt, dass heute jeder mit “Datenbak” “relationale
> Datenbank” meint. Bei der Persistenz von Objekt- und XML-Strukturen
> kommen aber alte Bekannte wieder zum Vorschein: ein OODBMS ist
> nämlich nichts weiter, als eine Netwerk-DB mit speziellen
> Mapping-Mechanismen, eine XML-DB ist eine hierarchiche DB.
>
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.
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.

> Die Hierarchie von XML ist zwar gut und sinnvoll, fuer mich jedoch
> aehnlich beschraenkt wie die Hierarchie von ueblichen Dateisystemen.
> afaik kann man Daten mit XML nicht nach mehreren Hierarchien ordnen,
> also eine Datei (um beim FS zu bleiben) mehreren baumartig sortierten
> Kategorien/Ordnern zuordnen.
Also hier geht genau das mit UFS problemlos, die multiplen Referenzen
– durchaus in verschiedenen Verzeichnissen — auf eine Datei,
welche im Dateisystem über eine eindeutige Nummer angesprochen wird,
existieren völlig gleichberechtigt nebeneinander. Erst nach Entfernen
der letzten Referenz wird die Datei gelöscht. Diese Technik ist
übrigens nichts neues, sondern existiert bereits seit Jahrzehnten.
Nur weil FAT es nicht kann, heißt es nicht, daß es überhaupt nicht
geht.
Ob es mit XML auch geht, darüber erlaube ich mir kein Urteil, weil
ich zur Zeit zu wenig darüber weiß.
> Das geht bei relationalen Datenbaenken doch relativ geschickt, auch
> wenn beileibe nicht optimal: der Kategorien-Baum wird rekursiv
> aufgebaut und die Daten in einer m:n-Verbindung zugeordnet.
IMHO will M$ mit dem neuen