Anbei ein Gerät, das ein typisiertes Dataset einlesen kann daraus eine zum Dataset passende Datenbank generieren.
Ich empfehle ja immer, eine Anwendung erstmal ohne Datenbank auszuprogrammieren, und erst wenn soweit featurecomplete, eine DB zu hinterlegen, um noch den "letzten Rest" zu implementieren, der ohne DB halt nicht machbar ist (wie Multi-User-Unterstützung oder gezielter Abruf von nur Teil-Daten).
Eine verfrühte DB-Integration vervielfacht die Komplexität der ganzen Entwicklung, und wenn ungeschickt angefangen, verbaut man sich u.U. auch noch alle Möglichkeiten von Databinding.
Aber wenn man dann am Punkt ist, wo die DB drangemacht wird, kann man hiermit zig Tabellen und hunderte von Spalten sich erstmal raushauen lassen - nacharbeiten, mit dem für die DB vorgesehenen Datenbank-Frontend kann man immer noch.
Oder auch, ums mal gesehen zu haben - für viele ists wohl ein ungutes Gefühl, sich fett in die Entwicklung zu stürzen, ohne die Frage des letztendlichen DB-Zugriffs auch nur grob geklärt zu wissen.
Jedenfalls das Proggi arbeitet bischen wie die Connectoren, die von verschiedenen DB-Anbietern bereitgestellt werden, nur in die annere Richtung: Also ein Connector generiert aus einer DB ein typDataset - DBGenerator aber generiert aus dem Dataset die DB :D.
Dabei unterstützt es vom Prinzip her alle .Net-tauglichen Datenbank-Systeme, also MySql, SqlServer, SqLite, SqlServerCe, Access, Oracle. Weil eine DB, von der man das Schema abrufen kann, an die kann man auch die
Begriffe: Ich werfe folgende Begriffe vermutlich unrichtiger weise durcheinander: Provider, Datenbank-System (DBS), Sql-Dialekt. Ich weiß nicht den Unterschied zw. DBS und Provider, jedenfalls scheinen diese 3 Begriffe 1:1 miteinander zusammenzuhängen: 1 Provider, 1 DBS, 1 Sql-Dialekt.
Paar Bildle
Beispiel-Generierung
Die rote Markierung zeigt ein Problem an - nämlich hier scheitert die Generierung, denn im Dataset wird offensichtlich eine Spalte mit Datentyp
DatabaseViewer
Damit kann man in der DB herumstöbern, zB was für Datentypen die hat, und auf welchen Framework-Datentyp die Mappen (Spalten #1 und #5). Aber auch alles mögliche annere kann man in Augenschein nehmen.
Provider-Settings
DbGenerator ruft vonne DB das Schema ab, und ordnet es einem Provider zu. Dann muss man einige Festlegungen treffen, die die Spezifika dieses Providers betreffen:
wichtiger Hinweis von @Arby:: Eigentlich ists nicht korrekt, den Providern spezifische Syntax zuzuordnen, denn man kann etwa mit dem OleDb-Provider ebensogut auch SqlServer abfragen. Und dann failt die Syntax, die dort eigentlich für Access hinterlegt ist.
Ich entscheide aber zunächst mal, es trotzdem dabei zu belassen, und empfehle, beim Einsatz vom DbGenerator halt die spezifischen DbProvider zu verwenden, also: SqlServer -> SqlClient, SQLite -> SQLite, MySql -> MySqlClient.
Wo lerne ich Sql-Syntax?
W3Schools: SQL Tutorial ist die beste Sql-Doku, die mir bekannt ist's - damit kann man sich auf jeden Fall erfolgreich durchkämpfen.
W3Schools wird betrieben vom W3-Konsortium, also was renomierteres gibts einfach nicht, wage ich zu behaupten.
Zum Abschluss
Fast wie ein "Mini-Universal-Datenbank-Management-System": Man kann egal für welche Datenbank sein relationales Datenmodell grafisch unterstützt im Dataset-Designer des VisualStudio gestalten (und sogar schon voll funktionsfähige Anwendungen damit entwickeln) - bei Bedarf haut DbGenerator die Datenbank dazu raus
Leider musste ich feststellen, dass SqLite zumindest auf meinem System nur bis Framework-Version FW3.5 unterstützt wird. Ich habe zwar eine neuere Dll auch eingebunden, aber da zickt VisualStudio rum.
Vielleicht hätte ich auch nur was installieren müssen - da hab ich aber keine Lust zu.
Dafür hat sich SqlCe verbessert: Die 3.5-Version hat noch kein Schema bereitgestellt, aber Version 4.0 läuft wunderbar - siehe mein Video.
letzte Links
Mir fällt auf, dass ich hier pausenlos von typisiertem Dataset rede, aber möglicherweise ist vielen gar nicht bekannt, wie in .Net Datenbanken, typisiertes Dataset und databinding-getriebene Oberflächen-Entwicklung miteinander verzahnt sind:
Also vier Views-Videos und weiterführende Links geben glaub eine umfassende Einführung in diese Programmier-Welt, DBExtensions handeln die Daten-Zugriffs-Schicht ein für allemal ab, jedenfalls in ziemlich großem Umfang.
Das Video
Zeigt (etwas hastig), wie man eine Dataset-Only-Anwendung in 10 Minuten in eine SqlCe-DB-Anwendung migriert.
Inklusive der Anpassung eines Char-Mappings für den SqlCe-Provider, sowie Transfer der Daten aus der Xml-Datei in die DB.
2 kl. Korrekturen zum Film
Lizenz: Beerware
Ich empfehle ja immer, eine Anwendung erstmal ohne Datenbank auszuprogrammieren, und erst wenn soweit featurecomplete, eine DB zu hinterlegen, um noch den "letzten Rest" zu implementieren, der ohne DB halt nicht machbar ist (wie Multi-User-Unterstützung oder gezielter Abruf von nur Teil-Daten).
Eine verfrühte DB-Integration vervielfacht die Komplexität der ganzen Entwicklung, und wenn ungeschickt angefangen, verbaut man sich u.U. auch noch alle Möglichkeiten von Databinding.
Aber wenn man dann am Punkt ist, wo die DB drangemacht wird, kann man hiermit zig Tabellen und hunderte von Spalten sich erstmal raushauen lassen - nacharbeiten, mit dem für die DB vorgesehenen Datenbank-Frontend kann man immer noch.
Oder auch, ums mal gesehen zu haben - für viele ists wohl ein ungutes Gefühl, sich fett in die Entwicklung zu stürzen, ohne die Frage des letztendlichen DB-Zugriffs auch nur grob geklärt zu wissen.
Jedenfalls das Proggi arbeitet bischen wie die Connectoren, die von verschiedenen DB-Anbietern bereitgestellt werden, nur in die annere Richtung: Also ein Connector generiert aus einer DB ein typDataset - DBGenerator aber generiert aus dem Dataset die DB :D.
Dabei unterstützt es vom Prinzip her alle .Net-tauglichen Datenbank-Systeme, also MySql, SqlServer, SqLite, SqlServerCe, Access, Oracle. Weil eine DB, von der man das Schema abrufen kann, an die kann man auch die
CREATE TABLE - Commands in geeigneter Weise schicken, dass das Ding hinterher mit dem Dataset zusammenpasst.Begriffe: Ich werfe folgende Begriffe vermutlich unrichtiger weise durcheinander: Provider, Datenbank-System (DBS), Sql-Dialekt. Ich weiß nicht den Unterschied zw. DBS und Provider, jedenfalls scheinen diese 3 Begriffe 1:1 miteinander zusammenzuhängen: 1 Provider, 1 DBS, 1 Sql-Dialekt.
Paar Bildle
Beispiel-Generierung
Die rote Markierung zeigt ein Problem an - nämlich hier scheitert die Generierung, denn im Dataset wird offensichtlich eine Spalte mit Datentyp
Char verwendet, wofür im Schema des SqlCe-DBS kein Mapping angegeben ist. Im Video wird gezeigt, wie man das ausbessert, indem man einfach ein benutzerdefiniertes Mapping hinzufügt.DatabaseViewer
Damit kann man in der DB herumstöbern, zB was für Datentypen die hat, und auf welchen Framework-Datentyp die Mappen (Spalten #1 und #5). Aber auch alles mögliche annere kann man in Augenschein nehmen.
Provider-Settings
DbGenerator ruft vonne DB das Schema ab, und ordnet es einem Provider zu. Dann muss man einige Festlegungen treffen, die die Spezifika dieses Providers betreffen:
- FileExtension: Bei dateibasierten Providern ordnet DbGenerator anhand dieser Angabe den Provider zu (war zu faul, das per Registry zu machen)
- Quotes: verschiedene Sql-Dialekte haben verschiedene Quote-Identifier, also Zeichen, mit denen DB-Objekte wie Tabellen und Spalten eindeutig als DB-Objekte gekennzeichnet werden, um Verwechslungen mit Schlüsselworten auszuschließen, zB:
[Update] <> Update- das linke wäre ein SqlCe-DB-Objekt, das rechte ist ein Schlüsselwort.
- AutoIncrement: Jeder Dialekt hat eine eigene Syntax, um Auto-Increment-Spalten zu definieren. Bei manchen - wie Access - ist Counter ein eigener Datentyp, bei anderen, wie SqlCe kann man einen geeigneten Datentyp angeben (meist int oder BigInt), und qualifizieren mit "Identity" und sogar noch 2 Parametern für Startwert und Schrittweite. In meiner Eingabe dafür stellt '?' einen Platzhalter für den Datentyp dar, der dann aus der AutoIncrement-Spalte des zu migrierenden Datasets ausgelesen wird.
- ConnectionPattern: DbGenerator speichert hier eine Vorgabe für dateibasierte DBS, sodass er, wenn eine Datei eingegeben wird, den ConnectionString sich selbst ausdenken kann. Hierbei ist '?' der Platzhalter, an dem DbGenerator den übergebenen Dateipfad einsetzt.
Im einzelnen Migrations-Projekt (s. Abb. "PersonBerufProject.Png", Grid#1) kann der Connectionstring immer noch individuell geändert werden - der Connection-Pattern ist nur die Voreinstellung.
- Mappings: Hier sind die vom DBS unterstützten Datentypen gelistet, gruppiert nach den .Net-Datentypen, die man darauf mappen kann. Kann ein .Net-Typ auf mehrere DbTypen mappen, so wird beim autom. Generieren das "Preferred" Mapping vorgezogen - ist aber im konkreten Projekt auch individuell änderbar.
Wie man sieht, erfordern einige DbTypen die Angabe von Parametern - auch hier kann man die Voreinstellungen anpassen.
Insgesamt sind im Mapping-View editierbare Felder hellblau gekennzeichnet.
wichtiger Hinweis von @Arby:: Eigentlich ists nicht korrekt, den Providern spezifische Syntax zuzuordnen, denn man kann etwa mit dem OleDb-Provider ebensogut auch SqlServer abfragen. Und dann failt die Syntax, die dort eigentlich für Access hinterlegt ist.
Ich entscheide aber zunächst mal, es trotzdem dabei zu belassen, und empfehle, beim Einsatz vom DbGenerator halt die spezifischen DbProvider zu verwenden, also: SqlServer -> SqlClient, SQLite -> SQLite, MySql -> MySqlClient.
Wo lerne ich Sql-Syntax?
W3Schools: SQL Tutorial ist die beste Sql-Doku, die mir bekannt ist's - damit kann man sich auf jeden Fall erfolgreich durchkämpfen.
W3Schools wird betrieben vom W3-Konsortium, also was renomierteres gibts einfach nicht, wage ich zu behaupten.
Zum Abschluss
Fast wie ein "Mini-Universal-Datenbank-Management-System": Man kann egal für welche Datenbank sein relationales Datenmodell grafisch unterstützt im Dataset-Designer des VisualStudio gestalten (und sogar schon voll funktionsfähige Anwendungen damit entwickeln) - bei Bedarf haut DbGenerator die Datenbank dazu raus
Leider musste ich feststellen, dass SqLite zumindest auf meinem System nur bis Framework-Version FW3.5 unterstützt wird. Ich habe zwar eine neuere Dll auch eingebunden, aber da zickt VisualStudio rum.
Vielleicht hätte ich auch nur was installieren müssen - da hab ich aber keine Lust zu.
Dafür hat sich SqlCe verbessert: Die 3.5-Version hat noch kein Schema bereitgestellt, aber Version 4.0 läuft wunderbar - siehe mein Video.
letzte Links
Mir fällt auf, dass ich hier pausenlos von typisiertem Dataset rede, aber möglicherweise ist vielen gar nicht bekannt, wie in .Net Datenbanken, typisiertes Dataset und databinding-getriebene Oberflächen-Entwicklung miteinander verzahnt sind:
Also vier Views-Videos und weiterführende Links geben glaub eine umfassende Einführung in diese Programmier-Welt, DBExtensions handeln die Daten-Zugriffs-Schicht ein für allemal ab, jedenfalls in ziemlich großem Umfang.
Das Video
Zeigt (etwas hastig), wie man eine Dataset-Only-Anwendung in 10 Minuten in eine SqlCe-DB-Anwendung migriert.
Inklusive der Anpassung eines Char-Mappings für den SqlCe-Provider, sowie Transfer der Daten aus der Xml-Datei in die DB.
2 kl. Korrekturen zum Film
- Im Film erzähle ich, das DB-Schema sei Grundlage für die DB-Extensions. Ist natürlich Quark - richtig ist, dass das DB-Schema Grundlage des DbGenerators ist - nicht der DbExtensions
- Im Film erkläre ich den 'n'-Prefix des
nchar()-Db-Datentyps falsch, und das richtige ist eiglich recht interessant:
Bei Sql-Datentypen sind 2 Prefixe üblich, nämlich 'n' und 'var'.- 'n' wird auf Chars angewendet, und heißt "national", und meint einen unicode-Char-Typ, also einen mit doppelter Breite, der daher jegliche Sonderzeichen und Kram fassen kann - mit
nchar()ist man also auf der sicheren Seite - 'var' bedeutet "variable Länge". char(50) ist also immer 50 Zeichen breit, varchar(50) ist maximal 50 Zeichen breit.
Die betreffenden Datentypen heissen:char(), varchar(), nchar(), nvarchar(), byte(), varbyte()
- 'n' wird auf Chars angewendet, und heißt "national", und meint einen unicode-Char-Typ, also einen mit doppelter Breite, der daher jegliche Sonderzeichen und Kram fassen kann - mit
Lizenz: Beerware
