vb@rchiv
VB Classic
VB.NET
ADO.NET
VBA
C#
 Brandneu! sevEingabe v3.0 - Das Eingabecontrol der Superlative!  
 vb@rchiv Quick-Search: Suche startenErweiterte Suche starten   Impressum  | Datenschutz  | vb@rchiv CD Vol.6  | Shop Copyright ©2000-2024
 
zurück

 Sie sind aktuell nicht angemeldet.Funktionen: Einloggen  |  Neu registrieren  |  Suchen

ADO.NET / Datenbanken
Vorgehensweise beim Zugriff auf SQL Datenbanken... (Video-Tutorials auf MSDN) 
Autor: Schudi
Datum: 04.05.15 09:54
Ich habe mir bei MSDN die Videos von Beth Messi zum Thema SQL-Datenbanken angesehen:

https://msdn.microsoft.com/de-de/vstudio/bb643825.aspx
(How Do I: Create a Database?)

https://msdn.microsoft.com/de-de/vstudio/bb643826.aspx
(How Do I: Connect to a Database)

usw.

Dort wird der Server-Explorer benutzt, um die Datenbank zu definieren. Soweit erscheint mir das noch sinnvoll.

Für INSERT, UPDATE und DELETE werden dann Stored Procedures verwendet, obwohl das Programm ohne genauso funktioniert. Ich vermute dass der Sinn darin liegt, hier zusätzliche Bedingungen (wie des Setzen des Timestamps "modified" definieren zu können.

a) Ist meine Annahme richtig? Oder worin liegt der Sinn der Stored Procedures?

Später wird dann die Verbindung zur Datenbank über den Data Source Configuration Wizard hergestellt wodurch alle notwendigen "Tools" (DataSet, BindingSource, TableAdapter und BindingNavigator) direkt in das Projekt aufgenommen und eingestellt werden. Auch der Connection String wird in dem Video gespeichert.

b) Ist das wirklich sinnvoll oder sollte man den Zugriff (also z.B. den ConnectionString und die oben genannten "Tools") besser im Code selber definieren/schreiben um hier flexibler zu bleiben (und übersichtlicher)? Wie viel Logik sollte in der Datenbank und wie viel im Programm sein?

Noch später wird dann im Solution Explorer das xsd-file des Datasets bearbeitet. Genauer gesagt wird in den Properties des Tableadapters eingestellt, dass die Stored Procedures genutzt werden sollen. Besonders aufwändig finde ich, dass danach noch jeder Parameter der Stored Procedure (also jedes Feld in der Tabelle bzw. dem Statement) mit dem Datenfeld auf dem Form verbunden werden muss.

Für mich erscheint das sehr aufwändig vor Allem im Hinblick auf die spätere Wartung der Programme. Was ist, wenn mal einer Datenbank ein Feld hinzugefügt wird und diese in vielen Programmen genutzt wird? Da kann man doch schnell vergessen eines dieser Programme entsprechend anzupassen...

c) Ist die gezeigte Vorgehensweise sinnvoll? Oder sollte man auch hier lieber die Statements auf andere Weise im Programm "codieren"?

d) Sollte man vielleicht ganz auf die Stored Procedures verzichten und statt dessen die Zugriffe lieber über eine eigene Klasse (ist das richtig?) definieren? Könnte man in eine solche Klasse dann auch gleich eine Logikprüfung/Validierung der Daten mit aufnehmen? Im Prinzip also eine Klasse pro Tabelle in der Datenbank?

Sicherlich ist das ganze auch eine Glaubensfrage wie so vieles auf der Welt...

Es gibt zig Videos zu dem Thema und mal wird es so und dann wieder anders gezeigt. Letztlich möchte ich mir gar nicht erst etwas falsches angewöhnen...

Vielen Dank für das Lesen dieses langen Textes und Eure Hilfe im Voraus.
alle Nachrichten anzeigenGesamtübersicht  |  Zum Thema  |  Suchen

 ThemaViews  AutorDatum
Vorgehensweise beim Zugriff auf SQL Datenbanken... (Video-Tu...2.431Schudi04.05.15 09:54
Re: Vorgehensweise beim Zugriff auf SQL Datenbanken... (Vide...1.208Manfred X04.05.15 13:02

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

Funktionen:  Zum Thema  |  GesamtübersichtSuchen 

nach obenzurück
  
   

Copyright ©2000-2024 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