Was muss man beachten bei eine DB Anwenung in Netz?

[Karstadt]

Hallo. Programmieren gerade eine DB Anwendung für mehr als 20 Benutzer.

Server-> Clientanwendung.

Was soll ich dabei besonders beauchten?

Select Anfragen so detaliert wie möglich
Nach jeden Post sofort ein Refresh

-> Wie kann ich die Aktualliesierung aller Tabellen am schlausten durchfürhen?

Danke

[Hansa]

Zitat:

Zitat von Karstadt

-> Wie kann ich die Aktualliesierung aller Tabellen am schlausten durchfürhen?

1. Mit stored Procedures, die eventuell sofort benötigte (auch berechnete) Felder gleich beim Insert/Update zurückliefern. 2. Über Update/Insert die Datenbank entscheiden lassen. Entlastet eigenen Source und Logik. Allgemein gilt: möglichst viel parametrisieren und nicht so was im Klartext ins eigene Programm schreiben : 'INSERT INTO TABLE VALUE ...'. Sehe aber gerade : MySql ? Für 20 Benutzer ? :shock: Ist das Dein Ernst ? :mrgreen:

[shmia]

Das Wichtigste ist die Datenbankmodellierung.
Also alle Tabellen benötigen einen Primärschlüssel und sind
mindestens in der 3. Normalform.
http://de.wikipedia.org/wiki/Normali...28Datenbank%29

Jeder Fremdschlüssel benötigt einen Index, da dieser für JOINs herangezogen wird.

Bei wichtigen Tabellen sollte man zusätzlich das Datum+Uhrzeit in einem TDateTime Feld speichern.
Zusätzlich sollte man auch den Computernamen in einem VARCHAR(15) Feld speichern.
Damit lässt sich später nachvollziehen, wer wann was "versaubeutelt" hat.

[Sharky]

Zitat:

Zitat von Hansa

... Sehe aber gerade : MySql ? Für 20 Benutzer ? :shock: Ist das Dein Ernst ? :mrgreen:

Und was würdes Du nehmen? Und Warum?

[mquadrat]

3. Normalform macht nicht immer Sinn. Oft ist es wesentlich schneller mit redundanten Daten zu arbeiten.

[Karstadt]

Ich arbeite mit eine MYDAC Componente entwicketl extra für MQSQL.

So gehe ich vor. MyTyble = SELECT * FROM XYZ WHERE XYZBAZ=3. Wenn ich ein DS einfügen will gehe ich über MYTABLE.APPEND, EDIT, POST, DELETE. Das ist für mich viel einfacher und übersichtlicher.

[Karstadt]

Mit stored Procedures arbeiten? Wie geht das bei MYSQL 4.1? Ist das überhaupt möglich?

[dfried]

Zitat:

Zitat von Karstadt

Mit stored Procedures arbeiten? Wie geht das bei MYSQL 4.1? Ist das überhaupt möglich?

Nö, StoredProcs kann MySQL erst ab Version 5!

[alzaimar]

Ihr solltet Euch von der klassischen 2-Schichten Architektur verabschieden, also Grid anzeigen und den User durchscrollen lassen. Bei 20 Anwendern geht es zwar gerade noch (wenn die Tabellen nicht zu lang sind), aber das ist eigentlich keine Art.

Der Anwender muss wissen, was er sehen will. Bei niedriger Bandbreite und schmalbrüstigen Mainframes baut man eine Suchmaske und zeigt den gefundenen Datensatz an. Heutzutage könnte man so 10-1000 Records saugen und die in einem Grid darstellen, z.B. eine Auftragsübersicht (machen wir gerade) o.ä. Wir haben das bei der Auftragsübersicht so gelöst, das beim Aufruf nur die heutigen Aufträge angezeigt werden. Ist gerade ein Kundensatz geladen, werden die heutigen Aufträge dieses Kunden angezeigt.
Über Filtereinstellungen kann man aber beliebige andere Queries ausführen. Wir deckeln die dann jedoch über ein 'SELECT TOP 1000...' o.ä. Wichtig ist außerdem, das man einen maximalen Timout einstellt, sodaß der :twisted: Anwender durch Auswahl von blödsinnigen Filterkriterien das System nicht zum Stehen bringt ("select * from Universe")

---

Ich finde es absolut zweit- wenn nicht gar drittrangig, ob man stored procedures nimmt, oder seine SQL-Befehle im Klartext im Programm konstruiert, oder nicht. Das hängt IMMER vom Einsatzgebiet ab und hat imho nix mit Multi-Tier zu tun.

Beispiel gegen Stored Procedures: Die Anwendung wird eventuell auf eine andere DB portiert. Oder MYSQL < 5.0, FlashFiler etc.
Beispiel für SQL-Befehle im Klartext: Die Anwendung basiert auf Metadaten. Die Objekte/Entities sind also gar nicht 1:1 in der DB abgebildet.

Aber, wenn ich mich auf eine DB eingeschossen habe (ich verwende MSSQL), dann habe ich mit Stored Procedures die besten Erfahrungen gemacht. Ich verwende die Mittelschicht nur, um die Verbindungen zur DB zu bündeln, und um eventuell einen Cache für bestimmte Daten einzurichten.

Die Geschäftslogik wird weitestgehend in den Stored Procedures abgebildet. Warum? Weil man es so auch im laufenden Betrieb ändern kann, ohne die Mittelschicht runterzufahren. Allen Unkenrufen zum Trotz habe ich damit bisher null Probleme gehabt. Selbst komplizierteste Geschäftsregeln lassen sich über geschickte SQL-Befehle oft verblüffend einfach realisieren. Wenn man ohne CURSOR arbeitet (was man fast immer kann), hat man absolut robuste und verdammich schnelle Lösungen, die mit klassischen Mitteln in der Mittelschicht ein vielfaches (Faktor 1000) an Zeit kosten.

Das ich ALLES über Stored Procedures und Updateable Views abbilde, hat aber nix mit dem Multitier zu tun, sondern mit meiner Prämisse, Aufgaben an Spezialisten zu deligieren. Und der DB-Server ist DER Spezialist für Daten.

Grundsätzlich würde ich nicht mit MYSQL arbeiten. Die DB ist alles andere als umsonst (wenn ihr kommerziell damit arbeitet) und wird erst langsam ein richtiges DBMS. Firebird oder eben MSSQL (in der Express-Version absolut umsonst), PostGreSQL etc. sind weitaus bessere Vertreter einer DB, stabil, ausgereift.

Was ich bei MYSQL so grauenvoll finde ist, das man bei einem Servercrash doch Angst um die Daten haben muss (Stromausfall bei einem INSERT). Das passiert garantiert NIE bei MSSQL (außer, die Platte ist hinüber).

Alter Schwede, kann man darüber viel schreiben.

[Hansa]

Zitat:

Zitat von Sharky

Und was würdes Du nehmen? Und Warum?

Ich würde das nehmen, was die nötigen Werkzeuge (und zwar auch alle !) mitbringt, inkl. verfügbarer Zugriffskomponenten. Und zwar nicht als Beta-Version. Dazu gehören elementare Dinge wie : Trigger bzw. stored Procedures. Bei MySql wurden die angeblich in Version 5 neu eingeführt. Vielleicht gehts ja, oder auch nicht. :mrgreen: Kommt jedenfalls sehr sehr spät für bereits existierende DB.
Und auch Transaktionen. Es gibt DBs, die das zumindest bei kleineren Versionen ausgespart haben, z.B. ADS. Das Kosten/Nutzen-Verhältnis muß natürlich auch stimmen. Ich bin deshalb bei IB/FB gelandet. Denn : Ora, MS-SQL und auch Mysql (!) sind vom Preis her nach oben offen ! Wer zu schnell denkt : was solls ? Transaktionen brauche ich nicht, oder mehr als 5 User auch nicht und da reicht die Light Version, der wird sich bei dem irgendwann zwangsläufigen 6. User schwarz ärgern. Dann fällt die Wahl zwischen Pest und Cholera : Programm komplett umschreiben, bestehende Daten in andere DB konvertieren. Neue DB-Komponenten kaufen und verstehen usw. Oder man tritt gleich den gang nach Canossa an : "Sie brauchen eine größere DB-Version, sonst geht das nicht" Und die kostet XXXX EUR. Dann kommt zwangsläufig :"WAAS ?? Wegen des einen bereits vorhandenen Zusatzrechners im Zweitbüro um die Ecke soll ich soviel bezahlen für IHR Programm ???". Nene, ohne mich. :mrgreen:

Zum Hauptthema : Shmia hat ja schon einen Trick verraten : Timestamp immer schön festhalten, wer wann was gemacht hat. Womit wir bei Triggern wären : pro Table habe ich z.B. 2. Einen BI und einen AU. Der Before Insert ermittelt die ID und speichert, wer den Datensatz und auch wann angelegt hat. Der After Update Trigger geht entsprechend. Das hat jede Table schon mal standardmäßig, läßt sich aber auch auf die Spitze treiben. Und wie Alzaimer, habe auch ich gemerkt, daß das Ändern am einfachsten mit stored Procedures zu regeln ist. Allerdings ohne SQL im Source, sondern lediglich durch setzen von Parametern. Alleine schon, wie bereits gesagt, um beim Einfügen gleich Rückgabewerte zur Weiterverarbeitung zu erhalten. Gerade im Netzwerk ist das sehr wichtig ! Wie man das alles nun ohne Trigger / SPs / Transaktionen überhaupt umsetzen kann ? Wohl so ähnlich wie beim Eichhörnchen.

[alzaimar]

@Hansa: MS-SQL ist in der Express-Version absolut umsonst, kostenfrei, lau. Imho das Beste, was man für das Geld (nämlich 0,00 Euro) bekommen kann. Ich bin kein Fan der Redmonder Frickelbude, aber MS-SQL ist nun mal eines der besten DB. Und wenn man das umsonst bekommen kann, dann sollte man es doch einsetzen.

Ich weiss nicht, wie sich FB/IB auf einem Multiprozessorsystem verhält, das ist bei Express-MSSQL das Einzige, was hier nicht so schön ist: MP wird einfach nicht unterstützt. Schade, aber man kann nicht Alles für Null haben.

Ich kann mir aber kein Urteil über andere DB (FB/IB, PostGreSQL) erlauben, sondern nur das wiedergeben, was ich gehört habe: Allesamt sind wirklich gut.

Nur MySQL ist doch Frickelkram. Und wenn ich mir überlege, wie schwierig das ist, mit Delphi auf die Teile zuzugreifen... Dann doch lieber MSSQL+ADO, oder FBU/IB mit den IBObjects (heisst doch so, oder?)

[Sharky]

Zitat:

Zitat von Hansa

... Vielleicht gehts ja, oder auch nicht. :mrgreen:

Hai Hansa,
Auch wenn Du immer gerne den MrGreen verwendest. Weisst Du auch von was Du redest?

Zitat:

...Kommt jedenfalls sehr sehr spät für bereits existierende DB. ...

Für ein OS Projekt wohl nicht.

Zitat:

Und auch Transaktionen.

Wo ist denn dein Problem? Es wird bei mySQL unterstützt.

Zitat:

Das Kosten/Nutzen-Verhältnis muß natürlich auch stimmen.

Und gerade das ist doch bei mySQL mehr als gut.

Zitat:

Denn : Ora, MS-SQL und auch Mysql (!) sind vom Preis her nach oben offen !

So, dafür möchte ich jetzt aber eine Erklärung! Wo sind diese DBMS "nach oben offen"?
Weisst Du eigentlich etwas von diesen Systemen?

Zitat:

Wer zu schnell denkt ...

Man sollte überhaupt denken.

Sein mir nicht böse; aber Du lebst nur in deiner kleinen DB-Welt die Du verwendest. Alles andere versuchst Du immer wieder schlecht zu reden ohne wirklich Ahnung davon zu haben.

[SirThornberry]

@Sharky: Wenn du findest das die ganzen Behauptungen falsch sind, warum stellst du diese dann nicht richtig? Auch für einen Mod gilt: "sachlich bleiben" und nicht einfach von den gefühlen leiten lassen und Kontra geben und dabei genau so unsachlich sein wie du es anderen vorwirfst :wink:

Ich denke wir sollten hier sachlich zum Thema zurück kehren und nicht irgendwelche Behauptungen nur in den Raum stellen ohne diese zu beweisen.

[MagicAndre1981]

Zitat:

Zitat von Sharky

Zitat:

Und auch Transaktionen.

Wo ist denn dein Problem? Es wird bei mySQL unterstützt.

Aber nur mit InnoDB als Type, nicht aber bei MyISAM .

[Union]

Mal wieder zurück zum Thema ;) - Was muss man beachten...
Abhängig von der Art der Bearbeitung ist daran zu denken, wie Transaktionen und Sperren eingesetzt werden. Handelt es sich bei dem Projekt um viele eigenständige Datensätze (wie z.B. ein Protokoll) oder ist die Struktur mehr hierarchisch aufgebaut (wie z.B. Aufträge, Positionen, Lieferungen).

Das Datenbankdesign ist dabei wirklich immens wichtig. Man muss einen Mittelweg finden zwischen der extremen Normalform (keine Redundanz) und entsprechender Performance. Bei der Normalisierung wird nämlcih oft vergessen, dass manche DB nur eine begrenzte JOIN-Verschaltelungstiefe unterstützen. Und was nützt eine DB die insgesamt wenig Felder, geringen Platzbedarf hat und der 4. NF entspricht, wenn Du permanent 6-fach verschachtelete JOIN deswegen benötigst und ab der 7. sagt Die DB "ist nicht". Oder entsprechend das Absacken der Performance.

Soll im Projekt vorgangsorientiert oder eher visuell (QBE) gearbeitet werden?

Generell solltest Du, wenn möglich, Transaktionen einsetzen. Dabei ist aber auch wieder die Dauer der Transaktionen zu beachten. Wenn ein Benutzer einen Auftrag 10 Minuten lang bearbeitet, dürfen durch die Transaktion nur die direkt verarbeiteten Daten geschützte werden. Absolut fatal ist, wenn man z.B. eine zentrale Tabelle mit lfd. Nummern hat, die dann ebenfalls geblockt bleibt. Also Transaktionen isolieren und wenn möglich nur für kurze, zusammenhängende Update-Operationen.

Views und Stored Procedures ersparen Dir viel Arbeit und Redundanz im Projekt. Allerdings ist da die Frage, ob Du für immer by MySQL bleiben willst, denn meistens setzen unterschiedliche DB auch andere SQL-Dialekte für ihre Scripts ein, die nicht zueinander kompatibel sind. Und leider kommt immer irgendwann der Zeitpunkt, wo man aus Bequemlichkeit oder weil es funktional momentan keine andere Lösung zu geben scheint, proprietäre Syntax einsetzt.

Viel Spass...

[Sharky]

Zitat:

Zitat von SirThornberry

... Auch für einen Mod gilt: "sachlich bleiben" und nicht einfach von den gefühlen leiten lassen ...

Hai Sir,

Du hast recht und ich entschuldige mich.

Aber auch für einen Mod gilt: Er ist ein "Mensch" und muss gelegentlich sagen was er denkt ohne seine Gefühle im Zaum zu halten ;-)

Ich hoffe das keiner aus dem Thread böse auf mich ist :oops:

[Hansa]

Was heißt "Deine kleine DB-Welt" ? Oder wer war gemeint ? Meine DB-Welt ist allerdings nicht gerade klein. Einige dürften noch wissen, was BS2000 ist, oder eine VAX. Diese Dinger hielten mich allerdings nicht davon ab, ein PC-basierendes DB-Netzwerkprogramm (Novell) bereits 1989 im Einsatz zu haben. Und nicht nur eines ! Die Nachfolger davon laufen heute noch, daran konnten weder Euro noch M$ mit ME etwas ändern. :mrgreen: <- für Sharky :mrgreen: Die Hauptfrage geht ja um Netzwerk. Und da gibt es für mich eine einzige Ausnahme, wo man kein Netzwerk braucht : ein einzelner alleine stehender Rechner, wodrauf 1 Programm alleine läuft. Ab 2 gehts bereits los. Egal ob 10 oder 2000 User. Entweder das Programm kann das, oder eben nicht. Beschränkung auf 5 User kann ich jedenfalls nicht gebrauchen. Auch keine sonstigen Einschränkungen kleinerer Versionen, wie auf Transactions zu verzichten (bezog sich auf ADS) oder eben stored Procedures (für ältere MySQl). Wer eben meint,er wisse alles besser und schlägt solcherlei Bedenken in den Wind, tja. Ansonsten ist hier außer Shmias, Alzaimers und meiner Tips leider nichts zum Thema zu finden. Und bei dem Timestamp hakts nun auch schon wegen fehlendem Trigger für MySQl 4. Der Fragesteller wird sich wohl sowieso noch wundern, was im Netzwerk alles an Problematik auftauchen kann ! Und Alzaimer : MS-SQL und Interbase lagen bei der Auswahl von der Leistung her ziemlich gleichauf. Über Interbase waren aber viel mehr Infos zu haben und Firebird ist auch ein Argument wegen Herstellerunabhängigkeit, Leistung und Kosten. Wobei aber selbst eine Borland-IB-Arbeitsplatz Lizenz für 69 $ nicht sonderlich ins Gewicht fällt.

[Union]

@Hansa

Wer setzt heute noch DEC Hardware ein ;)

Und noch eine Frage (nix generelles gegen kostenlose Soft): Wer supported FB - und wenn, tut er das auch kostenlos? Wie sind da die Reaktionszeiten? Und zwar vertraglich mit SLA.

Eine Entscheidung bzgl. der DB sollte eigentlich auf Grund diverser Entscheidungen getroffen werden, i.e.:

- Budget
- Stabilität
- Support
- Reaktionszeit Support
- Leistungsumfang
- Kompatibilität

Und nicht unbedingt "Ich setze das ein und deshalb ist das gut". Die o.g. Argumente sollte man auch des öfteren für sich prüfen und dann erneut entscheiden, was für die Anwender und einen selbst am besten ist. Ich z.B. kann mit meinen momentanen Kunden keine kostenlose DB einsetzen, da diese dies ablehnen. Und so finden sich immer wieder neue Gründe, die man alle in Betracht ziehen sollte.

[Jelly]

Also ich muss Hansa zumindest in einigen Punkten Recht, was MySQL betrifft. Im profesionnellen Bereich würd ich die Finger von lassen.

Zitat:

Zitat von Sharky

Zitat:

Und auch Transaktionen.

Wo ist denn dein Problem? Es wird bei mySQL unterstützt.

Allerdings nur beim InnoDB Tabellentyp. Da leidet dann jedoch ganz gewaltig die Performance.

Zitat:

Zitat von Sharky

Zitat:

Das Kosten/Nutzen-Verhältnis muß natürlich auch stimmen.

Und gerade das ist doch bei mySQL mehr als gut.

Bei Firebird oder MSSQL Express ist er besser: nämlich umsonst. MySQL im kommerziellen Bereich kostet auch sein Geld, wenn auch nicht soviel wie ein vollwertiger MSSQL Server, aber das wär ja echt dir Krönung.

Zitat:

Zitat von Sharky

Zitat:

Denn : Ora, MS-SQL und auch Mysql (!) sind vom Preis her nach oben offen !

So, dafür möchte ich jetzt aber eine Erklärung! Wo sind diese DBMS "nach oben offen"?

Für Ora und MySQL leg ich meine Hand nicht ins Feuer, aber ich kann mir vorstellen dass zumindest bei Ora ähnliche Bedingungen herrschen wie bei MSSQL. Den Server gibts in mehreren Varianten (Express: umsonst, Standard: erschwinglich, und Enterprise: da wirds teuer). Arbeitet man in Clustern ist die Enterprise Version ein Muss, aber das ist ein unfairer Vergleich zu MySQL. Pro Client fallen dann auch noch Kosten an, denn bei einer Serverlizenz sind default mässig nur 5 Clientlizenzen dabei. Ich denk mal, das ist mit (nach oben offen gemeint). Setze ich einen 2 SQL Server ein (zur Spiegelung oder sonstwas), fallen wieder kosten an. Und bei richtig grossen Systemen wird das dann sehr schnell teuer. Aber leider auch nicht umgänglich, denn da haben MySQL und auch Firebird längst die Segel gestreckt.

Letztendlich muss jeder selbst entscheiden, welches DBS für sich das Richtige ist. Es ist imho ein unfairer Vergleich, Marktführer wie MSSQL oder Orakel mit MySQL oder Firebird zu vergleichen, denn erst genannte sind ja nicht nur reine Datenschreiber, sondern können darüber hinaus noch viel mehr. (XML Export, Mailing, Replikation u.v.m.)

[Karstadt]

Es ist doch sinnvoll, dass nach jeden Post oder delete das Refresh folgt. Oder?

[Karstadt]

Was muss ich in diesen Fall tun.


Die anwendung ist "fertig". Wird seit Monaten benutz. Nun sehe das ich einen Bestimten String Feld in eine bestimmte Tabelle garnicht brauche. Soll ich diesen beim nächten Update entfernen (was nicht ungefährlich ist) oder macht das nichts aus?

-Gleicher Fall bei 10 Felder in 30 Tabellen (insgesamt 10 Felder)

[mquadrat]

Na das hängt von deinem Programm ab, ob du das entfernen kannst. Nimm es doch einfach in deiner Testdatenbank raus, dann wirst du merken, ob das ne gute Idee war oder nicht ;)

[Thanatos81]

Und teste, dass dann auch mit allen Versionen die noch bei Anwendern im Einsatz sein könnten, sonst klingelt dir nachher das Telefon mit der Ansage "Wir haben gar nix gemacht und nix geht mehr." ;-)

[alzaimar]

Ein Tipp:
Sämtliche Zugriffe vom Client/Mittelschicht an die DB laufen über Views. Die den Views zugrunde liegende Struktur (Tabellen- und Feldnamen, die konkreten Datentypen etc.) sind für die Mittelschicht absolut unsichtbar. Somit kannst du die Tabellen verändern, wie Du lustig bist.

Schreibzugriffe erfolgen über "Updateable Views" (Standard SQL), oder über Stored Procedures (mein Favorit).

Updateable Views sind einfacher zu programmieren, aber ich mag Trigger nicht (weil man vergisst, das da welche sind :oops: ). Ich verwende lieber so etwas:

SQL-Code:

Create Procedure Customer_Modify 
  @Action Char (1), /* 'I' - Insert, 'D' - Delete, 'U' - Update, 'R' - Remove */
  @Name VarChar (20),
  @Vorname VarChar (20),
...
  @CustomerID int output
as
  If @Action = 'I' begin -- 'Insert' fügt einen neuen Kundendatensatz ein und liefert die ID
    /* Code für ein BEFORE INSERT Trigger */
    Insert into Customer (Name, Vorname, Valid) Values (@Name, @Vorname, 1)
    select @CustomerID = @@Identity /* Die Spalte 'CustomerID' ist ein AutoInc, so bekommt man den unter MSSQL */
    /* Code für ein AFTER INSERT Trigger */
  End
  If @Action = 'D' begin /* 'Delete' soll den Datensatz nicht löschen, sondern z.B. nur als 'ungültig' markieren */
    /* Code für einen ON BEFORE UPDATE (Valid) Trigger */
    Update Customer set Valid = 0 Where CustomerID = @CustomerID
    /* Code für einen ON AFTER UPDATE (Valid) Trigger */
  End
  If @Action = 'U' begin /* 'Update' modifiziert die Kundentabelle */
    /* Code für einen ON BEFORE UPDATE Trigger */
    Update Customer Set Name = @Name, Vorname = @Vorname Where CustomerID = @CustomerID
    /* Code für einen ON AFTER UPDATE Trigger */
  End
  If @Action = 'R' begin /* 'Remove' entfernt einen Kundendatensatz inklusive der Details */
    /* Code für einen ON BEFORE DELETE Trigger */
    Delete From CustomerRelations Where CustomerID = @CustomerID
    Delete From Customer Where CustomerID = @CustomerID
  End
/* Hier vielleicht noch Code, der immer ausgeführt werden soll, wenn sich was am Kunden geändert hat */

Ich habe somit die vollständige Kontrolle, was bei welchen Datenmodifikation geschehen soll. Früher hatte ich vier Stored Procedures ('Customer_Insert', 'Customer_Delete' etc.), aber das müllt die SP-Liste nur zu.

Damit habe ich die besten Resultate in der kürzesten Zeit erzielt. Nachträgliche Änderungen am Verhalten (z.B. Einbau eines Logfiles bei Änderungen am Kundenstamm) sind so ohne Modifikation an der Anwendung selbst online möglich, d.h. ohne das die Anwendung selbst gestoppt werden muss.

Ich find's so am einfachsten: Alles, was den Customer betrifft, findet sich an einer zentralen Stelle. :mrgreen:

[webcss]

Noch ein kleiner Tip bezüglich Normalisierung:

Ich verwende Firebird für eine Auftragsbearbeitung. Dort habe ich z.B. für Artikel ein Feld 'Einheit'
für dieses habe ich eine Domain erstellt vom Typ smallint.
In der Domainbeschreibung hinterlege ich die Einheiten in Key=Value Form, e.g. 0=<unbekannt>, 1=Stk usw.
Wenn das Programm startet bzw. sich ein Benutzer anmeldet, liest mein Program diese Beschreibung in ein TStrings-Liste, somit ist das visuelle Update seitens des Anwenders gewährleistet.
Abfragen laufen über ViEWS, wobei die Werte mittels case construkt ersetzt werden (nicht unbedingt notwendig, da Feldwert=ItemIndex = Klartext!).

Delphi-Quellcode:

procedure TdmMain.InitComboboxes(const DomainName: string; List: TStrings);
const
   sql = 'select RDB$DESCRIPTION from RDB$FIELDS where RDB$FIELD_NAME = %s';
var
   i : integer;
begin
   List.Clear;
   try
      query.SQL.Text := Format(sql, [QuotedStr(DomainName)]);
      query.open;
      List.Text := query.Fields.AsString[0];
   finally
      query.close(etmCommit);
   end;
   for i := 0 to pred(List.Count) do
      List.Strings[i] := List.Values[List.Names[i]];
end;

Somit schlage ich zwei oder mehr Fliegen mit einer klappe:
Vorteile:
1. Keine weitere Tabelle mit dazugehörigem Index nötig (DB-Größe und Verwaltungsaufwand minimiert)
2. weniger joins in Abfragen
3. Trotzdem keine Redundanz, da der Benutzer keine unsinnigen Werte eingeben kann
4. kleine Feldgröße (smallint vs. varchar)
5. Datenänderungen finden in der DB statt, kein erneutes kompilieren der Clientsoftware notwendig
6. Auf Clientseite bleiben derartige Wertvorgaben trotzdem editierbar, wie in einer Tabelle

Nachteile:
1. Durch Substitution der Feldwerte mit Klartext in Abfragen größe Bandbreite bei Übertragung, wie bei VarChar-Feldern halt üblich. Naja, geht halt nicht anders :wink:
2. Nur für kleine Lookuplisten mit wenigen Werten sinnvoll umsetzbar
3. man muß Änderungen immer an mindestens zwei Stellen einpflegen, Domain Description und case-Construkte, aber hey, besser als etwa das Clientprogramm anzupassen und neu zu kompilieren und auf etlichen Clients neu aufzusetzen, oder?

[alzaimar]

Na, da würde ich aber Lookuplisten implementieren, dann musst Du gar nichts mehr im Code ändern. Es gibt viele Ansätze, meiner ist zwar DB-technisch nicht astrein, aber imho völlig ausreichend:
Ich habe zwei Listen: LookupLists und LookupListItems
Die LookupLists haben zwei Spalten:
LkID (AutoInc) und LkName. Dort stehen die Lookuplistenbeschreibungen drin, z.B:

• 1 Anrede
  2 Status
  3 Einheiten

Die LookupListItems besitzen drei Spalten
LiID (AutoInc), lkID und liName. Dort stehen die Ausprägungen drinm z.B.:

• 1 1 Herr
  2 1 Frau
  3 1 Dr.
  4 1 Herr Prof. Dr.
  5 2 OK
  6 2 Fehler
  7 2 Ungültig
  8 3 m
  9 3 Stk
  ...

Die Tabelle 'Namen' hat dann Anstelle der Anrede einen int-Wert, wobei 1 für 'Herr', 2 für 'Frau' etc. steht.
Wenn ich die Tabelle 'Namen' nun im Klartext ausgeben will (innerhalb einer view), dann brauch ich kein CASE, sondern nur ein Join über die Spalten 'NameAnrede' und 'liID'.

Die Eingaben kann ich bequem über Lookupcomboboxen machen, wobei das Dataset eben meine LookupListItems gefiltert nach der 'lkID' sind, bei der Anrede eben die '1'.

Vorteil: Nix Codeänderung, nur editieren/erweitern der Lookuplisten und deren Items. Damit ist die Übersetzung in andere Sprachen kein Problem.

[mquadrat]

Wir arbeiten gar nicht mit den DB Komponenten, alles wird in "eigene" Klassen gefüttert. Jede Klasse kennt nun wieder die SQL Anweisungen um sich zu persistieren. Der Vorteil ist, dass man sogar hingehen könnte und die Anwendung auftrennen könnte, so dass sie ihre Daten z.B. aus nem Webservice und nicht aus der DB bezieht, indem man einfach die Persistenzmethoden überschreibt.

[alzaimar]

Och, nö. Die Ausprägung einzelner Merkmale ('Anrede', 'Status' etc.) wird dann auch über die Lookuplisten repräsentiert. Ob das nun nachher Objekte werden, oder TDatasets, ist irrelevant. Eingegeben werden müssen die Werte ja sowieso irgendwann, und da ist mir eine Lookup-Combo (egal ob datensensitiv oder nicht) doch lieber.

Dessenungeachtet ist die objektorientierte Abbildung von Daten performancetechnisch ein Disaster, da die schöne Datenmengenwelt verlassen wird, und mit einzelnen Objekten rumhantiert wird. Das ist bei der Bearbeitung einzelner 'Objekte' noch ok, aber auf 'Objektlisten' würde ich das nicht aufweiten. Der Unterschied liegt bei ca. 400% (und mehr).

Das ist die Crux mit den Mittelschichten: Entweder schön objektorientiert (wirklich schön), dafür lahm, oder den DB-Server ausreizen, dafür etwas klassisch. Irgendwo gibt es einen Schnittpunkt zwischen Übersichtlichkeit und Performance. Wenn das Projekt zu komplex wird, wird man auf Performance eventuell verzichten. Denn dann muss die Implementierung sauber und wartbar sein.

[mquadrat]

Jep, Performance verliert man definitiv. Problematisch ist das aber nur bei Batch-Vorgängen, die mit vielen Datensätzen arbeiten. Dort kommen dann auch Stored-Procedures zum Einsatz ;) Aber komplexe Business-Logik lässt sich IMHO über "richtiges" OOP sehr viel einfacher abbilden. Außerdem bin ich ein Fan von Layer-Architekturen :D

[alzaimar]

Du wirst lachen, wir haben die gesamte relativ komplexe Businesslogik eines Logistikunternehmens in SQL abgebildet. Einfach, weil wir bei z.B. bei der Rechnungslegung nicht 10 Minuten warten wollten, bis die 10.000 Rechnungen erstellt werden (OOP). Dann eben eine Stored Procedure, die macht das in 30 Sekunden. Sie enhält ca. 200 Zeilen SQL-Code, und 2000 Zeilen Kommentare.

Was will man machen?

Ich verspreche mir von der Integration von XML in z.B. MSSQL, sowie der Möglichkeit, dot.net-Prozeduren (oder Java) als stored procedures einzubinden, sehr viel. Denn auf lange sicht müssen (OOP!)-Mittelschicht und DBMS zusammenwachsen.

Ich will doch nicht auf meine Ergebnisse warten! Ich will sie sofort! Instantan! Am liebsten im OnKeyUp der Enter-Taste!

Bis dahin bleibt jedoch der goldene Mittelweg zwischen OOP-Layer und Performance. Da hab ich mich von meinem klassischen Bild auch verabschiedet (eben weil es einfach 1000x besser ist, komplexe Objekte auch so zu behandeln, aber nur, wenn sie verzeinzelt vorkommen).

[mquadrat]

Da unsere Software derzeit nicht im Bereich 10.000 Rechnungen pro Rechnungslauf angesiedelt ist, haben wir da (noch) kein Problem mit. Aber hast natürlich recht, in den Größenordnungen geht nichts anderes. Problematisch wird's halt wenn man OOP-basierte und Stored-Procedure-basierte Logik miteinander mischt. Dann muss man schon sehr gut qualifizierte Mitarbeiter haben, damit noch jemand durchblickt ;)

Es bleibt auch abzuwarten was noch aus der Ecke der modellgetriebenen Architekturen kommt. Die wären ja prädestiniert dafür das Mapping zwischen Datenbank und Modell auf sehr niedriger Ebene zu übernehmen. Die Engine könnte durch eine Analyse des Modells und des Verhaltens ja völlig selbstständig entscheiden, welche Teile durch wen, wie übernommen werden.

Aber irgendwie denke ich, sind wir vom Thema abgekommen :D

[alzaimar]

Nicht ganz:

"Was muss man bei DB-Anwendungen im Netz beachten?"

Bei EINER Architektur bleiben!
Entweder OOP-Business Logic in der Mittelschicht
ODER
Business Logic im Server

Mischen nur im Notfall!

[mquadrat]

Stimmt ;) So gesehen sind wir mitten drin im Thema. Die Frage ist, ob der Eröffner damit überhaupt was anfangen kann.

[webcss]

Also, nach meiner Meinung sollte man im Client-Server-Bereich komplett auf Datensensitive-Elemente verzichten, da, abgesehen von ClientDatasets, die Daten nur solange sichtbar sind wie die Verbindung zum Server besteht, sprich eine Transaktion läuft.
Man stelle sich dann den klassischen Fall der Datenbearbeitung kurz vor der Mittagspause vor... Dem kann man nur mit einem Timergeregelten AutoCommit beikommen.

Schlimmer noch wird die Beabeitung in Grids: was dem Anwender zwar ein relativ gewohntes Arbeitsumfeld bietet, ist nahezu tödlich für die Datenbank; 10000 Datensätze rüberschaufeln, um letztendlich einen zu Bearbeiten?! Hier sind ein gutdurchdachtes Oberflächen- und Programmdesign verpflichtend.

Zwar bieten Lösungen wie QuantumGrid o.ä. verlockende Features, im CS-Viertel ist das Alles jedoch reine Spielerei und unsinnig.

[alzaimar]

Na ja, wir haben das so gelöst:
Server->Objekt->Client->Memdataset->Datensensitiv (DevExpress)
Daten werden verarbeitet. Das geht sehr schön und einfach mit TDBEdits und derivaten.
Dann wieder Memdataset->Objekt->Server

Bisser umständlich, aber fürs RAD ganz brauchbar. Und das Mapping Objekt<-->MemDataset wurde auch noch mit einem handgebissenen Codegenerator erstellt.

Deine Lösung (KEINE TDBEdits) ist aber immer noch die beste Lösung, auch wenn Sie aufwändiger zu coden ist.

Für die Visualisierung hingegen geht nix über ein TcxGrid von DevExpress. Und weil man so schön zur Designzeit designen kann, am besten die datensensitive Alternative.