Diese Diskussion wurde archiviert.
Es können keine neuen Kommentare abgegeben werden.
|
|
|
|
|
|
|
|
|
http://www.heise.de/ix/artikel/2004/02/036/
|
|
|
|
|
|
|
|
|
|
|
|
|
Meiner Meinung nach sagt dieser Artikel aus, dass OSS Datenbanken für den Test und Heimgebrauch gerade noch gut genug sind, aber im Kommerziellen Einsatz nicht geeignet seien. Das verwirrt mich jetzt doch ein wenig schliesslich werden von den meisten Hostern Mysql, Postgresql etc. eingesetzt. Auch ich setzt Mysql ein und kann nicht behaupten, das diese Datenbanken nicht geeignet sei. http://www.iframe.ch
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Wednesday 21. January, 17:06 MET (#3)
|
|
|
|
|
Meiner Meinung nach lohnen sich Oracle und Co. in jedem grösseren Firmenumfeld (Enterprise Applications). Eine grosse Funktionsvielfalt nützt in einer Webapplikation nicht viel. Aber ob DBA oder Entwickler, jedesmal können mit nützlichen Features Stundenweise Arbeitsaufand gespart werden, somit sind die Lizenzkosten schnell wieder drin.
Aber grundsäztlich hab ich die Erfahrung gemacht je simpler die DB, desto besser strukturiert wird eine Applikation. Funktionsvielfalt führt zu Lösungsvielfalt, somit zum Chaos.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Wednesday 21. January, 17:13 MET (#4)
|
|
|
|
|
... ist es in der Zwischenzeit sogar besser, eine schlanke Datenbank einzusetzen und alles, was fehlt (Rules/Trigger/Sequences/Transactions/Subselects/DBStructureAlternation/Dump/Restore/Datatypes(also nur varchar2)/GroupOperators)
in der Applikation oder als MittelVieh (Tier) selbst zu implementieren, damit man im Endeffekt von der Datenbank völlig unabhängig ist und keine Fehler verantworten muß, die der Datenbankhersteller gemacht hat (ist mir bei z.B. Oracle passiert)
Anynomous
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Wednesday 21. January, 17:17 MET (#5)
|
|
|
|
|
Also, Webhosting als Beispiel für 'professionellen Einsatz' zu nehmen find ich schon grad ein bisschen gewagt. :)
|
|
|
|
|
|
|
|
|
|
|
|
|
Hmmm... doch. Mag sein, dass die Kunden nicht alle so professionell sind, aber die Provider sollten es schon sein. An meinem Arbeitsplatz muten wir mysql einiges zu: Der in etwa grösste Kunde hat doch immerhin auch um 6000 Artikel in seinem Shop, diverse Informationsseiten zusätzlich im CMS und natürlich auch seine Kunden, Bestellungen etc. in der gleichen Datenbank. Natürlich ist das noch nicht die Datenflut des europäischen Gerichtshofs, aber wenn das unprofessionell gehostet wird reicht es für ein schönes Chaos.
Grüsse vom Knochen
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Wednesday 21. January, 19:16 MET (#7)
|
|
|
|
|
ich muss zwar zugeben, dass MySQL nur für die kleinen und meistens Amateurhaften Webprogrammieren geeignet ist.
Wir haben ein Oracle durch Postgres SQL abgelöst. Und ratet mal wer die SUN Sever betreut. Na ich, danke für den Applaus
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Wednesday 21. January, 22:11 MET (#9)
|
|
|
|
|
"ich muss zwar zugeben, dass MySQL nur für die kleinen und meistens Amateurhaften Webprogrammieren geeignet ist."
Ts... was hast du denn grosses "Webprogrammiert", dass eine MySQL-DB nicht ausgereicht gemacht hat?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Im Web wird die Transaktion meist durch die Webapplikation vorgegeben und anschliessend alles in einem Rutsch gespeichert. Da braucht es keine Transaktion auf der Stufe DB mehr. --
Computers - born to use Linux!
|
|
|
|
|
|
|
|
|
|
|
|
|
Ach, "in einem Rutsch"?
Deine INSERTS und UPDATES will ich sehen.
Auch wenn die queries direkt nacheinander im Source stehen besteht die Möglichkeit einer race condition.
Und die wird mit steigender Benutzerzahl auch immer wahrscheinlicher.
Nein nein, eine "richtige" (grosse) Datenbank App sollte man schon mit Transaktionen machen. Webgui hin oder her.
|
|
|
|
|
|