Datenmodelle poste / prüfen / bewerten möglich?
MB
Datenmodelle poste / prüfen / bewerten möglich?
MB
moin Community,
bevor es ans eingemachte geht kommt man nicht um Datenmodelle rum. Meine Frage ist daher ob man hier UML Strukturdiagramme aller Art posten und bewerten kann. und wenn ja, unter welcher Rubrik man dies stellen soll.
vlg
MB
akzeptierte Antworten
Datenmodelle poste / prüfen / bewerten möglich?
Bewertung: −2, 4 Stimmen
-
Vor ungefär 15 Jahren hab ich beim Entwickeln komplexer Webanwendungen mal gesagt, ein Hash-of-Hashes, entspricht Schlüssel/Schlüssel/Wert, ist völlig ausreichend für den Random Access persistenter Daten nachdem diese deserialisiert wurden. Zumal sich mit diesem abstrakten Datentyp, heute eher bekannt als Entity/Attribut/Value (EAV) Muster zyklische, also sich wiederholende Datenstrukturen abbilden lassen.
Bis heute hat sich an dieser Ansicht nichts geändert, je einfacher ein abstrakter Datentyp aufgebaut ist, desto einfacher ist es, Daten außerhalb des Hauptspeichers zwischen Anwendungen verschiedener PLs auszutauschen (Perl-JS-Perl) und egal ob die Daten auf Platte geschrieben oder nur trasportsicher verpackt werden sollen (AJAX).
Tatsächlich waren Abweichungen von diesem EAV-Muster in meiner gesamten beruflichen Praxis die Ausnahme und anstatt kompliziertere ggf. vorgegebene Strukturen einfach so zu übernehmen, hab ich die soweit möglich auf das EAV Muster heruntergebrochen. So ists z.B. durchaus möglich, an die Stelle eines Values wieder ein EAV Type einzuhängen, was den Programmieraufwand erheblich vereinfacht und unnötigen redundanten Code vermeidet. Gleichermaßen wird ein Persistent- bzw. Transport-Layer transparent, wenn dieselben Algorithmen in verschiedenen PLs gleichermaßen implementiert sind.
Geb ich Dir gerne weiter, keine Ursache. Auch für den Wiki.
-
Lieber pl,
Vor ungefär 15 Jahren hab ich beim Entwickeln komplexer Webanwendungen mal gesagt, ein Hash-of-Hashes, entspricht Schlüssel/Schlüssel/Wert, ist völlig ausreichend für den Random Access persistenter Daten nachdem diese deserialisiert wurden.
Du meinst mehrdimensionale Arrays mit Hash of Hashes?
Bis heute hat sich an dieser Ansicht nichts geändert, je einfacher ein abstrakter Datentyp aufgebaut ist, desto einfacher ist es, Daten außerhalb des Hauptspeichers zwischen Anwendungen verschiedener PLs auszutauschen (Perl-JS-Perl) und egal ob die Daten auf Platte geschrieben oder nur trasportsicher verpackt werden sollen (AJAX).
Habe ich auch beantwortet bekommen auf meine Fragen fern vom unterricht. Danke für die Bestätigung ;-)
Tatsächlich waren Abweichungen von diesem EAV-Muster in meiner gesamten beruflichen Praxis die Ausnahme und anstatt kompliziertere ggf. vorgegebene Strukturen einfach so zu übernehmen, hab ich die soweit möglich auf das EAV Muster heruntergebrochen.
Warum???
So ists z.B. durchaus möglich, an die Stelle eines Values wieder ein EAV Type einzuhängen, was den Programmieraufwand erheblich vereinfacht und unnötigen redundanten Code vermeidet. Gleichermaßen wird ein Persistent- bzw. Transport-Layer transparent, wenn dieselben Algorithmen in verschiedenen PLs gleichermaßen implementiert sind.
Das verstehe ich nicht??? Und auch den Zusammenhang meiner Frage nicht. Aber Ich glaube mittlerweile weist du dass ich ein wenig begriffsstutzig bin. Man verzeihe mir dafür.
Und es ist mir ein wenig unangenehm. Ein Teil dieser Begriffstutzigkeit liegt daran das ich auf einer stark geprägten sachlichen ebene kommuniziere. Ich raff in der appelativen z.B. nichts.
Meine Frage ist nur ob es möglich ist ein UML Diagramm hier zu bewerten und welche Rubrik ich da nehmen muss damit es besser gefunden wird. Das Paradigma MVC und einige andere Design Patterns finde ich sinvoll und wollte die in meinem Code einbauen zur struktur und zur besserer Dokumenation.
Gute Nacht bzw. Guten Morgen,
Herzlichste Grüße MB
-
Tach!
Vor ungefär 15 Jahren hab ich beim Entwickeln komplexer Webanwendungen mal gesagt, ein Hash-of-Hashes, entspricht Schlüssel/Schlüssel/Wert, ist völlig ausreichend für den Random Access persistenter Daten nachdem diese deserialisiert wurden.
Du meinst mehrdimensionale Arrays mit Hash of Hashes?
Er meint anscheinend, dass eine relativ einfache und sehr allgemein gehaltene Datenstruktur die Lösung aller Probleme sei. Klingt zu gut um wahr zu sein. CSV ist beispielsweise eine sehr einfache Möglichkeit, eine Datenbank zu bauen. Aber wenn man genauer hinschaut, hat das eine Menge Nachteile gegenüber einem solch komplexen Gebilde wie einem SQL-DBMS. Und natürlich ist auch ein solches nicht in jedem Fall das Non-Plus-Ultra. Das muss man gegen den konkreten Anwendungsfall prüfen.
Wenn man überall assoziative Arrays verwendet, sieht das auch einfach aus. Der Teufel ist aber das Detail, dass die Keys alles Strings sind und damit ist eine Eindeutigkeit nicht mehr gegeben. Ist denn "foo" gleich "foo" oder ist das zufällig nur der gleiche Wert für zwei unterschiedliche Dinge? Man kann es oft nicht auf den ersten Blick erkennen. Leichte Erkennung, was ein Code macht, ist wichtig für das Verstehen und die Wartung. Besonders IDEs tun sich schwer damit, eindeutige Codevervollständigung für solche string-basierten Geschichten zu bieten. Ein Objekt einer vorher definierten und mit PhpDoc (gibts auch für andere Sprachen) maschinenlesbar dokumentierten Klasse ist wesentlich eindeutiger und damit besser durch die IDE unterstützbar. Natürlich ist es komplexer als ein einfaches Array, doch es hat auch entscheidende Vorteile gegenüber einem solchen.
Mit Arrays als Datensammlung kann man auch keine Funktionsparameter mit Typehint oder in streng typisierten Sprachen mit einem konkreten Typ hinterlegen. Somit kann einem auch die IDE und der Compiler nicht darauf hinweisen, dass man da was unerwartetes zu übergeben versucht. Will man all solche Nachteile haben, zugunsten eines einfach aussehenden und zu einfach seiendem Datenmodell? Ich nicht. EAV ist eine tolle Sache - da wo man eine solche Flexibilität benötigt. In einem Shopsystem, wo man beim Entwickeln nicht wissen kann, wieviele und welche Attribute die Artikel beschreiben werden, ist so ein flexibles Datenmodel von Vorteil. Aber für zur Entwicklungszeit bekannte Eigenschaften von Objekten brauche ich diese Flexibilität nicht. Da brauch ich vielmehr die Typsicherheit.
Meine Frage ist nur ob es möglich ist ein UML Diagramm hier zu bewerten und welche Rubrik ich da nehmen muss damit es besser gefunden wird.
Ja, wir werden solche Fragen garantiert nicht löschen und wenn sich jemanden mit entsprechendem Wissen und Zeit findet, wirst du sie beantwortet bekommen. Rubrik? Wenn du keine passende in der Liste der Tags findest, nimm erstmal "Sonstiges", wird schon jemand anpassen.
dedlfix.
-
Hallo Dedlfix,
Ja, wir werden solche Fragen garantiert nicht löschen und wenn sich jemanden mit entsprechendem Wissen und Zeit findet, wirst du sie beantwortet bekommen. Rubrik? Wenn du keine passende in der Liste der Tags findest, nimm erstmal "Sonstiges", wird schon jemand anpassen.
Besten Dank für den Tipp, vlg MB
-
EAV ist eine tolle Sache - da wo man eine solche Flexibilität benötigt. In einem Shopsystem, wo man beim Entwickeln nicht wissen kann, wieviele und welche Attribute die Artikel beschreiben werden, ist so ein flexibles Datenmodel von Vorteil. Aber für zur Entwicklungszeit bekannte Eigenschaften von Objekten brauche ich diese Flexibilität nicht. Da brauch ich vielmehr die Typsicherheit.
So flexibel ist EAV im Übrigen auch nicht, man kann darin zum Beispiel keine Hierarchien oder Zykel auf natürliche Weise abbilden. Solche Struktureigenschaften müssen deshalb über künstlich hinzugefügte Attribute kodiert werden. Das führt dann dazu, dass man Daten der Anwendungsdomäne mit Daten, die ausschließlich der internen Verwaltungen dienen, mischt. Bäume und Graphen, respektive, sind für die beiden genannten Fälle die geeigneteren Datenstrukturen. Der Vorteil dieser Linearitäts-Eigenschaft von EAV ist natürlich, dass man sie sehr einfach in SQL-Tabellen speichern kann.
-
-
-