Was muss man beachten bei eine DB Anwenung in Netz?

[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).