Edit oder DBedit?

[plautzer]

Hi,

es ist zwar ne ziehmlich banale frage, aber ich würde gern mal wissen, was für edits und dbedits in verbindung mit datenbanken (Interbase) spricht.
Ich weiß das dbedits speziell für den Gebrauch mit datenbanken gedacht sind, gibt es aber nachteile und wären so edits geeigneter?

Thx,

plautzer

[Hansa]

Zitat von plautzer:

es ist zwar ne ziehmlich banale frage...

Diese Frage ist ganz und gar nicht banal. 8) Bei größeren Sachen sind DBedits ziemlich ungeeignet, weil zu unflexibel.

[urs.liska]

Der Nachteil an Edits ist, dass Du alles selber machen musst (Daten einlesen, prüfen, anzeigen).
Der Nachteil an DBEdits ist, dass sie alles für Dich machen (Du also in bestimmten Fällen keinen Einfluss mehr hast).

Es kommt auf den Zusammenhang an...

[Hansa]

Stop ! Es geht nur um DBEdits ? Na ja, die kann man noch verwenden, aber DBGrid, DBChart usw. nicht wirklich. Dann lieber selber Arbeit reinstecken. Mit einem OOP-Ansatz wird das dann auch was gutes, ohne die eingebauten Nachteile.

[Jelly]

Vorteil von DBEdit liegt auf der Hand. 2 Properties ausfüllen, schon hast du die korrekten Daten drin, kannst diese problemlos ändern usw. Nachteil ist allerdings, sobald du was in ein Editfeld tippst, dieser Datensatz für andere User gesperrt wird, und zwar solange du ein Post oder Cancel aufrufst. Handelt es sich um viele Datenbankfelder, oder du vergisst das Post und gehst in die Mittagspause, kann der Datensatz unter Umsatänden sehr lange gesperrt sein. In kleinen Netzwerken sicherlich nicht dramatisch. Greifen aber viele User auf die DB zu, sollte schon ein Gedanke an die Datensatzsperre verschwendet werden.

Gruß,
Tom

[plautzer]

Also sind dbedits klar zu empfehlen.
Mein Programm soll vorerst sowieso nicht mit Netzwerk laufen.
Mit dbgrids, dbcomboboxen hatte ich schon mal probleme, also nutze ich da lieber auf stinggrid, CB ua. Ich war mir jetzt bloß noch im unklaren, ob dbedits besser/ eigneter als edits wären.

Ich danke,

Plautzer

[Bernhard Geyer]

Zitat von plautzer:

Also sind dbedits klar zu empfehlen.

Würde ich nicht sagen.

Um schnelle Ergebnisse zu bekommen oder für Prototypen - Klares Ja.
Für komplexere Programme sind datenbankgebundene Grundsätzlich mit Vorsicht zu verwenden. Vor allem wenn man sein Programm über eine mehrschichtige Architektur betreibt bzw. einfach alle in intelligentere Objekte verpackt ist eh Schluß mit DB-Bindung von Controls.

[urs.liska]

@Bernhard Geyer
@Hansa

Verstehe ich das richtig: Ihr (das sind in diesem Fall die Leute mit Erfahrung bei größeren DB-Projekten) empfehlt für eine komplexere Datenbankanwendung folgendes Vorgehen:
- Formular mit normalen Steuerelementen aufbauen.
- Eine Klasse für den Datensatz entwickeln.
- Den Datensatz aus der DB in das Datensatz-Objekt einlesen und von diesem anzeigen lassen.
(- Transaktion beenden)
- Daten bearbeiten, nur im Formular
- Daten im Kontext einer neuen Transaktion durch das Datensatz-Objekt in die DB schreiben lassen und dabei, evtl. in der Zwischenzeit durch andere Benutzer entstandene, Konflikte auflösen

Ich stehe gerade vor Beginn meines ersten „größeren“ DB-Projekts und wage noch nicht, mich für einen Ansatz zu entscheiden...
(größer bedeutet: ca. 40 Tabellen (Firebird), davon viele Nachschlage- und Interselektionstabellen. In den Hauptformularen der Anwendung werden sicher jeweils die Hälfte bis zwei Drittel der Tabellen verwendet).

Danke für die Meinung
Urs

[Sharky]

Hai Urs,

auch ich verwende nach möglichkeit keine Visuellen DB-Komponenten mehr. Es ist zwar mehr arbeit aber dafür habe ich dann auch volle Kontrolle über alles was passiert. Meiner Meinung nach rechtfertig dies den Aufwand.

[urs.liska]

Und wie sieht es mit Detaildatensätzen aus?
Eine array-eigenschaft im hauptdatensatz, die wiederum objekte für die detaildatensätze enthält?
Oder gar eine Collection?

Und Nachschlagefelder?
Normale Combobox und bei OnDropDown eine hintergrundquery?

Urs