OR Mapper falls alles in einer Tabelle ist

verwendetes Datenbanksystem: SQL Server

Hallo Zusammen
Bin auf der Suche nach einem ORM welches folgendes unterstützt :
Habe eine Tabelle die als Datenbank misbraucht wird (sprich anstelle für jeden zweck eine eigene zu erstellen, wurden die Einträge einfach in diese gespeichert.) Das geht von Benutzernamen über Postleitzahlen zu Kategorien. Natürlich verweisen andere Tabellen dann auf diese Werte (jeder eintragstyp hat eine "eigenschaftsid" und eine eigene id.

Wie kann ich das am besten und möglichst schnell umsetzen?

(momentan mache ich einfach Views, ist aber auch nicht schön)

Gruss patahel

PS: nhibernate müsste das doch unterstützen...?

Klingt erst einmal nach sehr schlechtem DB Design, was ja jetzt schon Probleme macht da du zum trennen der Daten scheinbar mit Views um dich werfen musst.
Views zu machen umschifft das Problem nur, löst es aber in diesem Fall nicht sauber.
Sauber wäre es die Daten nach dem Relationen Modell zu trennen und entsprechend zu verteilen.

Ein OR Mapper nimmt dir die arbeit auch nicht ab.
Dies musst du als Programmierer lösen, dafür sind OR Mapper nicht da.
Diese erfüllen lediglich den Zweck, dass du dich als Entwickler nicht mit grundsätzlichen Dingen wie dem lesen/schreiben von Daten aus/in die DB beschäftigen musst.

Ansonsten kannst du jeden X beliebigen OR Mapper nehmen, den du willst.
Empfehlen könnte man Dapper oder falls du noch weniger mit SQL arbeiten willst, auch Entity Framework Core.
Wobei Dapper schneller ist und wegen der direkten Nähe zu SQL auch mehr Optimierungen bei den Abfragen erlaubt.

T-Virus

Danke für die schnelle Antwort.
Das es ein be******enes DB Design ist versuche ich den Anderen schon lange klar zumachen, aber die finden das ORMs scheisse sind, weil die ne saubere trennung der Daten erfordern (Access leute) .

Mir ist auch jlar das mir ein ORM die Arbeit nicht abnimmt, geht mir mehr darum dass ich das ganze zentraler regeln kann um fehler besser ausschliessen zu können.

Das schlimmste daran ist ja das die Mandanten fähikeit auch über die selbe Tabelle gelöst ist...

Über Dapper habe ich auch schon nachgedacht. EFcore habe ich bis jetzt verwendet, wird aber ermüdend für alles n View machen zu müssen

Gruss
Patahel

Ich würde sagen, dass es kein ORM dafür zu 100% gibt, weil es hellseherische Fähigkeiten erfordern würde.

Mir ist egal ob ich die Klassen schreiben muss und dazu eine where beschränkung. (das ich für jeden benötigten fall etwas ausprogrammieren muss ist logisch, hab nur kein bock alles von hand zu in die entsprechenden objekte abzufüllen)
Habuptsache ich kann diese in meinem Model verwenden...

Gruss
Patahel

Dann bräuchten wir mehr Details um das Problem besser lösen zu können.
Hier passt aber auch der Titel des Threads nicht so recht, da der OR Mapper hier nicht die Lösung ist sondern die Umsetzung des konkreten Problems.

Dazu wären aber Details wie der Tabellenaufbau und ein Beispiel hilfreicher.
Dann könnte man schauen wie man das Problem, unabhängig von OR Mappern, lösen kann.

Wenn ich den aktuellen Stand aus deinem Start Post richtig verstehe hast du grob folgenden Aufbau.

Tabelle (ID, EigenschaftsID, Wert)
Hierbei ist ID die Relations ID also der PK des jeweiligen Eintrags zu dem diese Eigenschaft gehört.
EigenschaftsID ist dann vermutlich ein Enum Wert für PLZ, Benutzername etc.
Und die "Wert" Spalte eben der konkrete Wert wie die PLZ oder der Benutzername.

Dann wirst du deine Objekte vermutich wie so auslesen, dass du pro ID mehrere EigenschaftID Einträge hast.
wenn du einen ganzen Eintrag mit z.B. 10 Eigenschaften hast, musst du auch alle 10 einträge aus der Tabelle lesen.

Vermutlich wäre es "einfacher" alle Einträge über ID auszulesen und dann im Code ein Objekt zu mappen, was eben die ID, Eigenschaft ID und Wert enthält.
Dann musst du nur noch eine einfache Methode bauen, die über die ID dann die Liste der Eigenschaften liefert.
Der Rest ist trockendes Datenmapping im Code, da wird dir aber kein OR Mapper helfen können.

Mein Tipp wäre es den Access Leuten oder deren Vorgesetztem klar zu machen, dass sie keine Ahnung von DB Design haben und dir die Arbeit damit unnötig schwer machen.
Auch wird mit solch einem Design die Datenbank unnötig aufgebläht und wird bei größeren Datenmengen wegen fehlender Datenteilung unbrauchbar langsam.
Hier können die Daten nich mal eigene Tabellen partitioniert werden, was auf lange Sicht zu Performance Verlust führen kann.
Je nachdem wieviele Objekte und Eigenschaften eingelesen werden müssen, wird der Prozess auch lange dauern.

T-Virus

Ich würd linq2db verwenden. Ist nicht so low level wie dapper, es kann z.B. LINQ. Und mit linq ist es schneller als ef core.

Du könntest die verschiedenen Typen in einer Tabelle dann z.B. über Inheritance abbilden.