Diskussion:Object-relational impedance mismatch

Englischer Titel??

Dies ist der deutschsprachige Bereich der Wikipedia. Entsprechend sollten die Titel demnach auch auf Deutsch lauten.

Statt die englische Bezeichnung unreflektiert zu kopieren (und statt eine falsche Übersetzung - wie im Text aktuell vorhanden - anzubieten), schlage ich deshalb vor, den Titel korrekt auf Deutsch zu verfassen:

Leistungsabweichungen zwischen Objekt- und relationalen Beziehungen.

Damit erübrigt sich dann jede weitere Erläuterung.

--My2Cents (Diskussion) 15:10, 16. Jul. 2022 (CEST)

Der Vorschlag ist aus zwei Gründen abzulehnen. Zum einen handelt es sich hier um den Versuch der WP:Begriffsfindung. Der Begriff "Impedance Mismatch" hat sich in Lehre und Wirtschaft etabliert, siehe z.B. https://www.ionos.de/digitalguide/hosting/hosting-technik/relationale-datenbanken/ und https://www.dbs.ifi.lmu.de/Lehre/DBS/WS-2008/Skript/dbs1_10.pdf#page=14. Zweitens hat die vorgeschlagene Übersetzung "Leistungsabweichungen" mit dem eigentlichen Problem nicht viel zu tun. Daten aus einer objektorientierten Anwendung in eine relationale Datenbank zu speichern, wirkt handwerklich so, als ob man ein Auto in seine Einzelteile zerlegen müsste, bevor man es in die Garage kriegt; das Gefühl der Ganzheitlichkeit geht verloren, und in der Folge manchmal auch die Übersicht. Leute wie Ted Neward haben versucht, diesen Sachverhalt als einen unpassend hohen Widerstand zwischen einem Stromverbraucher und einer Batterie zu erklären.

Ich bin nicht grundsätzlich gegen Eindeutschungen wie z.B. Stapelspeicher statt Stack, doch bei so einem Randphänomen wie dem Impedance Mismatch wird sich das nicht durchsetzen, der anglo-amerikanische Diskurs war eben zuerst da und wurde von Technikern in anderen Kulturkreisen reflektiert übernommen, nicht jede Reflexion muss zu einem neuen Wortungetüm führen. Ich wäre aber dabei, im Einleitungssatz eine bessere Übersetzung als "objektrelationale Unverträglichkeit" zu finden, gerne etwas freier. Ich würde das eher objekt-relationalen "Umformungsversatz" oder (lateinischer) "Transformationsdiskrepanz" nennen, etwas, was beim Abbilden von Objekten auf relationale Tupel entsteht. --T. Wirbitzki (Diskussion) 09:55, 17. Jul. 2022 (CEST)

Bin auch dagegen - insbesondere wegen WP:Begriffsfindung. Es geht bei dem OR impedance mismatch auch nicht um "Objekt- und relationale Beziehungen", sondern um OO vs. Relational. Da sind die Beziehungen nur ein Teil davon - siehe Absatz Object-relational impedance mismatch#Unterschiede --Sebastian.Dietrich  ✉  10:11, 18. Jul. 2022 (CEST)

Artikel inhaltlich richtig?

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

Anwendungsfall verkannt

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)

Änderungen vom 9.8.

Habe die Änderung vom 9.8. von Benutzer:Ksweber zurückgesetzt - [1]. 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)

• Was sind "Wiederholgruppen"?

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)

• Primärschlüssel muss nicht Seriennummer sein, kann auch z.B. UUID sein

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)

--> Bitte um Diskussion... --Sebastian.Dietrich ✉ 08:02, 14. Aug. 2017 (CEST)

Nächste Schritte

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

NoSQL

Der Absatz ist etwas verschrubelt und unbelegt. Bei der Änderung durch @Ksweber: 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)