Hallo,

ich versuche gerade einen Tabellennamen aus einer Query herauszulesen, doch erweist es sich - wenn´s zuverlässig sein soll - als nicht ganz einfach.
Beispiel:
Was hier so ganz offensichtlich ist, ist im Programm, auch bei beliebig komplexen Queries, nicht so einfach zu finden.

Kennt ihr eine zuverlässige Möglichkeit das herauszufinden?

Welche Datenbank nutzt du?

für SQL & Oracle:
itknowledgeexchange.techtarget…et-all-tablenames-by-sql/

Access:
bigresource.com/VB-getting-tab…using-SQL-bOmfvzF3Ww.html

lg

Hi!

ADO.Net ist so konzipiert, dass man i.a. kein kompliziertes SQL schreiben muß/sollte. Anstatt mehrere Tabellen per SQL zusammenzurühren (und dann den Salat nicht mehr abspeichern zu können), lädt man von den verschiedenen Tabellen die Datensätze, die man braucht, nämlich in verschiedene DataTables des typisierten Datasets.
Erst im Client erstellt man den View, also man setzt die Daten in der Form zusammen, wie man sie braucht

• Das ist weniger Traffic, denn zB eine gejointe Tabelle enthält zusätzliche Spalten (mit hochredundanten Daten - nämlich Werten aus der übergeordneten Tabelle).
  
• Man kann aus den Daten derselben Query verschiedene Views bauen, ohne erneut abfragen zu müssen. Gugge die Vorstellung verschiedener Views auf Movie-Tuts
  
• Man kann alle Änderungen problemlos zurückspeichern
  
• Aus einem Command mit einem einfachem SELECT-Statement kann der CommandBuilder die erforderlichen UPDATE/INSERT/DELETE - Commands selbst ableiten
  

Aber warum meinst du denn, dein (mir unverständliches) Sql analysieren zu müssen? (wie gesagt, das ist normalerweise der Job des CommandBuilders)

@ ErfinderDesRades

OT: Einwand gegen Deine Aussage an sich (nicht auf die Problemstellung bezogen). Das was Du beschreibst, kannste machen für Kleinst-Datenbanken die lokal liegen. Aber bereits bei einer mittleren DB die auch noch auf einem Server liegt knickste mit der Vorgehensweise komplett ein.

Hier ist es fast immer sinnvoller in der DB die View zu erzeugen und sich nur die View auf den Client zu holen (eben nur die benötigten DS und nicht alle). Allerdings ist im Grundprinzip eine View auch nix was man direkt bearbeitet, sondern genau das was es heisst: Eine Sicht auf Daten. Um Daten zu bearbeiten verwendet man eher seltener Views sondern mehr den direkten Zugriff auf das/die Table/s (komplexere Views können ja aus den Daten von x0 Tables zusammen gesetzt sein). Aber auch hier ist es bei größeren DB's sinnvoller sich nur den/die zu bearbeitenden DS zu holen anstatt erstmal das komplette Table zu holen ... x00.000 DS pro Table sind ja normale Größenordnungen. Das würde die Ressourcen und Trafic an die Grenzen bringen und zu Verarbeitungszeiten führen die jenseits von Gut und Böse sind.

@ peter-70

Ich verstehe Dein Problem nicht wirklich. Ich arbeite ja schon länger mit Datenbanken aber mir ist es noch nie passiert das ich gezwungen gewesen wäre aus einer View Table-Names auszulesen.

Könntest Du mal genau beschreiben was Du vor hast? Ich vermute nämlich das Du hier in dem Prinzip Deiner Vorgehensweise möglicherweise falsch denkst.

Gruß

Rainer

Ein Entwicklertool.

Der Entwickler gibt eine DB-Quelle ein, z.B. Tabellen- oder Viewnamen, oder eben ein SELECT-Statement ein.
Daraus wird dann eine XSD-Datei für Word generiert; jedoch läuft das als ein PLSQL-Script auf dem Server.

Die Funtkion, die das XSD generiert, erwartet einen Tabellen, oder Viewnamen.
Wenn der Entwickler aber einen SELECT angibt, dann muss ich herausfinden

A - ist nur eine Datenquelle angegeben worden? Falls ja welchen (Name der Tabelle, oder View)
B - Falls es ein JOIN ist, eine temporäre View anlegen und den TEMP-Namen an das Script übergeben.

raist10 schrieb:

Aber bereits bei einer mittleren DB die auch noch auf einem Server liegt knickste mit der Vorgehensweise komplett ein.

Wieso sollte da was einknicken?
Das von mir genannte Prinzip funzt ebensogut, wenn man nur die Teile der Tabellen lädt, die man braucht.

@ peter-70

Ahja ... na dann viel Spaß.

Kann ich Dir echt nicht mehr weiterhelfen weil ich da keinen Plan habe wie Du ran kommen könntest rein aus den Angaben aus dem SQL-Statement. Da gibt es ja unendlich viele Variations-Möglichkeiten an welchen Stellen und in welcher Form Tables und Views angesprochen werden könnten ... z.B. Thema Sub-Statements oder kombinierte Statements die sich auf Tabelle und View beziehen.

@ ErfinderDesRades

Und was haste damit gewonnen?

Du musst das was in der DB mit einem SQL-Statement erledigt wird, dann in VS in x-Statements zerlegen um die passenden Daten aus den Tables zu holen, und dann wieder über das ursprüngliche Statement zu einem View zusammen fassen das dann aus allen geholten DS die letztendlich anzuzeigenden DS filtert. Das ist im Vergleich dazu ein View aus einer DB auszulesen ein riesen Akt und im Regelfall hast Du trotzdem deutlich mehr DS transportiert als Du letztendlich brauchst.

Wie gesagt, für kleinere DB's und bei kleineren Statements sicherlich machbar, aber nimm mal eine View die sich über 5 bis 10 Tabellen erstreckt und ein SQL-Statement mit 200 und mehr Zeilen hat ... und das ist ja jetzt noch nichts wirklich Großes. Da progst Du Dir mit der Vorgehensweise aber sowas von einen Wolf und von dem Handling das Statement erstmal zu zerlegen um nur mal an die grobe Informationen zu kommen welche DS Du nun wirklich aus den Tables brauchst und welche nicht, will ich erst gar nicht reden. Sehr oft ergibt sich ja auch erst aus der Berechnung von mehrere Feldern die in unterschiedlichen Tables liegen ob der DS gebraucht wird oder nicht.

Sowas hast Du mit einer View aus der DB mit einer einzigen Anweisung erledigt im Programm-Code.

Es ergibt sich ja auch bei der Vorgehensweise kein einziger Vorteil, sondern nur Nachteile ... langsamer, extrem viel mehr Programmieraufwand, mehr Traffic/gesamt höhere Ressourcenbelastung und Du rennst damit auch schon bei mittleren Geschichten sehr leicht in das Limit des DataSet-Designers (welches nach User-Meldungen bei rund 700 Fields/2100 Parameters liegen soll und das hat man aber selbst schon bei einer kleineren mittleren DB problemlos gesprengt).

Gruß

Rainer

raist10 schrieb:

Und was haste damit gewonnen?

Habichdoch bereits gesagt:

ErfinderDesRades schrieb:

• Das ist weniger Traffic, denn zB eine gejointe Tabelle enthält zusätzliche Spalten (mit hochredundanten Daten - nämlich Werten aus der übergeordneten Tabelle).
  
• Man kann aus den Daten derselben Query verschiedene Views bauen, ohne erneut abfragen zu müssen.
  
• Man kann alle Änderungen problemlos zurückspeichern
  
• Aus einem Command mit einem einfachem SELECT-Statement kann der CommandBuilder die erforderlichen UPDATE/INSERT/DELETE - Commands selbst ableiten
  

raist10 schrieb:

Du musst das was in der DB mit einem SQL-Statement erledigt wird, dann in VS in x-Statements zerlegen um die passenden Daten aus den Tables zu holen, und dann wieder über das ursprüngliche Statement zu einem View zusammen fassen das dann aus allen geholten DS die letztendlich anzuzeigenden DS filtert. Das ist im Vergleich dazu ein View aus einer DB auszulesen ein riesen Akt und im Regelfall hast Du trotzdem deutlich mehr DS transportiert als Du letztendlich brauchst.

Das ist für mich eine komische Denkweise.
Das "ursprüngliche Statement" gibts gar nicht. Ich hab einen Haufen von Datensätzen in verschiedenen Tabellen, die über Properties mittnander verbunden sind, also die Kategorie eines Artikels rufe ich mit ab, und annersrum kriege ich alle Artikel einer Kategorie mit - so ist alles verfügbar ohne "ursprüngliches Statement".

raist10 schrieb:

Wie gesagt, für kleinere DB's und bei kleineren Statements sicherlich machbar, aber nimm mal eine View die sich über 5 bis 10 Tabellen erstreckt und ein SQL-Statement mit 200 und mehr Zeilen hat ... und das ist ja jetzt noch nichts wirklich Großes.

@Peter - was sagst du dazu: Ein Sql-Statement mit 200 Zeilen - ist das was Großes, oder wirklich nicht? ;)

raist10 schrieb:

Da progst Du Dir mit der Vorgehensweise aber sowas von einen Wolf und von dem Handling das Statement erstmal zu zerlegen um nur mal an die grobe Informationen zu kommen welche DS Du nun wirklich aus den Tables brauchst und welche nicht, will ich erst gar nicht reden.

Ist vlt. schon angeklungen: Mit so "Kleinigkeiten" wie 200zeiligen Sql-Statements hatte ich bisher nix zu schaffen. Ansonsten habich inzwischen recht listigen Code, bei dem ich eine DataRow angeben muß, und die damit zusammenhängenden DataTables, und er bastelt mir die Sql-Statements dazu.
Ich weiß nicht, was mehr Wolf ist: 200 Zeilen Sql zu schreiben, oder mein Tabellen-Joiner-Dings zu benutzen (na, wennichhiermannich Äpfel und Birnen vergleiche, aber Rethorik rules ;)).
Jedenfalls zu so Sql: Gibts da eiglich iwie mehr Unterstützung, sowas zu coden? Mir kommen diese String - Statements überaus unzeitgemäß vor - also im VS habich Intellisense, Typ-Überprüfung, kann durchsteppen, hab Refaktorierung etc., aber wennich Sql schreibe kommichmir auf einmal wieder vor wie beim C proggen auffm Atari anno 1986: Da schrieb man egal was in den Editor, und hat alles mit Testläufen durchnudeln müssen - es gab nur total kryptische Compiler-Meldungen, und ansonsten Laufzeitfehler.

raist10 schrieb:

Es ergibt sich ja auch bei der Vorgehensweise kein einziger Vorteil, sondern nur Nachteile ... langsamer, extrem viel mehr Programmieraufwand, mehr Traffic/gesamt höhere Ressourcenbelastung

hmm - wie gesagt: Es ist schneller, schont Resourcen, minimiert den Umgang mit untypisierten Objekten, und man kann es rückspeichern

raist10 schrieb:

und Du rennst damit auch schon bei mittleren Geschichten sehr leicht in das Limit des DataSet-Designers (welches nach User-Meldungen bei rund 700 Fields/2100 Parameters liegen soll und das hat man aber selbst schon bei einer kleineren mittleren DB problemlos gesprengt).

Naja - was du dir unter einer "kleineren mittleren DB" vorstellst, kann ich inzwischen ja so ungefähr erahnen
Die Grenze mit den 700 Fields - soll das bedeuten, Dataset wäre bei 10 Tabellen a 7 Spalten am Ende? Das wäre glaub definitiv eine Falschinformation.

Edit: Fällt mir grad ein, du "schuldest" mir noch deine Version einer MiniKass-Anwendung
Täte mich zum einen interessieren, wie du das mit dem Mappen vom DataReader auf ordentliche .Net-Typen regelst, und zum andern, ob du auch so hübsche Comboboxen ins DatagridView machen kannst, mit denen man einstellt, dasses eben der Artikel "Cola" war, von dem 5 Einheiten gekauft wurden.
Weil wenn man solche Views als flache Tabelle abruft, sehe ich nicht, wie sone ComboColumn realisierbar ist.

ErfinderDesRades schrieb:

Das ist für mich eine komische Denkweise.
Das "ursprüngliche Statement" gibts gar nicht. Ich hab einen Haufen von Datensätzen in verschiedenen Tabellen, die über Properties mittnander verbunden sind, also die Kategorie eines Artikels rufe ich mit

...

ab, und annersrum kriege ich alle Artikel einer Kategorie mit

...

- so ist alles verfügbar ohne "ursprüngliches Statement".

Moment ... bitte ich rede auch eigentlich nicht über billigst Abfragen wie "Alle Artikel einer Kategorie". Das das bei Kleinst-DB's wo die Verwaltung mit einfachen SQL-Statements läuft kein Thema ist, habe ich ja schon gesagt.

Aber selbst hier musst Du ja zuerst wissen welche Daten der User aufruft um Sie aus der DB zu laden, eben das "Ursprungs-Statement" (woher sollst Du sonst wissen was der user gerade aufrufen will?). War ja Dein Argument bezügl. Traffic: Du lädst nur die Daten aus der DB die der User braucht. Lädst Du erst das komplette Table und sortierst dann nach Kategorie dann hast Du einen fetzen Traffic und Deine Anwendung knickt Dir irgendwann ein.

Stell Dir einfach nur mal die Artikelverwaltung bei Amazon vor und Du lädst nun über den Server das komplette Table mit den Artikeldaten um dann in Deinem Programm nur die Artikel der Kategorie XYZ anzuzeigen. Weisst Du was da Traffic über die Leitung jagt?

@Peter - was sagst du dazu: Ein Sql-Statement mit 200 Zeilen - ist das was Großes, oder wirklich nicht?

Was ist daran groß? o_O

Du hast doch die Bilder von meinem Universal-DataGrid gesehen, da stecken teilweise Views dahinter die 300 und mehr Statement-Zeilen haben (okay, kommt auch darauf an wie breit der Bildschirm eingestellt ist und wie man die Zeilen beim schreiben umbricht ... man kann auch so ein Statement was bei mir 300 Zeilen hat in 1 Zeile packen ... allerdings scrollt man sich dann zu Tode bis man das überblickt ^^).

Ist vlt. schon angeklungen: Mit so "Kleinigkeiten" wie 200zeiligen Sql-Statements hatte ich bisher nix zu schaffen. Ansonsten habich inzwischen recht listigen Code, bei dem ich eine DataRow angeben muß, und die damit zusammenhängenden DataTables, und er bastelt mir die Sql-Statements dazu.
Ich weiß nicht, was mehr Wolf ist: 200 Zeilen Sql zu schreiben, oder mein Tabellen-Joiner-Dings zu benutzen (na, wennichhiermannich Äpfel und Birnen vergleiche, aber Rethorik rules ;)).

Du gehst da glaube ich von völlig falschen Annahmen aus.

Für Deine Version ist es nötig das Dein DataSet-Designer alle Tables geladen hat und somit darauf zugreifen kann. Das kannst Du aber wirklich nur bei Kleinst-DB's veranstalten.

Was meinst Du was Du für einen Trafik produzierst wenn Du aus einer kleineren mittleren DB (100 bis 200 Tables, pro Table sagen wir mal 10 Spalten und in ein paar Table's mit 200.000 + DS drinnen) alles erstmal lädst um dann zu gucken welche Daten brauchst Du. Darum ging es doch.

Und jetzt haste eine Abfrage die über x Tables hinweg geht und jede Menge berechnete Felder beinhaltet und der User an Hand der berechneten Felder die Anzeige haben will.

Z.B. Alle Artikel aus Kategorie X, bei denen im Zeitraum A bis Z für 10.000 € oder Umsatz gemacht wurde, die Kalkulationsmarge nicht unter XX % lag, der Rabatt im Durchschnitt nicht über x% war, in der Renner-Penner-Liste mindestens unter den Top 100 liegen und das nur für den Verkaufsbereich Süd-Deutschland und nach Lieferanten gruppiert.

Das ist ja jetzt noch keine besonders unübliche Auswertung und auch nicht wirklich was weltbewegend Komplexes, sondern eher Normalkost für eine DB ... z.B. von einem Einkäufer der mal nachguckt von welchen Lieferanten er welche Artikel eventuell nachbestellen könnte.

Bei Deiner Vorgehensweise müsstest Du jetzt erstmal alle Umsätze aus dem Zeitraum laden um dann die richtigen Umsätze rauszuziehen. Hat ein Artikel 100.000 Verkäufe in dem Zeitrahmen musst Du die 100.000 DS laden nur um den Gesamtumsatz zu bilden und am Ende stellst Du fest ... verdammt der Artikel ist für den Zeitraum nur auf Platz 102 der Renner-Penner-Liste.

Verstehst Du jetzt besser worauf ich hinauswill, bzw. wo ich sage das da Deine Art der Vorgehensweise völlig versagt?

Jedenfalls zu so Sql: Gibts da eiglich iwie mehr Unterstützung, sowas zu coden?

Nein. Es gibt zwar Dinge wie SQL-Formatter (bis 100 Zeilen gibt es das sogar als kostenlose Browser-Version) aber klar ... Intellisense für Fields- und Tabellennamen gibt es nicht.

Mir kommen diese String - Statements überaus unzeitgemäß vor - also im VS habich Intellisense, Typ-Überprüfung, kann durchsteppen, hab Refaktorierung etc., aber wennich Sql schreibe kommichmir auf einmal wieder vor wie beim C proggen auffm Atari anno 1986: Da schrieb man egal was in den Editor, und hat alles mit Testläufen durchnudeln müssen - es gab nur total kryptische Compiler-Meldungen, und ansonsten Laufzeitfehler.

Ja, so ist es aber mit SQL (ausser Du willst Dinge wie UML mit einbeziehen) ... deswegen versucht ja MS mit dem DataSet-Designer bei kleineren DB-Geschichten diese Coding-Vorteile einzubauen. Aber wenn Du richtig mit Datenbanken arbeitest bleibt Dir irgendwann nichts anderes mehr übrig ... und wenn man sich daran gewöhnt hat, dann geht das auch problemlos. Aber nur weil es noch keiner geschaft hat dafür Coding-Hilfen zu basteln kann man trotzdem nicht auf SQL verzichten wenn man richtig mit einer DB arbeiten will.

ErfinderDesRades schrieb:

hmm - wie gesagt: Es ist schneller, schont Resourcen, minimiert den Umgang mit untypisierten Objekten, und man kann es rückspeichern

Bitte ... sollen wir mal gucken was bei einer Abfrage über 10-20 Tables mit teilweise 5.000.000 DS schneller ist? Deine Version alle Daten zu laden und dann nur die benötigten rauszuziehen oder meine Version sich gleich nur die benötigten 100 anliefern zu lassen? Und vorallem was Ressourcen schonender ist ... 100 DS auf Vorrat zu halten oder x Millionen DS? Und komme jetzt nicht wieder Du lädst ja nur die benötigten Daten, da verweise ich dann direkt auf das Beispiel oben das Du meistens vor einer Abfrage gar nicht weisst welche DS aus welchem Table wirklich als Treffer gelten ... um das zu wissen brauchst Du ja erst die Abfrage.

Zurückspeichern zählt nicht als Vorteil, da das mit meiner Vorgehensweise genauso geht ... User sucht sich aus dem View den DS aus den er bearbeiten will und den liefere ich ihm dann aus der DB zur Bearbeitung an. Will er die Änderungen übernehmen speichere ich das genauso zurück.

Untypisierte Objekte ist ein Vorteil und auch IntelliSense-Unterstützung, aber wiegen die Nachteile nicht auf und vor allem funzt es eh nicht wirklich wenn die DB zu groß wird (siehe Limits).

ErfinderDesRades schrieb:

Naja - was du dir unter einer "kleineren mittleren DB" vorstellst, kann ich inzwischen ja so ungefähr erahnen

Naja ... z.B. das woran ich gerade rumeiere ... derzeit hängen da 7 DB-Files als Backends dran (ist eine Single-User-Version die einfachst per Installationspackage installiert werden muss, daher auch kein DB-Server), gesamt verwalten die rd. 180 Tables und einiges an Views ... das ist langsam eine kleinere mittlere DB. Wenn ich das Projekt mal komplett fertig habe wird es dann sowas um die 200 bis 400 Tables haben ... da könnte man dann schon von etwas mehr als kleinerer mittlerer DB sprechen, aber auch nicht wirklich viel mehr.

Die Grenze mit den 700 Fields - soll das bedeuten, Dataset wäre bei 10 Tabellen a 7 Spalten am Ende? Das wäre glaub definitiv eine Falschinformation.

Nein, weil 10 * 7 ein Ergebnis von 70 ergibt und nicht von 700. SCNR

Aber bei 100 Tabellen * 7 klingt das schon anders und bei 3 Parameters pro Field die das xsd verwaltet (ka welche ... aber DataType, Length und Mandatory würden mir mal Adhoc einfallen) ergibt das 2100 Parameters ... damit wäre den Meldungen nach das Limit erreicht.

ErfinderDesRades schrieb:

Edit: Fällt mir grad ein, du "schuldest" mir noch deine Version einer MiniKass-Anwendung

Täte mich zum einen interessieren, wie du das mit dem Mappen vom DataReader auf ordentliche .Net-Typen regelst,

Das ist nicht wirklich ein Problem.

Habe schon auch einen kleinen Test geschrieben um eine globale Funktion zu entwickeln die mehrere DB's gleichzeitig verwaltet und eine globale Bearbeitungsmaske enthält, die jedes x-beliebige Table die grundsätzlichen Bearbeitungsfunktionen zur Verfügung stellt (anlegen, bearbeiten und löschen). Der Anschluß eines Tables wird dann über die Angabe des Table-Names und in welcher DB sich das Table befindet erledigt ... mehr nicht.

Diese Test-Spielerei funktioniert auch schon problemlos, allerdings habe ich da nur eine sehr rudimentäre Datentyp-Umwandlung drinnen mit der ich noch absolut nicht zufrieden bin.

Da muss ich mich nochmals tiefer in VB.NET reinfuchsen um da noch einen Weg zu finden mit dem ich zufrieden bin. Wenn ich das habe, dann bekommst Du auch Deine Demo.

und zum andern, ob du auch so hübsche Comboboxen ins DatagridView machen kannst, mit denen man einstellt, dasses eben der Artikel "Cola" war, von dem 5 Einheiten gekauft wurden.

Pfui ... direkte Dateneingabe in DataGrids ist im Regelfall ein NoGo (natürlich ... Ausnahmen auf Grund besonderer Anforderung bestätigen natürlich die Regel ... z.B. importierte DS in einer DB vor der letztendlichen Übernahme nochmals zur Bearbeitung zur Verfügung zu stellen oder sowas in der Richtung).

Soll ein DS angelegt/bearbeitet werden bekommt er auch seine Bearbeitungsmaske oder einen passenden Eingabe-Dialog (z.B. für ein Kassensystem ) ... aber direkt im DataGrid ... nööö ... sowas jibbet bei mir i.d.R. nicht.

Aber Du willst jetzt nicht ernsthaft fragen ob ich ein Problem hätte alle verfügbaren Artikel aus einem DB-Table in eine ComboBox oder einem sonstigen Auswahlfeld zur Verfügung zu stellen ... oder etwa doch?

Gruß

Rainer

raist10 schrieb:

Deine Version alle Daten zu laden und dann nur die benötigten rauszuziehen oder meine Version sich gleich nur die benötigten 100 anliefern zu lassen?

Ähm - ich lad nicht alle Daten - mussichnich. Da kann man sehr komfortabel einem TableAdapter eine Query zufügen, die dieselben Spalten einsammelt, aber dann im WHERE - Abschnitt iwelche Auswahlen trifft, etwa nur die Artikel einer bestimmten CategoryID.
Daraus generiert son TableAdapter dann eine zusätzliche Methode
GetArticleByCategoryID(ByVal categoryID As Integer) As ArticleRow()
bzw. eine entsprechende Sub, mit derman eine ArticleDataTable befüllen kann.

Aber eigentlich willich wirklich nicht gegen deine Projekte anstinken. Ich war noch nie über 15 Tabellen, und in dem Bereich geht das MS-Konzept wirklich gut auf, nach dem man die DS direkt beim Abholen gleich in ordentlich typisierte Objekte mapt, und den Umgang mittm vom Compiler unüberprüfbaren Umgang mit SQL möglichst dicht zusammenhält und einkapselt, damit die Hauptarbeit eben mit der Unterstützung und in den Strukturen der .Net-Sprachen erfolgen kann.

Jo, dass Datenbänker iwas dagegen haben, etwas direkt in Tabellen einzugeben, habich gelegentlich mitkriegen dürfen. Aber es ist halt oft so praktisch - viel praktischer als ein Herumgeklickse durch verschiedene Masken.
Beim MiniKass zB. isses ganz logisch und intuitiv, in die Zeile, wo der Posten steht, neben der Anzahl eben auch die Artikel-Art einzugeben.
Gut, kann man auch mit nem EinzelblattView machen, aber ob das wirklich sicherer ist - so ein EinzelblattView enthält dann ja gleich die 10-fache Menge an Controls (und das macht unübersichtlich), um alles abzudecken (zufügen, löschen, eingeben, korrigieren) , was im DGV gleich mit drin ist.

ErfinderDesRades schrieb:

Ähm - ich lad nicht alle Daten - mussichnich. Da kann man sehr komfortabel einem TableAdapter eine Query zufügen, die dieselben Spalten einsammelt, aber dann im WHERE - Abschnitt iwelche Auswahlen trifft, etwa nur die Artikel einer bestimmten CategoryID.
Daraus generiert son TableAdapter dann eine zusätzliche Methode
GetArticleByCategoryID(ByVal categoryID As Integer) As ArticleRow()
bzw. eine entsprechende Sub, mit derman eine ArticleDataTable befüllen kann.

Ich meinte ja auch nicht so einfache Dinge, sondern Abfragen die auf Berechnungen beruhen:

Z.B. Alle Artikel nach Kategorien sortiert in denen im Zeitraum von A bis Z mehr als 1.000 Stück verkauft wurden oder mit denen ein Umsatz größer 10.000 € gemacht wurde und die von den 3 Lieferanten A, B und C stammen.

Das wäre jetzt ein normales Beispiel das in der Praxis auch so vorkommt. Da brauchst Du nun als erstes die Anzahl verkaufte Stück und den Umsatz für den Zeitraum um entscheiden zu können welche Artikel Du nun wirklich für die Anzeige des Ergebnisses brauchst.

Wenn Du das ohne SQL-Statement nur mit den Bordmitteln hinbekommen willst musst Du erstmal alle relevanten Daten laden um diese dann zu filtern.

ErfinderDesRades schrieb:

Aber eigentlich willich wirklich nicht gegen deine Projekte anstinken. Ich war noch nie über 15 Tabellen, und in dem Bereich geht das MS-Konzept wirklich gut auf, nach dem man die DS direkt beim Abholen gleich in ordentlich typisierte Objekte mapt, und den Umgang mittm vom Compiler unüberprüfbaren Umgang mit SQL möglichst dicht zusammenhält und einkapselt, damit die Hauptarbeit eben mit der Unterstützung und in den Strukturen der .Net-Sprachen erfolgen kann.

Keine Frage das Deine Vorgehensweise bei Kleinst-DB's gut funktioniert, habe ich ja auch nie angezweifelt. Mein Thema war ja von Anfang an nur, dass das eben nur dafür passt aber spätestens bei mittleren DB-Vorhaben völlig unbrauchbar wird.

Die Frage ist halt immer nur baue ich auf einer Technologie auf die Ausweitungen des Projektes nicht mehr packen wird oder baue ich gleich auf einer Technologie auf die unbegrenzten Aufbau mit macht.

ErfinderDesRades schrieb:

Jo, dass Datenbänker iwas dagegen haben, etwas direkt in Tabellen einzugeben, habich gelegentlich mitkriegen dürfen. Aber es ist halt oft so praktisch - viel praktischer als ein Herumgeklickse durch verschiedene Masken.
Beim MiniKass zB. isses ganz logisch und intuitiv, in die Zeile, wo der Posten steht, neben der Anzahl eben auch die Artikel-Art einzugeben.
Gut, kann man auch mit nem EinzelblattView machen, aber ob das wirklich sicherer ist - so ein EinzelblattView enthält dann ja gleich die 10-fache Menge an Controls (und das macht unübersichtlich), um alles abzudecken (zufügen, löschen, eingeben, korrigieren) , was im DGV gleich mit drin ist.

Bloss wie überall ... es geht nicht darum was ist für den Programmierer praktischer sondern was ist sinnvoller und für den User nützlicher.

Z.B. bei einer Kassenanwendung würde ich niemals mit einer direkt Eingabe in einem DataGrid arbeiten. Das mag für Dich als Programmierer intuitiv sein, aber für den User noch lange nicht und es ist auch absolut nicht im Sinne des Erfinders das man Eingaben die bereits boniert wurden so einfach abändern kann. Jeder der eine Kassenanwendung bestellt erwartet/verlangt das Bonierungen nur über eine separate Storno-Funktion verändert/rückgängig gemacht werden können. Alles andere würde einem Mißbrauch durch Personal Tür und Tor öffnen. Und Du musst in einem DataGrid auch jedes Mal entscheiden welche Daten dürfen wann verändert werden ... ein Preis muss direkt bei der Bonierung änderbar sein (von wegen Sonderpreise o.ä.) aber danach nicht mehr. Jetzt musst Du bei einem DataGrid eine Logik schreiben wenn ein Preis noch änderbar ist und ab wann er nicht mehr änderbar ist, genauso wie eigentlich für alles andere auch.

Entfällt bei der Version mit den Eingabe-Controls völlig, denn solange was im Control ist ist es änderbar und wenn die Bonierung bestätigt wird geht es aus den Controls raus und wir in einem Listview als Posten XYZ angezeigt. Und Posten die dort angezeigt werden sind nicht mehr änderbar, ausser durch die separate Storno-Funktion.

Und für die Kassiererin sind eigene Eingabefelder für jede Position Artikel-Nummer/-Bezeichnung, Stückzahl einfacher und deutlich intuitiver zu handeln. Vorallem mit schön großen und schneller erreichbaren Feldern die man wunderbar in der Reihenfolge wie der Cursor springen soll bestimmen kann. Darfst ja nicht vergessen Kassierer stehen i.d.R. unter Zeitdruck ... Artikel, Stückzahl, bonieren, Artikel, Stückzahl, bonieren, Artikel, Stückzahl, bonieren ... etc., etc. .

Und vor allem mit eigenen Controls ist die Kassiererin davor geschützt in der Hektik ihrer Arbeit bereits bonierte Eingaben versehentlich zu ändern. Stell Dir vor die verklickt sich im DataGrid und gibt Daten ein bevor sie bemerkt das sie sich verklickt hat. Dann kann die nun im Zweifel den kompletten Einkauf nachkontrollieren um die Falscheingabe zu finden. Dafür knüpft Dich der User am nächsten Baum auf.

Es ist schlicht und ergreifend wie beim OOP ... Vorgänge werden sauber voneinander getrennt. Ein Bearbeitung von Daten ist nun mal was völlig anderes als eine Anzeige von Daten. Du schreibst im OOP ja auch nicht Klassen die eierlegende Wollmichsäue sind und x Aufgaben ausführen. Sondern jede Aufgabe bekommt eine eigene Klasse/ein eigenes Objekt und damit hast Du die sauberer Aufgabentrennung. Und genauso sollte man es auch machen wenn es anfängt richtig wichtig zu werden ... nämlich bei der Datenhaltung/-bearbeitung. Alles andere ist grober Unfug und eher unprofessionell (wie gesagt Ausnahmen bestätigen die Regel).

Das ist der Grund wieso DB'ler das Thema Datenbearbeitung direkt im DataGrid eher als Pfui ansehen. Wie gesagt, Spezial-Themen wie z.B. hypothetische Zukunftsmodelle mit Zeitstrahl bei denen man Daten direkt abändern können will um zu sehen wie sich eine Änderung an einer Stelle auf die nachfolgenden Zahlen auswirkt sind ganz klar von der Aussage ausgenommen (Umsatz-/Gewinnplanungen oder Geschäftspläne an sich).

Gruß

Rainer

wie gesagt: minikass kann man auch mit ne annere Oberfläche machen. Wennichnochma überleg, findichs DGV mit ComboColumns korrekt angewandt, denn es ging eher drum das Prinzip relational verknüpfter Daten zu zeigen als eine Kassensoftware.
Mir fallen aber noch paar annere Anwendungen ein, wo ich fröhlich direkt ins Grid eingeben möchte - etwa das KlientenKonten-AbrechnungsProgramm (wovon meine DGV-Screenies waren).
Da isses glaub eher wünschenswert, einen Bon mit all seinen Posten im Überblick zu haben, und auch direkt in diesem Überblick korrigieren zu können (etwa wenn der falsche Klient eingetragen ist, einen Posten zu bezahlen).
Hmm - in meim RegexTester auch.
Dann habichhiermal einen Ansatz fürn Bestellwesen aufgezeigt, bei dem man den Katalog durchgeht, und bei den Artikeln nur reinschreiben muß, wieviel man davon haben will. Findich auch besonders praktisch im Grid.
(Und hat sich auch ein Datenbänker drüber aufgeregt - wird dir gefallen ;))

Die Frage ist halt immer nur baue ich auf einer Technologie auf die Ausweitungen des Projektes nicht mehr packen wird oder baue ich gleich auf einer Technologie auf die unbegrenzten Aufbau mit macht.

Noja - zum einen sollte man bei der Betrachtung der Ausweitungsmöglichkeiten auffm Teppich bleiben. Wie gesagt: Ich bin noch nie über 15 Tabellen gewesen, also was sollichmich da jetzt ins Entity-Framework einarbeiten.
EF ist übrigens die Technologie, auf die ich setzen würde, wenns unseremeinen mal zu eng wird mittm Dataset.

Das peile ich bei deinem Ansatz noch nicht so richtig: "Normalerweise" mapt man die Datensätze auf .Net-konforme Klassen, und hat dann ein relationales Datenmodell im Client - also ein Abbild eines Ausschnitts des Datenbestandes der DB, mit dem man aber OOP operieren kann.
Das ist der Grundgedanke des typisierten Dataets, und ebenso der OR-Mapper, wies EF einer ist.
Bei dir erkenne ich aber gar keine Datenklassen, und daher wäres interessant, wie du das mit einer Combobox backen tätest, die für einen BonPosten die zulässigen Artikel anbietet (also mal egal, ob in einer DGV-Column oder separat).

ErfinderDesRades schrieb:

wie gesagt: minikass kann man auch mit ne annere Oberfläche machen. Wennichnochma überleg, findichs DGV mit ComboColumns korrekt angewandt, denn es ging eher drum das Prinzip relational verknüpfter Daten zu zeigen als eine Kassensoftware.

Sorry, natürlich wollte ich hier nicht Deine Demo "schlecht machen" denn für das was sie demonstrieren soll ist es völlig okay so. Mir ging es nur darum die Thematik zu erläutern wieso die meisten DB'ler die direkte Dateneingabe in einem DataGrid ablehnen/als negativ erachten. Und das war da gerade gut an Hand des Beispieles Minikass zu erklären, wenn man von einem Praxiseinsatz ausgehen würde.

Mir fallen aber noch paar annere Anwendungen ein, wo ich fröhlich direkt ins Grid eingeben möchte - etwa das KlientenKonten-AbrechnungsProgramm (wovon meine DGV-Screenies waren).
Da isses glaub eher wünschenswert, einen Bon mit all seinen Posten im Überblick zu haben, und auch direkt in diesem Überblick korrigieren zu können (etwa wenn der falsche Klient eingetragen ist, einen Posten zu bezahlen).

Auch hier ist es suboptimal, einfach wegen dem Problem der unfreiwilligen Änderung. Es ist für den User klar gut wenn er die Buchungen in einer Übersicht auswählen kann, aber die Bearbeitung sollte dann nach wie vor über ein separates Bearbeitungsformular erfolgen. Vor allem da es doch eh kein Mehraufwand ist. Irgendein Bearbeitungsformular für die Grundeingaben braucht man ja eh und das kann man gleich so global gestalten das es Stand-Alone funktioniert. Dann reicht ein Doppelklick auf den entsprechenden Eintrag im DataGrid und das Bearbeitungsformular öffnet sich mit dem angeclickten Buchungssatz ... bearbeiten, speichern, Änderungen verwerfen etc. und nach schliessen des bearbeitungsformulares wird der Buchungssatz im DataGrid neu geladen oder das DataGrid akutalisiert.

Denk mal an das DataGrid von dem ich Dir Bilder gezeigt habe. Das Teil beherrscht die Anzeige aller Daten für das es einen gültigen SQL-String übergeben bekommt alles automatisch und dynamisiert. Sowas wäre völlig unmöglich wenn man dort direkt die Datensätze bearbeiten könnte. Klar kann ich Format-Gültigkeiten und ähnliche Standard-Regelung auch dynamisch programmieren, aber spätestens bei Logik-Regelungen in der Dateneingabe würde sowas völlig versagen da Logik-Validierung immer individuell ist (die Datumgseingabe 27.06.2010 kann für ein Geburtsdatum korrekt sein, aber für die Eingabe eines Buchungsdatums ungültig wenn das BelegDatum 20.06.2011 aufweist ... eine Buchung kann halt nicht vor dem Belegdatum stattfinden).

Durch Trennung von Anzeige und Bearbeitung habe ich damit aber kein Problem.

Datensätze werden in Bearbeitungsformularen - die auch die komplette Logik-Validierung beinhalten - bearbeitet und Anzeige erfolgt über DataGrids. Klickt der User einen Eintrag im DataGrid an öffnet sich das Bearbeitungsformular zu dem Datensatz ... das kann man sogar automatisieren wenn man dafür sorgt das alle SQL-Statements oder Views die in dem DataGrid angezeigt werden in der 1ten Spalte eine Info über das zu nutzende Anzeigeformular haben und in der 2ten Spalte immer den PrimaryKey beinhalten (die Spalten sind dann natürlich hidden).

Hmm - in meim RegexTester auch.

Hilfs-Tools für Developer sind ein anderes Thema. Hier würde ich auch auf die Annehmlichkeiten für End-User verzichten und davon ausgehen das das Ding nur ein Profi bedient der auch weiss was er tut.

Dann habichhiermal einen Ansatz fürn Bestellwesen aufgezeigt, bei dem man den Katalog durchgeht, und bei den Artikeln nur reinschreiben muß, wieviel man davon haben will. Findich auch besonders praktisch im Grid.

Sowas würde bei mir jetzt tatsächlich unter Sonderanforderung fallen und in dem Falle scheint ein DataGrid wirklich optimal zu sein. Aber klar ... hier habe ich auch keinerlei Logik-Validierung nötig, es kann keine unabsichtlichen Fehleingaben geben und ich habe nur ein änderbares Feld und kennt nur zwei Regeln: Nicht kleiner als Null und muss eine Ganzzahl sein. Für sowas würde kein Mensch ein Bearbeitungsformular machen ... ausser es gibt noch weitere Angaben dazu.

Wobei aber auch extrem selten in der Praxis seinen Kunden den kompletten Warenkatalog als DataGrid präsentieren würde, aber das ist ein anderes Thema.

ErfinderDesRades schrieb:

Noja - zum einen sollte man bei der Betrachtung der Ausweitungsmöglichkeiten auffm Teppich bleiben. Wie gesagt: Ich bin noch nie über 15 Tabellen gewesen, also was sollichmich da jetzt ins Entity-Framework einarbeiten.

Man kann es gerade bei richtigem DB-Einsatz (also Datenhaltung des Users und nicht Programm-Datenhaltung) nie vorhersagen wohin die Reise gehen wird. Wie oft war die Urpsrungsanforderung ein Datenmodell das mit 10 bis 20 Tables auskam und am Ende hatte sich das Ganze dann auf 100 + Tables ausgeweitet.

Klar, wenn ich nur meine CD's, DVD's oder Bücher handeln will ist sowas okay. Aber selbst das fängt dann mit CD's an ... dann kommen MP3's dazu, danach dann DVD's und am Ende sollen noch Bücher und die alte Schallplattensammlung dazu und am besten noch mit Verleihverfolgung etc., etc., etc. ... jo, da kommste dann auch mal schnell auf 30 oder 40 Tables wo man erst gedacht hat naja 1 Table reicht ja (reicht eh so gut wie nie ^^).

Ich persönlich habe eh die Erfahrung gemacht das man auch das kleinste Projekt so professionell und ausbaufähig wie möglich gestalten sollte, auch wenn es am Ende dann nie gebraucht wird. Aber man weiss es vorher nicht und bei den Projekten wo man es dann braucht spart man sich so enorm viel Zeit wenn man es von Anfang an richtig gemacht hat. Aber gut ... das ist natürlich eine persönliche Einstellungssache und kann man sicher nicht faktisch darüber diskutieren. Genauso wie ich NIE Hilfsfunktionen direkt im Code anspreche sondern nur über Schnittstellen gehe ... selbst Aufrufe von Forms würde ich NIE direkt im produktiven Code ausführen, sondern über ein separat gekapselte Methode ausführen lassen oder um die Form ein eigenes Handling-Objekt wrappe und nur dieses im produktiven Code anspreche. Halten manche für mehr als Übertrieben ... aber wer schonmal in einem etwas größeren Projekt Forms austauschen musste die enorm oft zum Aufruf kommen wird gut verstehen können wieso ich das aus Prinzip so mache.

EF ist übrigens die Technologie, auf die ich setzen würde, wenns unseremeinen mal zu eng wird mittm Dataset.

Auch Ansichtssache ... ich würde mich weigern ausser es wäre ein Muss-Anforderung. Der Grund ist schlicht das Microsoft mir zuviel einfach ändert und man im Nachgang nur enormen Aufwand und Ärger hat seine Anwendung wieder zum laufen zu bringen. Aber das ist eine persönliche Einstellung die hauptsächlich auf Erfahrungen mit MS aus der Vergangenheit. Versuch mal ein aufwändigeres, älteres Access-Frontend zum Laufen zu bringen bei einem User der ganz begeistert auf seinem neuen Rechner Office 64 bit aufgezogen hat ... kannste vergessen, keine Chance da die 64 bit Version von Office die alten Com-Dll's im Regelfall nicht mehr nutzen kann. Von der unsäglichen Dll-Hell die MS verbrochen hat will ich gar nicht reden.

ErfinderDesRades schrieb:

Das peile ich bei deinem Ansatz noch nicht so richtig: "Normalerweise" mapt man die Datensätze auf .Net-konforme Klassen, und hat dann ein relationales Datenmodell im Client - also ein Abbild eines Ausschnitts des Datenbestandes der DB, mit dem man aber OOP operieren kann.
Das ist der Grundgedanke des typisierten Dataets, und ebenso der OR-Mapper, wies EF einer ist.
Bei dir erkenne ich aber gar keine Datenklassen, und daher wäres interessant, wie du das mit einer Combobox backen tätest, die für einen BonPosten die zulässigen Artikel anbietet (also mal egal, ob in einer DGV-Column oder separat).

Du bist da offensichtlich zu sehr in das Thema Datenklassen verfangen. Du brauchst theoretisch gar keine Datenklassen sondern die reinen Zugriffsklassen reichen völlig. Vor NET hat man das auch so geregelt.

Nimm eine OCDB-Connection, über die setzt man SQL-Statement ab ala "SELECT ArtBezeichnung FROM tbl_Artikel WHERE ArtAktiv = 1" damit bestückt man ein klassisches ADO-Recordset. Dieses wird dann mit einem einfachen Do Loop Until rst.EOF abgearbeitet und jeder Eintrag im Recordset wird der ComboBox hinzugefügt als Eintrag. Das progst Du eh nur einmal ... oben kommt SQL-Statement und die Reference auf eine Combo-Box und den Rest erledigt die Methode ComboBoxFill eh automatisch. Ist ganz easy und wirklich kein Aufwand ... sowas schreibste in 2-3 Minuten (wenn das Zugriffsobjekt steht) und Feierabend. Datentyp Probleme gibt es dabei nicht ... da das Recordset selber die Information beinhalten welches Recordset-Field welchen DB-DataType aufweisst ... die Umwandlung in System.Data erledigst Du auch optimalerweise mit einem einzigen Objekt das die Type-Umwandlung eines Recordset-Field handelt für die gesamte Anwendung (das ist aber die Stelle wo ich da in meiner kleinen Demo noch nicht wirklich zufrieden bin ... zugegeben ^^).

Was anderes macht Deine Vorgehensweise ja auch nicht, bloss Du hast es nicht selber geproggt sondern einen Automatismus hergenommen (die TypeUmwandlung erfolgt ja auch nur durch die Info des xsd-Schemas des DataSet-Designers). Und bei MS-Automatismen habe ich eh immer so meine Schwierigkeiten weil sie sehr oft enorm viel langsamer sind, daher benutze ich die meistens erst wenn ich sicher bin das die a) wirklich zuverlässig funzen und b) auch keine sonstigen Probleme wie 100-fach langsamer o.ä. mit sich bringen.

Das ist also keine Kunst und auch extrem schnell. Wenn Du da nicht gerade x00.000 DS reinlädst läuft das in unter 50 MS ab wenn die DB-Verbindung einigermaßen mithalten kann, aber das Thema Geschwindigkeit der Verbindung haste ja immer wenn Du auf eine echte DB zugreifst.

Gruß

Rainer

raist10 schrieb:

Du bist da offensichtlich zu sehr in das Thema Datenklassen verfangen.

Oder du zuwenig ;)

Du brauchst theoretisch gar keine Datenklassen sondern die reinen Zugriffsklassen reichen völlig. Vor NET hat man das auch so geregelt.

Ja, aber dann hat sich der Stand der Technik dahin entwickelt, DB-Daten nach Datenklassen zu mappen, damit man im weiteren mit einer OOP-Struktur proggen zu können, die ein relationales Modell repräsentiert. Ich würde diese Entwicklung unbedingt als Fortschritt ansehen, und MS war da nichtmal federführend, jdfs. was EF angeht, dazu waren sie gezwungen, weil ihnen die Leute reihenweise davongelaufen sind, zu 3rd-Party-OR-Mappern, etwa Hybernate.

Nimm eine OCDB-Connection, über die setzt man SQL-Statement ab ala "SELECT ArtBezeichnung FROM tbl_Artikel WHERE ArtAktiv = 1" damit bestückt man ein klassisches ADO-Recordset. Dieses wird dann mit einem einfachen Do Loop Until rst.EOF abgearbeitet und jeder Eintrag im Recordset wird der ComboBox hinzugefügt als Eintrag. Das progst Du eh nur einmal ...
...
Was anderes macht Deine Vorgehensweise ja auch nicht...

Na doch. Während du dein ZugriffsObjekt bei jedem Zugriff benützen musst (wennich recht verstehe, isses ZugriffsObjekt funktional eher ein Modul als eine Klasse, von der man viele Instanzen erstellt), mappe ich nur einmal in ordentliche Klassen, und geniesse dann die komplette Unterstützung der typisierten Programmiersprache, inklusive der Designer der MS-IDE.
Zum Abspeichern mussichhalt Zurück-Mappen - wie du richtig sagst - da empfehle ich den erprobten Automatismus.

Wesentlicher Vorteil von gemappten Objekten gegenüber RecordSets, deren einzelne Spalten jedesmal übersetzt werden müssen, ist auch die Databinding-Option. Ich binde eine Combo, die Kategorien repräsentiert an die CategoryID-Spalte der Artikel-DataRows, und so kann der User die CategoryIDs von ArtikelRows festlegen - normaldeutsch gesprochen: Die Artikel einer Kategorie zuordnen.
Oder im Minikass wird ein BonPosten einem Artikel zugeordnet.
Dazu brauchts dank Databinding keine Zeile User-Code. Die Befüllung der Combo mit Kategorien läuft per DataBinding, die Aktualisierung der Combo, dass sie jeweils auf die Kategorie springt, der der soeben editierte Artikel zugehört, macht das Binding, und auch das Schreiben des neuen Kategorie-Wertes in den Artikel-Datensatz.

U.a. deswegen halte ich Datenklassen für unabdingbar, weil ich mit Databinding ein standardisiertes, überaus mächtiges und sicheres Instrument habe für den Brückenschlag von Gui zu den Daten.
Dank Databinding kannich Gui und Daten als getrennt voneinander denken.

Ah - zum trennen von Anzeige und Bearbeitung: Erinnert mich an den MVC-Pattern und an MVP. Beide Pattern halte ich nicht für Praxistauglich, weil man View und Controller nicht trennen kann. Eine Textbox hat ihre Controlling-Funktionalität bereits eingebaut - da kann man keine Controller-Schicht mehr separieren. Sinnigerweise heißen Controls ja auch Controls.
Ich kenn eiglich nur 2 Controls, die wirklich nur zur Anzeige da sind: Label und Progressbar.

Jo, das schöne nun am Databinding-Pattern ist, er gesteht den Controls ihre Controlling-Funktionalität zu.
Über die Bindings wird halt definiert, welches Control welche Property welches' Datensatzes controllt. (Readonly-Option ist natürlich auch immer gegeben).

ErfinderDesRades schrieb:

Ja, aber dann hat sich der Stand der Technik dahin entwickelt, DB-Daten nach Datenklassen zu mappen, damit man im weiteren mit einer OOP-Struktur proggen zu können, die ein relationales Modell repräsentiert. Ich würde diese Entwicklung unbedingt als Fortschritt ansehen, und MS war da nichtmal federführend, jdfs. was EF angeht, dazu waren sie gezwungen, weil ihnen die Leute reihenweise davongelaufen sind, zu 3rd-Party-OR-Mappern, etwa Hybernate.

Du redest hier aber von modellgetriebenem Development per UML-Diagrammen. Da sind wir hier im Forum aber sowas von weit entfernt.

ErfinderDesRades schrieb:

Na doch. Während du dein ZugriffsObjekt bei jedem Zugriff benützen musst (wennich recht verstehe, isses ZugriffsObjekt funktional eher ein Modul als eine Klasse, von der man viele Instanzen erstellt),

Öhem ... nö ... wie kommst Du darauf das ein Zugriffs-OBJEKT eher ein Modul als eine instanzierbare Klasse ist? Wäre ja völliger Nonsens.

Ich kann logischerweise von einem Zugriffs-Objekt mehrere Instanzen erstellen (also mehrere Connections aufbauen parallel zueinander) oder auch nur eine Instanz durchreichen dahin wo ich es haben will.

Genau wie bei Deiner Vorgehensweise auch, Du brauchst ja auch ein Connection-Object damit es funzt. Mehr ist eine Zugriffsklasse auch nicht.

mappe ich nur einmal in ordentliche Klassen, und geniesse dann die komplette Unterstützung der typisierten Programmiersprache, inklusive der Designer der MS-IDE.

Ja klar ... mach das mal mit 300 bis 400 Tabellen. Viel Spaß .... bis Du da Dein Mapping mit allen Datenklassen fertig hast, habe ich die Anwendung schon längst ausgeliefert.

Klar, modellgetriebene Entwicklung beginnt da langsam seine Vorteil zu entwickeln. Aber eben nur langsam, bei richtig großen Datenbank würde ich vermutlich auch nichts anderes mehr machen als modellgetriebene Entwicklung mit Hibernate oder dem Entity-Framework.

Aber der DataSet-Designer ist eben "nur" der kleine Ableger für Kleinst-DB's und für kleinere bis mittlere DB's ist modellgetriebene Entwicklung meistens noch mit Kanonen auf Spatzen geschossen (aber nur meine persönliche Meinung) und erhöht die Entwicklungskosten soweit das das kaum noch ein Kunde bezahlen wird.

ErfinderDesRades schrieb:

Wesentlicher Vorteil von gemappten Objekten gegenüber RecordSets, deren einzelne Spalten jedesmal übersetzt werden müssen, ist auch die Databinding-Option. Ich binde eine Combo, die Kategorien repräsentiert an die CategoryID-Spalte der Artikel-DataRows, und so kann der User die CategoryIDs von ArtikelRows festlegen - normaldeutsch gesprochen: Die Artikel einer Kategorie zuordnen.

Öhem ... Moment ... dafür braucht man aber kein typisiertes/gemapptes DataSet. Das Databinding geht auch mit untypisierten/ungemappten DataSets genauso, man muss halt nur einen einzigen Schritt mehr machen und pro Bindung-Spalte den DataType angeben.

Oder im Minikass wird ein BonPosten einem Artikel zugeordnet.
Dazu brauchts dank Databinding keine Zeile User-Code. Die Befüllung der Combo mit Kategorien läuft per DataBinding, die Aktualisierung der Combo, dass sie jeweils auf die Kategorie springt, der der soeben editierte Artikel zugehört, macht das Binding, und auch das Schreiben des neuen Kategorie-Wertes in den Artikel-Datensatz.

Ganz ehrlich ... wenn ich sowas für kleinere bis mittlere DB's will dann nehme ich gleich Access als Frontend und knall dann dort dahinter was ich will als Backend. Access beherrscht die Bindung mit dem DAO-Objekt-Modell noch einfacher das hier das Mapping entfällt und trotzdem der korrekte Datentyp zur Anwendung kommt, da Access den Datentyp für die Bindung gleich aus der Tabelle ausliest.

ErfinderDesRades schrieb:

U.a. deswegen halte ich Datenklassen für unabdingbar, weil ich mit Databinding ein standardisiertes, überaus mächtiges und sicheres Instrument habe für den Brückenschlag von Gui zu den Daten.
Dank Databinding kannich Gui und Daten als getrennt voneinander denken.

Moment ... Databinding ist unabhängig von gemappten Datenklassen. Wie schon gesagt, DataBinding kannst Du genauso problemlos ohne Mapping mit untypisierten DataSets durchführen.

Aber gut ... erkläre mir dann bitte doch mal wie Du mit Deiner Vorgehensweise dem User dynamische Abfragen anbieten willst.

Ich habe z.B. in meiner aktuellen Geschichte eine dynamische Abfrage drinnen in der der User aus rd. 250 Kriterien frei Schnauze eine Abfrage nach seinen Vorstellung zusammen klicken (Anhakeln/Abhaken, mehrfach Auswahlen, Zahlen-/Datums-Eingaben nach unterschiedlichen Punkten wie größer, kleiner, zwischen und gar nicht, etc., etc., etc. ) kann. Dabei müssen Daten aus rd. 100 Tables berücksichtigt werden und als Ergebniss kommen die Kunden raus auf die ALLE eingegebenen Kriterien EGAL in welcher Kombination eingegeben zu treffen ... dabei kann als Abfrage sowas in der Richtung rauskommen: Alle Kontakte die Kunden sind, älter als 40 jahre, verheiratet sind, mindestens 2 Kinder haben (mehr gilt auch als Treffer), in eigenem Immobilieneigentum wohnen, mindestens 1 Auto besitzen (mehr gilt auch als Treffer), über 60.000 € Brutto-Einkommen ZUSAMMEN aufweisen oder über 40.000 € Bruttoeinkommen EINZELN (alles drüber gilt auch als Treffer) und noch keinen Versicherungsvertrag der Kategorie XYZ vom Anbieter Pfefferminzia abgeschlossen haben und bei denen der letzte Termin-Kontakt länger als 6 Monate her ist.

Erklär mir bitte nun mal wo der Vorteil von Daten-Mapping und Datenklassen liegt wenn Du sowas erstellen musst. Das VB.NET das im DataSet-Designer vermutlich eh nicht packen würde weil die 100 Tables definitiv mehr als 700 Felder/2100 Paramter mit sich bringen lassen wir jetzt einfach mal dafür aussen vor. Ich bin gespannt. Bitte aber immer unter dem Aspekt das da noch x weitere Tables hinzukommen können bis alles fertig ist.

ErfinderDesRades schrieb:

Ah - zum trennen von Anzeige und Bearbeitung: Erinnert mich an den MVC-Pattern und an MVP. Beide Pattern halte ich nicht für Praxistauglich, ...

Mach mal was eine größere DB und trenne nicht Bearbeitung von Gesamt-/Übersichts-Anzeige und dann reden wir weiter. Du wirst ziemlich schnell ziemlich viel Probleme haben oder einen sehr unzufriedenen Kunden.

Denn bei Deinen ganzen Überlegungen lässt Du das Thema logische Eingabe-Validierung aussen vor. Das ist aber Pflichtprogramm in einer DB-Anwendung um die DB vor absichtlichen/unabsichtlichen Nonsens-Eingaben zu schützen wie z.B. für einen Kunden ein Geburtsdatum 26.01.1079 oder zu vermeiden das bei einem Verkauf Minus-Stückzahlen eingetragen werden oder, oder, oder ... .

Klar kannst Du das alles auch direkt im DataGridView bei CellChange proggen. Aber dann musst Du pro Anzeige ein eigenes DataGridView proggen und das macht wenig Sinn. Siehe mein DataGrid was ich Dir mal gepostet habe das derzeit die Anzeige von rd. 130 Views/Abfragen problemlos beherrscht und die nächsten 600 Views auch noch ohne Probleme darstellt.

Mal davon abgesehen das jeder User verrückt werden würde wenn er da pro DS 30 und mehr Felder zum ausfüllen hätte und sich nun wie ein wilder durch das DataGridView scrollen müsste. Da verreckt dir jeder User mit Augenkrebs bevor er mit der Eingabe fertig ist.

Aber egal ... ich werde Dich nicht überzeugen da die Vorgehensweise unsinnig ist und Du wirst mich nicht überzeugen das die Vorgehensweise Sinn macht.

Gruß

Rainer

raist10 schrieb:

Du redest hier aber von modellgetriebenem Development per UML-Diagrammen. Da sind wir hier im Forum aber sowas von weit entfernt.

"modellgetriebenem Development" hörichjetzt das erste mal.

Wenn es bedeutet, Datensätze in eine typisierte Objekt-Struktur zu übertragen, um im weiteren OOP proggen zu können, dann bist du davon vlt. entfernt - ich nicht

Mag sein, dass der Dataset-Designer nur für "Kleinkram" konzipiert ist. Aber die Denkweise ist bei EF und Hybernate keine andere, und deshalb ists typisierte Dataset kein totes Gleis, sondern zunächst mal selbst ordentlich mächtig (ja, für dich pillepalle ;), aber ich glaub, die überwiegende Mehrheit der vbParadise-Nutzer wird die nächsten 10 Jahre ebensowenig über dieses pillepalle hinauskommen, wie ich die letzten 10 Jahren).
Und dann ändert sich nicht soo viel, wenn man iwann auf EF wechselt.

Wie gesagt: Mapping macht überhaupt keine Arbeit - bei Kleinkram machts der Dataset-Designer, bei Großkram machens die EF-Tools. Also von Kanonen auf Spatzen kann da keine Rede sein - auf keiner Ebene.

Aber gut ... erkläre mir dann bitte doch mal wie Du mit Deiner Vorgehensweise dem User dynamische Abfragen anbieten willst.

Hmm. Im Vorpost hast du ein eigentlich recht naheliegendes Gui-Konzept als Sonderfall aufgefasst, und jetzt stellst du frei konfigurierbare Abfragen über hunderte von Tabellen als Standard-Anforderung hin.
Das wäre für mich eher ein Sonderfall. Da muß man sich ja einen richtigen SQL-Assistenten überlegen - du wirst ja nicht vom User verlangen, plain SQL einzugeben?
Ich hab nurmal was gemacht für eine Model-Foto-Verwaltung, da konnte dann alle Models unter 14 mit besonders dickem Arsch, und mw. aus Polen kommend abfragen (warne Spielerei).
Dazu habich einen Sql-Generator gebastelt, der anhand der DataTables das Sql auch so formuliert hat, dass mit getrennten Abfragen die getrennten DataTables korrekt befüllt wurden, mit den erforderlichen über- und untergeordneten Datensätzen.
K.A., ob man den Ansatz noch weiter ausbauen könnte (glaubich eiglich, weil das Teil konnte immerhin 0 bis viele Kategorien verknüpfen) - aber ich sterb auch nicht dran, mal ein SQL-Statement selbst zu coden.
Aber man kanns ja meist vermeiden.

Und Validierung - gibts auch schöne Konzepte, grad mittm Dataset. Die Datarows sind nämlich auch so freundlich, IDataErrorInfo von vornherein zu implementieren - da kann man schon schnucklige Sachen mit anstellen.

ErfinderDesRades schrieb:

"modellgetriebenem Development" hörichjetzt das erste mal.

Guckst Du hier:

de.wikipedia.org/wiki/Modellgetriebene_Softwareentwicklung
de.wikipedia.org/wiki/Model_Driven_Architecture

Mag sein, dass der Dataset-Designer nur für "Kleinkram" konzipiert ist. Aber die Denkweise ist bei EF und Hybernate keine andere, und deshalb ists typisierte Dataset kein totes Gleis, sondern zunächst mal selbst ordentlich mächtig (ja, für dich pillepalle ;), aber ich glaub, die überwiegende Mehrheit der vbParadise-Nutzer wird die nächsten 10 Jahre ebensowenig über dieses pillepalle hinauskommen, wie ich die letzten 10 Jahren).
Und dann ändert sich nicht soo viel, wenn man iwann auf EF wechselt.

Okay, nachdem ich mich jetzt mal das Thema DataSet-Designer und Entity-Framework etwas intensiver nachgelesen habe, bin ich darauf gestossen das beides das Gleiche ist.

Und nachdem ich nun weiss das es der dritte oder vierte (je nachdem wie man zählt) Anlauf von MS ist ein ORM-Tool zu entwickeln bin ich dem Teil gegenüber noch skeptischer. Linq-to-SQL haben sie ja erst vor relativ kurzer Zeit eingeführt (ist ja auch ein ORM-Tool) und jetzt muss man lesen das die das auch gleich wieder eingestampfen um sich mehr auf das ADO.NET Entity Framework zu konzentrieren.

Da liegt die Überlegung ob denen morgen nicht was Anderes einfällt und EF auch eingestampft wird ziemlich nahe. Naja ... halt typisch MS.

Hmm. Im Vorpost hast du ein eigentlich recht naheliegendes Gui-Konzept als Sonderfall aufgefasst, und jetzt stellst du frei konfigurierbare Abfragen über hunderte von Tabellen als Standard-Anforderung hin. Das wäre für mich eher ein Sonderfall.

Ein GUI das einen Artikel-Katalog in einem DataGridView präsentiert ist wohl ein Sonderfall (sowas habe ich in der Praxis wirklich noch nie gesehen ^^), dagegen sind dynamische Abfragen die der User sich über GUI zusammen klickt in so gut wie jeder Datenbank-Anwendung Standard (ob jetzt als Übersichts-/Statistik- oder einfacher Suchabfrage ist dabei ja egal). Okay ... nicht immer gleich so umfangreich das man mit einer Abfrage gleich 100 Tabellen zusammen fasst klar, aber auch sowas ist eher Standard.

Da muß man sich ja einen richtigen SQL-Assistenten überlegen - du wirst ja nicht vom User verlangen, plain SQL einzugeben?

Ja klar ... User und SQL-Eingaben schliessen sich einfach mal zwangsläufig aus.

Und Validierung - gibts auch schöne Konzepte, grad mittm Dataset. Die Datarows sind nämlich auch so freundlich, IDataErrorInfo von vornherein zu implementieren - da kann man schon schnucklige Sachen mit anstellen.

Och Menno ... habe ich jetzt doch mehrfach erklärt.

Es geht nicht darum ob es möglich ist, sondern darum das Du solche Dinge individuell machen musst wenn Du Anzeige und Eingabe im DataGridView erledigst. Sprich in ein und demselben DataGridView verschiedenste Datensätze anzuzeigen wird dadurch enormst kompliziert da Du jedesmal die komplette Individual-Validierung dafür bereit stellen musst.

Musst Du auch bei Bearbeitungsformularen individuell proggen, aber da die separat sind kannst Du die Anzeige aller möglichen Datensätze in einem einzigen DataGridView regeln da Du dort nur die Anzeige hast und daher nicht die Validierung mit unterbringen musst.

Aber gut ... wir kommen auf keinen grünen Zweig, bzw. auf keinen gemeinsamen Nenner. Lass uns an dieser Stelle dann auch die schon seit längerem OT laufende Diskussion damit beenden.

Gruß

Rainer

Sorry, ich muß das nochmal mitte Validierung aufnehmen

raist10 schrieb:

Es geht nicht darum ob es möglich ist, sondern darum das Du solche Dinge individuell machen musst wenn Du Anzeige und Eingabe im DataGridView erledigst.

Bei "schnucklige Sachen" beschäftige ich mich mit dem IDataErrorInfo-Interface, und davon das Konzept ist, dass Validierung garnixmeh mit Anzeige und Eingabe zu tun hat.
Ein Datensatz prüft selbst, ob er Mist enthält und kennzeichnet sich entsprechend.
Ein beliebiges Gui - ob nun generisch oder individuell - testet einheitlich nurnoch auf "HasErrors", und haut dann die Bremse rein.
Dabei werden ungültige Zustände im gewissen Rahmen toleriert, also du kannst AnReise angeben, wenn in Abreise noch "1.1.1900" steht - aber ein Wechsel des Datensatzes in dem Zustand wird unterdrückt - stattdessen blinkern dich ggfs. die ErrorProvider an.
Das würde auch mit deinem Grid funzen, was ganz verschiedene Sachen anzeigen soll.

(Oder binnich jetzt echt zu doof, und schnall BrettVormKopp nicht, was du meinst?)

Ich denk übrigens immer mehr, unsere "Differenzen" (beachte die Afü-Striche ;)) rühren einfach daher, dass wir in verschiedenen Ligen spielen.
Hier zB. meldet sich auch einer aus deiner Liga zu Wort - ich denke, in deinem Sinne.

Aber ich denk auch, ihr aus der Oberliga verstoßt leicht gegens Yagni-Prinzip, wenn ihr meint, ein einfacher (und einfach zu vermittelnder) Ansatz müsse ausgeschlossen werden, weiler euch nicht erweiterbar auf mw. 200 Tabellen erscheint (was übrigens erst noch zu belegen wäre, aber ich kanns auch nicht widerlegen, weilich auf absehbare Zeit nicht aus meine 20-Tabellen-Liga herauskomme).

Ja - der Thread ist sowas von entgleist.
Ich frag mal die Mods, ob sie die Diskussion vlt. auslagern können, in einen eigenen Thread.
Vlt. mit dem Titel (inkl. Fragezeichen): "Architektonische Begrenztheit von ADO.Net?"

(Falls du Einwände dagegen hast, bitte PN, ok?)

ErfinderDesRades schrieb:

(Oder binnich jetzt echt zu doof, und schnall BrettVormKopp nicht, was du meinst?)

Bekloppt bestimmt nicht und Brett vorm Kopp ... ka, aber in dem Punkt reden wir wirklich aneinander vorbei.

Es geht hier nicht um Standard-Validierungen, wie Dinge ala IsDate oder IsNumeric (jetzt einfachst gehalten vom Beispiel her), sondern um Plausbilitätsprüfungen (vllt das bessere Wort als Validierung).

Die sind aus ihrer Natur her individuell je Entität unterschiedlich.

Beispiel damit es deutlicher wird: Ein User gibt einen Versicherungsvertrag ein den er bei seinem Kunden verkauft hat. Dazu gibt es noch die Beitragsverläufer ein und seine verdiente Provision. Hier haben wir einige Entitäten die erst zusammen einen gültigen Datensatz ergeben: Kunden/Personen (kein Vertrag ohne Kunde, eh klar ^^), Verträge, Vertragsbeiträge, Vertragsprovisionen ... klar ... aber dazu kommen noch Produktgeber (also in dem Falle die Versicherung) und Produkte an sich. Habe jetzt bestimmt noch was vergessen, aber ist ja jetzt nicht relevant.

Daraus ergeben sich erstmal jede Menge Plausibilitätsprüfungen:

- Jeder Vertrag muss als Angabe einen GÜLTIGEN Kunden und ein GÜLTIGES Produkt (und ein Produkt MUSS immer einen Produktgeber haben) beinhalten ... Kunden könnten z.B. als inaktiv oder verloren markiert sein ... das würde Auswertungen/Statistiken durcheinander werfen wenn aufeinmal inaktive oder verlorene Kunden Neuabschlüße zugeordnet bekommen oder Produkte sind abgelaufen (Z.B. Sonderaktionen können nur in einem bestimmten Zeitrahmen verkauft werden und danach sind sie nicht mehr gültig) und das würde wiederum die Datenlogik durcheinander wirbeln wenn nicht mehr gültige Produkte verkauft werden würden

- Jeder Vertrag braucht ein paar zwingende Pflichteingaben, wie z.B. Vertragsbeginn und Abschlußdatum ... aus letzten ergibt sich die Frage wie verhalten sich Vertragsbeginn zu Abschlußdatum zu einander, MUSS Vertragsbeginn immer nach Abschlußdatum liegen und wenn ja, dann muss das sicher gestellt sein

- Jeder Vertrag KANN Beiträge habe (eine MUSS-Lösung wäre auch denkbar). Wenn er Beiträge hat dann MÜSSEN ein paar Punkte sichergestellt sein: Beitragsbeginn kann nicht vor Vertragsbeginn liegen, Beitragsende kann auch nicht nach Vertragsende liegen, Beitagszahlweise muss zu Produktdetails passen (also monatliche Beiträge bei einem Produkt das per Produkl-Definition nur gegen Einmalzahlung abschliessbar sind dürfen nicht möglich sein)

... usw. und so fort

Jetzt klar worauf ich hinaus will? Du hast ja nicht nur die Technik dahinter sondern auch eine Programm- und Datenlogik dahinter.

Lässt du unkontrolliert zu das der Nutzer nicht aktive Kunden und/oder nicht gültige Produkte als Neuvertrag auswählt, hast Du sofort ein Problem wenn der sich seine Umsatzstatistik anguckt und ihm auffällt .... hoppla, Vertrag XYZ fehlt da. Der kotzt Dir vor die Füsse weil Dein Programm zu dumm ist richtig zu rechnen. Irgendwann bei der Fehlersuche kommst Du dann drauf ... Oops, inaktiver Kunde und/oder ungültiges Produkt ... kann ja gar nicht in der Umsatzstatistik angezeigt werden. Und jetzt wettert der User erst Recht los wieso er darauf bei der Eingabe nicht hingewiesen wurde ... sowas muss das Programm doch merken (und er hat auch Recht).

Sowie Du beim Programmieren Intellisense und Anzeige von Warnungen/Fehlern direkt bei der Code-Eingabe schätzt und nicht mehr missen willst und alles andere als rückständig und veraltert ansiehst (siehe SQL-Statements schreiben), so erwartet Dein User von Dir das er auf Fehleingaben hingewiesen wird ... auch auf die Fehleingaben die nicht technischer Natur sind (Text-Eingabe in Datumsfeld oder sowas) sondern und ganz besonders auf die logische Fehleingaben.

Für eine Datenbank ist eine logische Fehleingabe (also technisch alles korrekt, aber die Eingabe macht so keinen Sinn bzw. wird bei der restlichen Datenverarbeitung so nicht erwartet ... wie z.B. das ungültige Produkte verkauft werden oder inaktive Kunden Neuabschlüße machen können) genauso schlimm wie eine technische Fehleingabe (die aber eh nicht möglich ist).

Wie willst du so eine Logik in ein DataGridView das x00 Datensätze anzeigen kann und deren Bearbeitung zulässt da rein proggen?

Ich denk übrigens immer mehr, unsere "Differenzen" (beachte die Afü-Striche ;)) rühren einfach daher, dass wir in verschiedenen Ligen spielen.

Vom Sinn her hast Du vermutlich sehr Recht (siehe oben ^^), aber mir gefällt die Bezeichnung "unterschiedliche Ligen" nicht so sehr ... das hat so den negativen Beigeschmack von der eine ist in der "besseren/höheren" Liga und der andere in der "unteren/schlechteren" Liga. Das wird der Sache sicherlich nicht gerecht. Lass es uns so formulieren: Unsere Differenzen rühren daher das wir bei der Diskussion darum an völlig unterschiedliche Einsatzgebiete denken ... okay?

Hier zB. meldet sich auch einer aus deiner Liga zu Wort - ich denke, in deinem Sinne.

Habe nur den ersten Beitrag gelesen ... und ja, kann ich auf die Schnell geurteilt 100% sign drunter setzen.

Aber ich denk auch, ihr aus der Oberliga verstoßt leicht gegens Yagni-Prinzip, wenn ihr meint, ein einfacher (und einfach zu vermittelnder) Ansatz müsse ausgeschlossen werden, weiler euch nicht erweiterbar auf mw. 200 Tabellen erscheint (was übrigens erst noch zu belegen wäre, aber ich kanns auch nicht widerlegen, weilich auf absehbare Zeit nicht aus meine 20-Tabellen-Liga herauskomme).

Ich schliesse einfachere Ansätze für einfachere Aufgabenstellung absolut nicht aus. Für mich ist es nur einfacher gleich auf "Groß" zu arbeiten weil ich mich da nicht erst neu einarbeiten muss und es ja auch keine Nachteile gibt, eher den Vorteil das ich nie zu unflexibel angesetzt habe. Unsere Diskussion kam ja auch nur zu Stande weil Du Deinen Ansatz - so klang es wenigstens für mich - als einzig richtigen Ansatz dargestellt hattest und darauf zielte ich ab das das so nicht stimmt.

Für jemand der eine kleine Aufgabenstellung hat und sich neu in die Thematik einarbeiten muss, will ich gar nicht abstreiten das er mit Deiner vorgehensweise vermutlich besser fährt als sich das komplette Datenbankhandling inklusive SQL erstmal beizubringen um dann seine Anwendung die nur 2 Tables benötigt zu erstellen ... anderseits ... bei manchen Fragestellungen hier, fragt man sich doch ob das nicht der bessere Weg wäre (der TE ist damit nicht gemeint).

(Falls du Einwände dagegen hast, bitte PN, ok?)

Keine Einwände, aber denke irgendwo sind wir ja jetzt eh am Ende mit der Diskussion.

Gruß

Rainer