Was muss man beachten bei eine DB Anwenung in Netz?

[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 von Hansa:

... Vielleicht gehts ja, oder auch nicht.

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

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 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 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

[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. <- für Sharky 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 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 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 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?