|
| |
VB.NET - Ein- und Umsteiger| Re: Tabelle in Access erweitern/DataGridView anzeigen | |  | | Autor: ErfinderDesRades | | Datum: 06.12.13 17:00 |
| Manfred X schrieb:
| Zitat: | |
Beim Entwurf einer DB-Anwendung muß ZUERST die Struktur der DB geklärt werden - incl. der dazu erforderlichen SQL-Abfragen. | |
Das sagtest du bereits, und die Realität (nämlich Stefans Thread-Eröffnung) hat dich ja bereits widerlegt, nämlich kaum ein Entwickler schafft es, von vornherein das Datenmodell so zu konzipieren, dasses nicht geändert werden muss, im Verlauf der Entwicklung.
| Zitat: | |
Deine "unkonventionelle"; Alternative führt deshalb nur zu Mehrarbeit. | |
Du hättest recht in solchen Fällen, wo obiges in der Praxis erreicht würde.
Realistisch gesehen hat man die Mehrarbeit aber schon ab der ersten Modell-Anpassung.
| Zitat: | |
Eine XML-Datei bietet nicht die notwendige Funktionalität für die Entwicklung und den Test einer DB-Anwendung. | |
naja - die gesamte Oberfläche kann man schon mal fertig machen, insbesondere auch komplexe Databindings im FormDesigner zurecht-konfigurieren.
Weiters kann man auch alle mögliche Datenverarbeitung bereits implementieren, insbesondere die CRUD-Funktionalität (Create, Read, Update, Delete) rauf und runter.
Das Austauschen des einfachen Datenzugriffs durch den komplexeren und mächtigeren auf die DB zugreifenden Layer kannst du auch als Optimierung nach Definition auffassen: Steigerung der Leistungsfähigkeit um den Preis höherer Komplexität und geringerer Flexiblität (DB-Zugriff hängt immer auch an System-Parametern - eine Xml kannst du immer mitliefern).
Und wie lauten die 3 Regeln zur Optimierung?
http://c2.com/cgi/wiki?RulesOfOptimization
1) Don't
2) Not yet
3) Profile first
Also so spät wie möglich, und nur, wenn wirklich nötig
Aber eiglich unnötiges Geschwätz - dich werde ich sicher nicht überzeugen.
Das muss Stefan wissen, ob er sich von Anfang an die DB ans Bein binden will, und dann immer wieder so Probleme haben wie jetzt, oder ob er das Zentrum der Datenverarbeitung - nämlich das typisierte Dataset - auch wirklich in die Mitte nehmen will, und von da ausgehen.
Weil das zentrale Datenmodell in einer DB-Client-Anwendung ist nicht die DB, sondern ist das typDataset: Daran wird gebunden, da hinein wird eingegeben, da wird rausgelöscht, und daraus werden Ergebnisse berechnet - der DataAcces-Layer soll hauptsächlich nix tun, als die Änderungsverfolgung auswerten, und die Änderungen mit der DB synchronisieren.
Und wie gesagt: Das entwickelt sich wesentlich leichter, wenn man zunächstmal den Primitiv-Data-Access nimmt.
(Rechtschreibfehler urheberrechtlich geschützt) | |
 | Sie sind nicht angemeldet!
Um auf diesen Beitrag zu antworten oder neue Beiträge schreiben zu können, müssen Sie sich zunächst anmelden.
 Einloggen | Neu registrieren |
 |
|
sevISDN 1.0 
Überwachung aller eingehender Anrufe!
Die DLL erkennt alle über die CAPI-Schnittstelle eingehenden Anrufe und teilt Ihnen sogar mit, aus welchem Ortsbereich der Anruf stammt. Weitere Highlights: Online-Rufident, Erkennung der Anrufbehandlung u.v.m. Weitere InfosTipp des Monats Neu! sevEingabe 3.0 
Einfach stark!
Ein einziges Eingabe-Control für alle benötigten Eingabetypen und -formate, inkl. Kalender-, Taschenrechner und Floskelfunktion, mehrspaltige ComboBox mit DB-Anbindung, ImageComboBox u.v.m. Weitere Infos
|
| |
|
Copyright ©2000-2025 vb@rchiv Dieter Otter
Alle Rechte vorbehalten.
Microsoft, Windows und Visual Basic sind entweder eingetragene Marken oder Marken der Microsoft Corporation in den USA und/oder anderen Ländern. Weitere auf dieser Homepage aufgeführten Produkt- und Firmennamen können geschützte Marken ihrer jeweiligen Inhaber sein.
Diese Seiten wurden optimiert für eine Bildschirmauflösung von mind. 1280x1024 Pixel
|
|
November 2025
Sie sind aktuell nicht angemeldet.
