Erfahrungen ORM mit Firebird

[Morphie]

Hi,

wir wollen bald mit einem Projekt unter C# starten und würden dafür gerne Firebird als Datenbank verwenden.
Was habt ihr so für Erfahrungen mit den verfügbaren Mappern in Verbindung mit Firebird?

Beim Entity Framework gibt es drei Sachen, die mich stören:

1. dass das EF (bzw. der Firebird Provider dafür) die Felder, die ihren Wert über einen Generator + Trigger erhalten, nicht automatisch als solche "Autowert"-Felder erkannt werden.
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...

2. habe ich noch nicht herausgefunden, wie ich dem EF sagen kann, dass ein Feld über einen Autowert gefüllt wird, solange es keinen Inhalt hat.
Ich habe also einen Trigger auf dem Feld, welches auf NULL prüft. Wenn das Feld also NULL ist, wird ein berechneter Wert in das Feld eingetragen. Wenn nicht, bleibt mein vorgegebener Wert eingetragen.
Ich habe im EF aber nur die Möglichkeit zu sagen, dass ein Feld von der Datenbank berechnet wird. Dann kann ich aber überhaupt keinen Wert vorgeben. Oder sich sage, dass es nicht berechnet wird. Dann erhalte ich aber nicht den berechneten Wert zurück. (Kein Returning im generierten SQL-Statement)

3. Es ist unglaublich langsam bei Batch-Inserts... Jeder Datensatz wird einzeln mit einem eigenen "EXECUTE BLOCK"-SQL-Statement übetragen!



Und beim Telerik OpenAccess ORM hagelt es bei mir nur Fehlermeldungen, wenn ich Daten anfügen will. (Abfragen klappen komischerweise)


Ich habe mir auch schon überlegt, ob es vielleicht Sinn machen würde, sich selbst einen ORM zu schreiben, der quasi genau für Firebird und meinen Anforderungen aufgebaut ist... Was meint ihr?

Was nutzt ihr denn so?

[mjustin]

Ist NHibernate schon bei der Vorauswahl des ORM ausgeschieden? Es hat im Java Umfeld große Verbreitung, ich weiss nicht wie gut der .NET Port ist.

Daneben würde ich als Vergleich zu Firebird noch eine andere, möglichst verbreitete Datenbank wie zum Beispiel PostgreSQL testen.

[Morphie]

NHibernate habe ich noch nicht getestet... Werde ich aber nachholen
Hat dazu vielleicht schon jemand Erfahrungen in Verbindung mit FB?

Eigentlich bin ich mit Firebird sehr zufrieden...
Viele Features, leichte Installation, Embedded Support, erweiterbar, schnell und stabil... Nur weil es "keinen guten" ORM für Firebird gibt, würde ich ungern auf Firebird verzichten. Da schreibe ich mir den ORM dann doch lieber selbst und habe zudem auch noch volle Kontrolle über meinen Code...

[Iwo Asnet]

Zitat von Morphie:

Da schreibe ich mir den ORM dann doch lieber selbst und habe zudem auch noch volle Kontrolle über meinen Code...

Ein Paradigmen-Wechsel(hier: zu einer anderen DB) geht schneller.

PostGreSQL ist schon sehr anständig, aber wenn schon .NET, wieso dann nicht MSSQL? Das passt schließlich wie Faust auf Auge und C#/VS bringt alles mit, was man so braucht, um sich um ORM nicht mehr zu kümmern...

Oder bist Du ein 'Microsofthasser'?

[Morphie]

Nö... habe ich auch schon mal getestet...
Soll aber kostenlos sein und die 4/10 GB bei der Express-Version reichen für unsere Anwendungszwecke langfristig (10+ Jahre) nicht aus.
Wäre ich ein "Microsofthasser" wäre ich bei Delphi geblieben

[Iwo Asnet]

Dann nimm PostGres bzw. ziehe es in Erwägung. Wir verwenden das auch mit .NET und großen DBs.
Mit ORM habe ich aber keine Erfahrungen, obwohl der Programmierer schon einen Workshop mit NHibernate gemacht hat. Und ich denke, Du wärst nicht der Einzige, der PostGes mit NHibernate verwendet.

[taveuni]

Zitat von Morphie:

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.

[Elvis]

Zitat von Morphie:

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.

[Phoenix]

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.

[mjustin]

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