Laden...

Übersicht Datenspeicherung: EF vs. herkömmliche Datenbanken

Erstellt von robin_ vor 6 Jahren Letzter Beitrag vor 6 Jahren 1.558 Views
R
robin_ Themenstarter:in
38 Beiträge seit 2017
vor 6 Jahren
Übersicht Datenspeicherung: EF vs. herkömmliche Datenbanken

Hallo,

Ich bin Datenbanken-Neuling und bräuchte mal kurz eure Meinung 😃

Also folgendes: Ich habe mich gerade grob eingelesen, um die Unterschiede der verschiedenen Möglichkeiten zu verstehen um dann eine Variante auszuwählen und mich damit tiefer zu beschäftigen.

Sehe ich es richtig, dass wenn man das Entity Framework verwendet und das EDM selbst erstellt (und nicht durch eine Datenbank generieren lässt), dass man mit der eigentlichen Datenbank nichts mehr zu tun hat? Ich meine damit zum einen den Zugriff auf Daten in der DB aber auch zb. den Installationsprozess: Bei SQL muss man ja zb. immer einen im Hintergrund laufenden Dienst haben (hoffe das habe ich richtig verstanden) und somit bei der Installation die DLL-Dateien bereitstellen, sofern dies rechtlich möglich ist.

Für meinen Anwendungsfall wären es vielleicht mal paar hundert Datensätze, welche durch verschiedene Objekte abgebildet werden würden, welche wiederum aus strings, ints, doubles etc. bestehen. Außerdem würde mindestens ein Bild in einem solchen Datensatz vorhanden sein (eher als Thumbnail gedacht).

Was haltet ihr von meinen Überlegungen?
Danke

MfG Robin

MfG Robin

6.911 Beiträge seit 2009
vor 6 Jahren

Hallo robin_,

Entity Framework (EF) ist keine Datenbank, sondern ein O/R-Mapper. Die Datenbank ist relational (das R) und in C# bist du objekt-orentiert (das O) unterwegs. An und für sich passen diese zwei Konzepte nicht zusammen (Impedanz), daher gibt es Unterstützung durch diese Mapper, welche dann von R -> O und O -> R umwandeln. Es ist also nur ein Hilfe für dich, damit du nicht per SqlDataReader, etc. das alles selbst machen musst.

Entity Framework ist -- v.a. in den letzten Entwicklungen -- unabhängig von der (relationalen) Datenbank. Ob hier SQL Server, SQL Server Compact, MySQL, Postgres, etc. verwendet wird ist egal. Hierzu nutzt EF die verschiedenen Provider.

Datenbanken laufen meist als Dienste. Beispielsweise wird der SQL Server installiert (gleicher od. anderer Rechner) und bei der Installation wird auch der SQL Server-Dienst installiert (und gestartet).
Als Benutzer einer Datenbank im SQL Server braucht somit nur die Verbindung aufgebaut werden, SQL abgesetzt (auch wenn es vom O/R-Mapper generiert wird) und gut ist es.

Damit ein O/R-Mapper weiß wie er dieses Mapping durchführen soll, muss dies konfiguriert werden. Beim EF geht das z.B. wie EDM. Das ist ein XML indem die Entitäten, deren Eigenschaften, etc. angeführt werden und auch wie diese als Objekte abgebildet werden können.
Anstatt dieses xml-basierten Konfiguration kann diese auch per Code erfolgen und das ist der Weg den EF in letzter Zeit präferiert. Beim EF Core (Neuentwicklung um Altlasten zu entfernen und "zugeschnitten" für .net Core um es nicht zu verwirrend zu machen) gibt es den Weg via EDM (im Moment) gar nicht.

Auf die eigentliche Datenbank kann dennoch wie gewohnt zugegriffen werden, z.B. per SQL Server Management Studio.

Bei der Installation einer Client-Anwendung braucht der Datenbank-Server nicht berücksichtigt werden. Dieser ist wie gesagt separat zu installieren.

Es gibt aber auch embedded / lokale Datenbanken, die Bestandteil deiner Anwendung sind und in diesem Fall müssen auch die DLLs mit ausgeliefert werden. Entsprechend deiner Frage willst du vermutlich auf so ein System hinaus. Suche mal danach -> Forumssuche nach lokale datenbank

Wenn es aber nur ein paar Hundert Datensätze sind, so kannst du es dir auch einfacher machen und das alles z.B. in einer XML Datei speichern und die Bilder legst du im Dateisystem ab.

mfG G

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

R
robin_ Themenstarter:in
38 Beiträge seit 2017
vor 6 Jahren

OK, also was EF ist habe ich glaube ich verstanden, es scheint mir vom Prinzip her gleich zu sein wie CoreData in Objective-C 😃

Ja, mir geht es vor allem darum, einen Overhead für diese "paar" Datensätze zu vermeiden.

Würde ich nun zb. mit SQL Server Express eine Datenbank erstellen und in meiner Anwendung mittels ADO.net o.ä. verwenden, so müsste auf dem Client-PC ebenfalls ein SQL-Server-Dienst installiert sein und laufen (richtig?) --> Für mich sieht das nach recht hohem Aufwand aus.

Danke für die schnelle Antwort!

/EDIT:

Sorry, mir ist das immer noch nicht ganz klar. Also, ja, man kann mit EF verschiedenste Datenbanken verwalten und das EF fungiert zwischen dem Code und der DB als Wrapper. Muss ich nun einen SQL Server - Dienst installiert haben (beim Client, wenn ich eine Datenbank als Datei als Ressource (wie ein Bild zb.) beilege? ) ?

Danke

MfG Robin

6.911 Beiträge seit 2009
vor 6 Jahren

Hallo robin_,

so müsste auf dem Client-PC ebenfalls ein SQL-Server-Dienst installiert sein und laufen (richtig?) --> Für mich sieht das nach recht hohem Aufwand aus.

Richtig. Daher gibt es für solche Szenarien auch lokale Datenbanken (siehe Suchlink oben).

Muss ich nun einen SQL Server - Dienst installiert haben (beim Client, wenn ich eine Datenbank als Datei als Ressource (wie ein Bild zb.) beilege? ) ?

Wenn du SQL Server haben willst, dann ja.
Es gibt aber z.B. SqLite, das ist eine embedded Datenbank, und diese besteht aus ein paar DLLs du mit deiner Anwendung verteilen kannst. Ein eigener Dienst ist dafür nicht nötig. Mit SQL Server Compact ist es auch so.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"