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.