AGB  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Netzwerke C# Erfahrungen ORM mit Firebird

Erfahrungen ORM mit Firebird

Ein Thema von Morphie · begonnen am 3. Jul 2012 · letzter Beitrag vom 4. Jul 2012
Antwort Antwort
Seite 2 von 2     12
taveuni

Registriert seit: 3. Apr 2007
Ort: Zürich
274 Beiträge
 
Delphi XE2 Professional
 
#11

AW: Erfahrungen ORM mit Firebird

  Alt 3. Jul 2012, 13:51
und die 4/10 GB bei der Express-Version reichen für unsere Anwendungszwecke langfristig (10+ Jahre) nicht aus.
Was sind denn das für Daten welche 10 Jahre zurück(in der selben Datenbank) zur Verfügung stehen müssen?
Gibt es keine Möglichkeit diese in eine andere DB zu sichern bevor die 10GB Grenze erreicht ist?

Edit: Sorry - Hat eigentlich mit der Ursprungsfrage nichts zu tun.
Die obige Aussage repräsentiert meine persönliche Meinung.
Diese erhebt keinen Anspruch auf Objektivität oder Richtigkeit.
  Mit Zitat antworten Zitat
Morphie

Registriert seit: 27. Apr 2008
Ort: Rahden
610 Beiträge
 
#12

AW: Erfahrungen ORM mit Firebird

  Alt 3. Jul 2012, 14:17
Klar wäre das möglich...
Aber wozu, wenn es Datenbanken gibt, die das kostenlos ermöglichen?

Für mich fällt der SQL Server auf jedenfall weg.
Für kleinere / private Projekte ist er aber sicherlich gut... Dafür ist er ja schließlich auch vorgesehen

Die Datenbank steht fest (darüber haben wir hier oft und lange diskutiert), daher bitte zurück zum eigentlichen Thema.
  Mit Zitat antworten Zitat
Lemmy
Online

Registriert seit: 8. Jun 2002
Ort: Berglen
1.454 Beiträge
 
Delphi XE6 Professional
 
#13

AW: Erfahrungen ORM mit Firebird

  Alt 3. Jul 2012, 14:39
Hi,

erzähl doch erst mal warum du ein ORM einsetzen willst. Da du auf Firebird abfährst vermute ich, dass das Thema unterschiedliche DBs schon mal außen vor ist. Dann kann es durchaus sinnvoll sein, sich mit dem Thema "eigenes ORM" zu beschäftigen.

Ich kenne mich jetzt mit C# nicht wirklich gut aus, bin aber der Meinung, dass das schon einige Dinge mitbringt um ein eigenes kleines ORM in einem vertretbaren Zeitrahmen umzusetzen (De-/Serialisierung, Objekte an Oberfläche hängen,....). Habe so was mal mit Delphi gemacht, und würde nach dem Test verschiedener ORM (InstantObjects, tiOPF, NHibernate,...) im nächsten Projekt wo so was Sinn macht vermutlich wieder so beginnen. Zum einen ist die Einarbeitung in ein ORM nicht zu verachten, zudem kann es auch sein, dass die Philosophie eines Frameworks einfach nicht zur Aufgabenstellung passt. Zudem hast Du bei einem leichtgewichtigen eigenen ORM immer noch die Möglichkeit über einen Direktzugriff auf die DB gewisse kritische Funktionen entsprechend schnell auf der DB auszuführen.

Grüße
  Mit Zitat antworten Zitat
Morphie

Registriert seit: 27. Apr 2008
Ort: Rahden
610 Beiträge
 
#14

AW: Erfahrungen ORM mit Firebird

  Alt 3. Jul 2012, 15:06
erzähl doch erst mal warum du ein ORM einsetzen willst. Da du auf Firebird abfährst vermute ich, dass das Thema unterschiedliche DBs schon mal außen vor ist. Dann kann es durchaus sinnvoll sein, sich mit dem Thema "eigenes ORM" zu beschäftigen.
ADO.NET in Verbindung mit WPF lädt ja quasi dazu ein, die Daten irgendwie zu mappen und anschließend als Objekte weiterzuverwenden / an die Oberfläche zu binden.
Das Abfragen der Daten über LINQ empfinde ich auch als sehr angenehm...

So ein ORM nimmt mir halt viel Arbeit ab.
Die generierten Klassen haben schon alle die gewünschten Interfaces implementiert und sind für mich leicht zu erweitern.

Vorher habe ich viel mit reinem SQL (Command + DataReader) materialisiert. Das ging zwar richtig schnell und ich konnte die ganzen Features von Firebird benutzen, doch es war sehr aufwändig.

Mit DataSets konnte ich mich nie wirklich anfreunden.
Jetzt hat man schon mal so eine stark objektorientierte Programmiersprache, dann will man auch mit echten BusinessObjekten arbeiten...

Zum einen ist die Einarbeitung in ein ORM nicht zu verachten, zudem kann es auch sein, dass die Philosophie eines Frameworks einfach nicht zur Aufgabenstellung passt. Zudem hast Du bei einem leichtgewichtigen eigenen ORM immer noch die Möglichkeit über einen Direktzugriff auf die DB gewisse kritische Funktionen entsprechend schnell auf der DB auszuführen.
So denke ich auch...
  Mit Zitat antworten Zitat
Elvis

Registriert seit: 25. Nov 2005
Ort: München
1.893 Beiträge
 
Delphi 2010 Professional
 
#15

AW: Erfahrungen ORM mit Firebird

  Alt 3. Jul 2012, 17:55
Da gibt es dann einen "dirty"-Trick... Man muss in der Spaltendefinition in Firebird den Kommentar der Spalte mit den Text "#PK_GEN#" belegen, also quasi
Code:
COMMENT ON COLUMN ANSCHRIFTEN.ID
  IS '#PK_GEN#';
Das halte ich für eine unsaubere Umsetzung...
Naja, wenn du den Comment nicht nutzt, dann ist das einfach ein nachgeholtes Stück "Metadaten". Denn Firebird hat ja leider keine abfragbare Info darüber, dass ein Feld AutoInc'd wird.

Wenn der EF Provider sonst das tut was er soll, dann würde ich dir (gerade wenn ORMs-Neuland für dich sind) EF empfehlen.

NHibernate ist ungleich mächtiger, und man kann sich an praktisch allen Stellen selbst reinklinken und die Rädchen so einstellen, wie man es für sein Projekt haben will.
Allerdings muss man bei nHibernate wissen, wie man LINQ Queries schreiben muss, damit sie nicht zicken. (LINQ ist noch das große Manko von NHibernate)
Aber das ist alles für einen ORM-Einsteiger wohl etwas Overkill.

Fang also einfach mit EF an. Und wenn du den Comment brauchst, dann setz' ihn halt.
Stumpfsinniges Dogma kannst du dem Papst überlassen, das hat beim Programmieren nix zu suchen.


Kann denn Firebird mittlerweile vernünftig mit GUIDs umgehen? Wenn ja, dann gar nicht lange murksen und GUIDs anstatt Trigger und AutoInc nehmen.

btw: Kann der EF-Provider nicht die DB passend für deine Klassen erzeugen? Mich würde ein Comment in der DB nicht stören.
Die DB ist ja nur das Teil, was die Daten speichert. Genau dafür hast du ja den ORM. Wie das da aussieht ist fast egal. (Darf nur nicht uneffizient sein)
Denn wenn du nicht gegen eine exakte DB programmierst, sondern es dem ORM überlässt deine Klassen abzubilden, kannst du einfach auch mal postgres ausprobieren.
Robert Giesecke
I’m a great believer in “Occam’s Razor,” the principle which says:
“If you say something complicated, I’ll slit your throat.”

Geändert von Elvis ( 3. Jul 2012 um 18:01 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von Phoenix
Phoenix
(Moderator)

Registriert seit: 25. Jun 2002
Ort: Hausach
7.328 Beiträge
 
#16

AW: Erfahrungen ORM mit Firebird

  Alt 3. Jul 2012, 20:13
Ich persönlich habe noch nie einen ORM so schnell an seine Grenzen gebracht wie das EF (EF2, that is).
Das ging soweit, das für einen generischen Tabelleneditor mit zusammenklickbaren Views über die Entities das EF geschlagene 30 Minuten(!) an einem SQL Query berechnet hat (okay, es waren ne handvoll includes über Navigational Properties drin), und das Query hatte dann am Schluss joins über 256 Tabellennamen drin (waren in Summe aber nur 8-10 einzelne Tabellen, die standen halt zigmal drin), was der SQL Server dann konsequenterweise nicht mehr mitgemacht hat.

Eigentlich erwarte ich von einem OR-Mapper, dass er die Statements entsprechend optimiert, und vor allem nicht 30 Minuten rumrechnet.
Sebastian P.R. Gingter
不死鳥 Visit my Blog.
Do not argue with an idiot. They lower you to their level and then try to beat you with experience.
  Mit Zitat antworten Zitat
mjustin

Registriert seit: 14. Apr 2008
1.845 Beiträge
 
Delphi 2009 Professional
 
#17

AW: Erfahrungen ORM mit Firebird

  Alt 4. Jul 2012, 05:53
Auf Stackoverflow gibt es einige Beiträge zu diesem Thema:


http://stackoverflow.com/questions/2...et-application

* NHibernate und PostgreSQL als Kombination wird empfohlen
* von EF wird abgeraten wenn man es nicht zusammen mit MS SQL verwendet (allerdings ist der Beitrag aus 2008 also vor EF 2)

http://stackoverflow.com/questions/6...l-applications

* Dapper und PetaPoco werden als 'leichtgewichtige' Alternativen genannt

Vergleich EF und NHibernate:

* http://stackoverflow.com/a/5105917/80901
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 06:55 Uhr.
Powered by vBulletin® Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2014 by Daniel R. Wolf