Best Practice: Import von XML => SQL-DB und Ändern

[Furtbichler]

Hi,

Ich überlege gerade, was mit C# und .NET 4.5 (VS 2012) am Besten ist.

Ich habe (ziemlich kranke) XML-Dateien mit einem merkwürdig komplexen XSD-Schema, die ich in eine SQL-DB (SQL-Server) importieren will.
Das DB-Schema unterscheidet sich vom XSD, weil auch andere Datenformate in die Datenbank rein sollen und -wie erwähnt- das Schema von einem Selbstkasteier entwickelt wurde.

Ich hab eigentlich 0 Ahnung von den Spezifika von C# bezüglich Datenbanken und so, deshalb ist es vermutlich eine peinliche Frage ;-)

So. Wie sollte man das am besten machen?
1. Soll ich ein Dataset nehmen, und die XML-Datei (können echt groß werden) da rein schreiben und dann das Dataset per Update die ganzen Daten abspeichern lassen? Das hätte den Vorteil, das ich mit dem Dataset später die manuellen Änderungsmöglichkeiten einfach umsetzen könnte. Glaube ich.

2. Soll ich mit dem Dataset gar nicht arbeiten? Das erinnert mich nämlich ein wenig an ein TDataModule und die Crux mit datensensitiven Steuerelementen. Außerdem habe ich den Verdacht, das so ein Dataset ziemlich viel Speicher verbrät. Ich würde mir dann also einen Database-Writer für die XML-Daten schreiben, der handgebissene SQL-Befehler absetzt.

3. Oder mit einem Objektpersistenz-Framework arbeiten (was ich noch nicht habe)?

Kann mir wer einen Kick in die richtige Richtung geben? Wäre Klasse.

[Phoenix]

Zitat:

Zitat von Furtbichler (Beitrag 1185689)

Außerdem habe ich den Verdacht, das so ein Dataset ziemlich viel Speicher verbrät.

Aber sowas von :) Es gibt nicht viele Dinge, die mehr Speicher brauchen als ein Dataset.

An OR-Mappern hättest Du im .NET Framework natürlich gleich das Entity Framework drin. In 4.5 ist dann auch eine einigermassen taugliche Version davon enthalten (ich schlage mich hier noch mit EF 1 rum - das macht schneller die Grätsche als einem Lieb sein könnte). Ansonsten gibts als OpenSource natürlich noch nHibernate (wäre meine zweite Wahl).

Beide haben natürlich eine gewisse Lernkurve, aber zu EF gibts mehr Sachen im Netz zu finden.

Ich würde dann empfehlen, mit einem XmlReader durch das XML zu jagen und damit dann den Objektgraphen fürs EF (oder NH) aufzubauen. Danach das ganze an den jeweiligen Kontext attachen, persistieren und gut ist.

[jobo]

Wieso ist die Schema Datei so komplex? Sind es haufenweise Contraints oder eher Relationen?

Ich hab's selbst noch nicht benutzt und es passt nicht richtig zu Deiner Frage, aber vielleicht findest Du das interessant für Deine Zwecke:
http://www.microsoft.com/en-us/downl...24659#overview

[Furtbichler]

Hi Phoenix, jobo.

Danke für die Tipps. Ich werde mir mal das EF anschauen.

Wenn Dataset schon so ein Mumpitz ist, kann man wenigstens mit LinQ-SQL was anfangen?

@jobo: Die Schemadateien sind deswegen so komplex, weil es in Abhängigkeit einzelner Werte bestimmte Pflichtfelder gibt.

Ich verwende derzeit xsd.exe, um mir die Klassen zu basteln. Mal sehen, wie weit ich größentechnisch damit komme. Im Endeffekt gehe ich die XML-Datei ja eh sequentiell durch, also kann ich die eine Stelle auch später noch ändern

[Phoenix]

Zitat:

Zitat von Furtbichler (Beitrag 1185764)

Wenn Dataset schon so ein Mumpitz ist, kann man wenigstens mit LinQ-SQL was anfangen?

Linq2Sql ist im Prinzip eine sehr leichtgewichtige Ausgabe / 'Schmalspur-Version' des EF. Bzw. eigentlich war es die Ursprungsversion. EF ist ein früher Spin-Off von L2S und wurde dann in richtung multiple-DB weiterentwickelt. L2S ist dann irgendwann stehen geblieben: Es hat weniger Features, aber nicht viel weniger Overhead. Und am wichtigsten: es wird nicht mehr weiterentwickelt (weil EF eben flexibler ist, und es einen sehr einfachen Upgradepfad von L2S zu EF gibt.

Von daher lohnt es sich eigentlich nicht, heute noch mit L2S zu beginnen.

[Furtbichler]

Update: Mit EF habe ich das hinbekommen, ist ja auch nicht schwer. Mittlerweile habe ich DevExpress und deren XPO-Framework. Das sieht auch vielversprechend aus. Die Hauptschwächer aller ORM, nämlich keine Massenupdates machen zu können (geht natürlich, aber nur mit direktem SQL), haben die auch.

[Sir Rufo]

Zitat:

Zitat von Furtbichler (Beitrag 1194966)

Update: Mit EF habe ich das hinbekommen, ist ja auch nicht schwer. Mittlerweile habe ich DevExpress und deren XPO-Framework. Das sieht auch vielversprechend aus. Die Hauptschwächer aller ORM, nämlich keine Massenupdates machen zu können (geht natürlich, aber nur mit direktem SQL), haben die auch.

Wenn du den Programmierern erklärst, was Massenupdates mit einem ORM zu tun haben, dann würden die das auch umsetzen.

Sowas gehört in einen Service, der auf dem Server diese Aktion durchführt.
Um das also in die SQL Welt zu übersetzen analog einer Stored Procedure.

[Furtbichler]

Es ist nur oversized, dafür extra einen Service einzurichten. Und eine Stored Procedure mit einer Liste von IDs zu füttern ist auch nicht gerade prickelnd. Aber vom Architekturstandpunkt aus hast Du natürlich Recht.

Damit wir uns nicht falsch verstehen: Mit 'Massenupdates' (sollte es besser: Mengenupdates heißen?) meine ich Konstrukte wie:

Code:

update Tabelle 
   set Foo=123 
where ID In (1,2,3,4,5) -- 1,2,3,4,5 sind vom Anwender ausgewählte Daten

update Tabelle
   set Feld = EinAndererWert
  from AndereTabelle
 where AndereTabelle.Irgendwas = Tabelle.Irgendwas -- Das geht natürlich per SP

[Elvis]

Offtopic, aber was soll's:
NHibernate erlaubt Updates/Deletes in HQL, also gegen deine Mappings, nicht direkt gegen die DB-Struktur.
Wennu gerne alle Hans' mit Nachnamen Meyer oder Schulz umbenennen willst ginge das so:

Code:

class Trööt
{
   public virtual string FirstName{get;set;}
   public virtual string LastName{get;set;}
}

Code:

session.CreateQuery("update Trööt set FirstName = 'Egon' where FirstName = 'Hans' and LastName in (:s, :m)")
       .SetParameter("s", "Schulz")
       .SetParameter("m", "Meyer")
       .ExecuteUpdate();

Bei RDBMS', die Batches verstehen, wird es auch sehr viele Objekt-Änderungen in einem Rountrip abschicken können.
Hassu also lauter neue geänderte Objekte, die du wieder zurückschreibst, ist die Anzahl der Calls zur DB nur durch die max. Zahl von Parametern beschränkt (IMO 2000 für MSSQL).
Bei Oracle wird dann Array/Bulk DML benutzt, was *brutal* schnell ist.


Zum Thema:
Das ist mir hier irgendwo unterm Radar durchgeflogen...
Wenn dich dazu (auch wenn's vllt zu spät ist) mehr Details interessieren, könntest du vllt irgendein Beispiel aus den Fingern saugen.
Und ich könnte dir zeigen, wie man das mit XLinq, XSD, und dem ORM deiner Wahl löst.