Diskussion:Object-relational impedance mismatch

message: Hi,
klingt für mich alles etwas merkwürdig. Ich dachte eher, das Problem liegt darin, dass relationale Datenbanken grundsätzlich zu Sprachen der vierten Generation wie SQL passen, Objektoriente Sprachen aber nur dritte Generation sind. Das bedeutet, das mengenbasierte Probleme eben nur schwer und mit prozeduralen Sprachen zu realisieren sind!
Zweifelhaft finde ich 
: "Die Daten einer relationalen Datenbank werden durch Transaktionen von einer verbundenen Anwendung modifiziert. Dies erinnert stark an das prozedurale Programmieren, "
Dabei gehören doch Objektorientierte Sprachen zur Familie prozeduraler Sprachen und SQL eher zu den deskriptiven Sprachen.
Auch fehlt meiner Meinung nach der Hinweis, dass ORM die DBMS Vorteile (wie z.B. beliebig große [atomare] Änderungen, ohne Konsistenzbedingungen zu verletzen oder anomalies zu erzeugen) zunichte macht, in dem 4GL auf 3GL reduziert wird. OO Sprachen wie C++ und Java bringen von sich aus keine Möglichkeit mit, Änderungen an Objekten zu Transaktionen zusammenzufassen, die erstmal für "niemanden sonst" sichtbar sind und ggf. "rückgängig" zu machen, als ob sie nie passiert wären (was wieder für niemand anders sichtbar ist), obwohl soetwas grundsätzlich denkbar wäre.
Ein weiterer meiner Meinung nach essentieller Unterschied ist, dass bei Objekten die "relationen" und deren Mächtigkeit grundsätzlich erstmal statisch sind (wenn eine Klasse Firma eine Liste von Angestellten hat, ist dieser Sachverhalt statisch; Relationen hingegen kann man "hinzufügen", teils zeitlich gegrenzt auf die Dauer einer Abfrage [z.B. Firmat _hat_ "Menge Hochverdiener"].
Liegt die Ursache für das scheinbare Problem nicht sowieso nur dadrin, mit der beschränkten OO-Sicht Datenkomplexität eben nur schwer handhaben zu können, weil das OO Paradigma nicht ausreicht, also 3GL OO Sprachen einfach "zu klein" sind, um 4GL darin einfach und elegant abzubilden?
oki,
Steffen (nicht signierter Beitrag von 
STD (Diskussion | Beiträge) 11:01, 1. Aug. 2011 (CEST)
thread_title:  Artikel inhaltlich richtig? 

message: Daten extern abzulegen und wieder einzulesen ermöglicht es den Aktivitätsträgern einer laufenden Programmausführung Daten über die Laufzeit des Programms hinweg zu retten. Basistypen (Zeichenkette, Zahl, ...) sind dabei gern genutzt, um beim Einlesen/Schreiben eine gewisse Datenqualität sicherzustellen. JSON, XML oder Tabellen sind nur temporäre Repräsentationen der Daten. In Kommunikationsprotokollen spricht man von Transferdarstellung. Dass die Datenkapselung bei der Serialisierung/Deserialisierung leidet ist normal und wird in Kauf genommen, um den Vorteil der Persistenz über Sekunde, Stunden, Tage, Jahrzehnte, Äonen zu erhalten.
Wenn man den Artikel so liest, dann denkt man Serialisieren von Objekten in Tabellen ist schlecht. Ist die Serialisierung eines Objekts in ein JSON-File besser?
Auf die Unverträglichkeit hinzuweisen und auf Alternativen hinzuweisen ist ok, es kommt aber nicht rüber, warum sich dies überhaupt jemand antut - den Nutzen! Werde in der Einleitung eine kleine Ergänzung machen.
--Ksweber (Diskussion) 10:22, 9. Aug. 2017 (CEST)
thread_title:  Anwendungsfall verkannt 

message: Habe die Änderung vom 9.8. von Benutzer:Ksweber zurückgesetzt - . Grund: ziemlich massiver Umbau mit zumindest teilweise falschen Dingen:
* Es geht hier nicht ums archivieren, sondern tatsächlich ums Speichern (zur Laufzeit der Applikation)
* Es geht nicht nur um Serialisierung/Deserialisierung, sondern auch um Suchen etc.
:: Persistenz dient dazu Sachverhalte über die eigene Lebenszeit hinwegzuretten (Risikomanagement). Die Lebenszeit einer Anwendung kann auch durch Stromausfall verkürzt werden. --Ksweber (Diskussion) 08:34, 29. Aug. 2017 (CEST)
replies: text:  In einer Klasse würden Wiederholgruppen Attribute mit Multiplizität größer 1 genannt. Bei der Abbildung der objektorientierten Sicht auf die Relationen ist das kein Problem, weil diese Wiederholgruppen als Konzept dafür vorsehen. Erst bei der Abbildung der Relationen auf Tabellen des physischen Schemas muss man zur Unterstützung der 1:1-Abbildung erst Wiederholgruppen auflösen, indem man sie in eigene Tabellen auslagert. --Ksweber (Diskussion) 08:34, 29. Aug. 2017 (CEST)
replies: text:  Mir geht es nur darum, dass ein künstlicher Identifikator herangezogen wird, wenn die Attribute der Instanzen diese Funktion nicht übernehmen können. Die als überlegen dargestellte OO-Objektid ist in Wahrheit auch nur ein Zeiger auf das Objekt im Speicher. Sehe hierbei keinen Impedanz-Mismatch! --Ksweber (Diskussion) 08:34, 29. Aug. 2017 (CEST)
thread_title:  Änderungen vom 9.8. 

message: - wer entscheidet jetzt über meine Änderungsvorschläge vom 9.8., die wohl in Teilen als akzeptabel gesehen werden, aber in Gänze zurückgenommen wurden? --Ksweber (Diskussion) 11:01, 20. Dez. 2017 (CET)
thread_title:  Nächste Schritte 

message: Der Absatz ist etwas verschrubelt und unbelegt. Bei der Änderung durch  steht zwar als Referenz https://www.martinfowler.com/articles/nosqlKeyPoints.html dabei, aber dort finde ich nur "Application developers have been frustrated with the impedance mismatch between the relational model and the in-memory data structures.".
Ich finde es gut, wenn geschrieben wird, was und wie NoSQL den OR-Impedance Mismatcht löst. Aber der jetzige Text ist mMn falsch bzw. unpassend:
* "Bei der Speicherung von Daten in schemafreien Datenbanken kann jeder Datensatz eine andere innere Struktur haben." - das bringt doch beim OR-IM nichts oder?
* "Der Anwendungsentwickler bildet seine Anwendungsdaten nicht mit mehr auf ein normalisiertes Relationenmodell ab; stattdessen haben die Datensätze unterschiedliche Felder oder es wird auf eine hierarchische Datenstruktur abgebildet; oft auch denormalisiert." - nur ab "hierarchische ..." hat das was mit OR-IM zu tun oder?
* "Die Reibungsverluste durch den Object-Relational Impedance Mismatch entfallen und es entstehen Kosten durch einen anderen Impedance Mismatch." - welcher "andere" IM? Dass die Reibungsverluste des OR-IM entfallen sehe ich nicht so, von den oben genannten Punkte (Struktur, Identität, Datenkapselung, Arbeitsweise) wird durch NoSql nur der erste Punkt und auch der nicht vollständig ("Objekte enthalten sowohl Daten als auch Verhalten" wird bei NoSql nicht unterstützt) gelöst. --Sebastian.Dietrich   ✉  17:20, 22. Mär. 2022 (CET)
thread_title:  NoSQL