AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Datenbanken Delphi Was muss man beachten bei eine DB Anwenung in Netz?

Was muss man beachten bei eine DB Anwenung in Netz?

Ein Thema von Karstadt · begonnen am 15. Mär 2006 · letzter Beitrag vom 20. Mär 2006
Antwort Antwort
Seite 3 von 4     123 4   
Karstadt

Registriert seit: 8. Nov 2005
788 Beiträge
 
#21

Re: Was muss man beachten bei eine DB Anwenung in Netz?

  Alt 17. Mär 2006, 08:42
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)
  Mit Zitat antworten Zitat
mquadrat

Registriert seit: 13. Feb 2004
1.113 Beiträge
 
Delphi XE2 Professional
 
#22

Re: Was muss man beachten bei eine DB Anwenung in Netz?

  Alt 17. Mär 2006, 10:36
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
  Mit Zitat antworten Zitat
Thanatos81
(Gast)

n/a Beiträge
 
#23

Re: Was muss man beachten bei eine DB Anwenung in Netz?

  Alt 17. Mär 2006, 10:52
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."
  Mit Zitat antworten Zitat
alzaimar
(Moderator)

Registriert seit: 6. Mai 2005
Ort: Berlin
4.956 Beiträge
 
Delphi 2007 Enterprise
 
#24

Re: Was muss man beachten bei eine DB Anwenung in Netz?

  Alt 20. Mär 2006, 08:58
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 ). 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 = 'Ibegin -- '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 = 'Dbegin /* '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 = 'Ubegin /* '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 = 'Rbegin /* '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.
"Wenn ist das Nunstruck git und Slotermeyer? Ja! Beiherhund das Oder die Flipperwaldt gersput!"
(Monty Python "Joke Warefare")
  Mit Zitat antworten Zitat
webcss

Registriert seit: 10. Feb 2006
255 Beiträge
 
Delphi XE2 Professional
 
#25

Re: Was muss man beachten bei eine DB Anwenung in Netz?

  Alt 20. Mär 2006, 10:13
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
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?
"Wer seinem Computer Mist erzählt, muss immer damit rechnen..." (unbekannt)
"Der Computer rechnet damit, dass der Mensch denkt..." (auch unbekannt)
mein blog
  Mit Zitat antworten Zitat
alzaimar
(Moderator)

Registriert seit: 6. Mai 2005
Ort: Berlin
4.956 Beiträge
 
Delphi 2007 Enterprise
 
#26

Re: Was muss man beachten bei eine DB Anwenung in Netz?

  Alt 20. Mär 2006, 11:23
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.
"Wenn ist das Nunstruck git und Slotermeyer? Ja! Beiherhund das Oder die Flipperwaldt gersput!"
(Monty Python "Joke Warefare")
  Mit Zitat antworten Zitat
mquadrat

Registriert seit: 13. Feb 2004
1.113 Beiträge
 
Delphi XE2 Professional
 
#27

Re: Was muss man beachten bei eine DB Anwenung in Netz?

  Alt 20. Mär 2006, 11:27
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.
  Mit Zitat antworten Zitat
alzaimar
(Moderator)

Registriert seit: 6. Mai 2005
Ort: Berlin
4.956 Beiträge
 
Delphi 2007 Enterprise
 
#28

Re: Was muss man beachten bei eine DB Anwenung in Netz?

  Alt 20. Mär 2006, 11:40
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.
"Wenn ist das Nunstruck git und Slotermeyer? Ja! Beiherhund das Oder die Flipperwaldt gersput!"
(Monty Python "Joke Warefare")
  Mit Zitat antworten Zitat
mquadrat

Registriert seit: 13. Feb 2004
1.113 Beiträge
 
Delphi XE2 Professional
 
#29

Re: Was muss man beachten bei eine DB Anwenung in Netz?

  Alt 20. Mär 2006, 12:04
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
  Mit Zitat antworten Zitat
alzaimar
(Moderator)

Registriert seit: 6. Mai 2005
Ort: Berlin
4.956 Beiträge
 
Delphi 2007 Enterprise
 
#30

Re: Was muss man beachten bei eine DB Anwenung in Netz?

  Alt 20. Mär 2006, 12:12
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).
"Wenn ist das Nunstruck git und Slotermeyer? Ja! Beiherhund das Oder die Flipperwaldt gersput!"
(Monty Python "Joke Warefare")
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 23:07 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz