Hallo Udo, ich denke mal, dass es in deinem Projekt auch irgendwie wichtig ist die referentielle Integrität der Daten sowie Transaktionssicherheit sicherzustellen, und soweit ich das in Erinnerung habe kann das MySQL nicht. Was die Geschwindigkeit angeht, kann ich mich nicht über PostgreSQL beschweren, wenn man seine Joins richtig formuliert und sinnvoll indiziert geht das ab wie ein rotes Moped ... Ich habe hier auf minimaler Hardware ( AMB K7 1000, 518MB RAM ) Datenbanken mit mehreren Mio. Datensätzen laufen. Solange du keine Volltextsuche machen willst, aber das ist ein anderes Thema .... Gruß Helmut
Helmut Zengerling wrote:
Hallo Udo,
ich denke mal, dass es in deinem Projekt auch irgendwie wichtig ist die referentielle Integrität der Daten sowie Transaktionssicherheit sicherzustellen, und soweit ich das in Erinnerung habe kann das MySQL nicht.
bei wirklich grossen Datenvolumen meidet der Profi aus Performanceüberlegungen übrigens solche Features wie "referentielle Integrität". Ansonsten, wenn man auch ohne so etwas auskommen kann, warum nicht. Das betrifft auch Transaktionssicherheit, denn sehr viele der heutigen Anwendungsgebiete einer SQL Datenbank brauchen so etwas tatsächlich nicht, und der Erfolg von mysql stammt nicht unwesentlich daher, dass man den Menschen eben eine super flotte lightweight Lösung bietet, die sozusagen zeitgemäss ist und nicht mehr Konzepte mit sich herumschleppt, die man in Zeiten des Internets nicht mehr unbedingt benötigt.
At 10:56 30.08.2004, Carsten Weinberg wrote:
bei wirklich grossen Datenvolumen meidet der Profi aus Performanceüberlegungen übrigens solche Features wie "referentielle Integrität".
Ich kann mir keinen Profi vorstellen, der so eine Entscheidung nur vom Datenvolumen abhängig macht und nicht vom Inhalt der Anwendung.
Das betrifft auch Transaktionssicherheit, denn sehr viele der heutigen Anwendungsgebiete einer SQL Datenbank brauchen so etwas tatsächlich nicht, und der Erfolg von mysql stammt nicht unwesentlich daher, dass man den Menschen eben eine super flotte lightweight Lösung bietet, die sozusagen zeitgemäss ist und nicht mehr Konzepte mit sich herumschleppt, die man in Zeiten des Internets nicht mehr unbedingt benötigt.
Das hat doch nichts mit "zeitgemäß" oder "Zeiten des Internets" zu tun. Höchstens in dem Sinn, dass es im Netz Nur-Lese- oder Fast-nur-Lese-Datenbanken gibt, die es früher so gar nicht gab. Dr. Sibylle Koczian Universitaetsbibliothek, Abt. Naturwiss. D-86135 Augsburg Tel.: (0821) 598-2400, Fax : (0821) 598-2410 e-mail : Sibylle.Koczian@Bibliothek.Uni-Augsburg.DE
Am Mo, den 30.08.2004 schrieb Carsten Weinberg um 10:56:
bei wirklich grossen Datenvolumen meidet der Profi aus Performanceüberlegungen übrigens solche Features wie "referentielle Integrität".
dann hoffe ich darauf, dass bei meiner Bank, ebay und amazon Laien am werk sind, die sich gedanken um referentielle integrität machen, auf "profis" die das nicht tun kann ich gut verzichten !!!
Ansonsten, wenn man auch ohne so etwas auskommen kann, warum nicht.
Das betrifft auch Transaktionssicherheit, denn sehr viele der heutigen Anwendungsgebiete einer SQL Datenbank brauchen so etwas tatsächlich nicht, und der Erfolg von mysql stammt nicht unwesentlich daher, dass man den Menschen eben eine super flotte lightweight Lösung bietet, die sozusagen zeitgemäss ist und nicht mehr Konzepte mit sich herumschleppt, die man in Zeiten des Internets nicht mehr unbedingt benötigt.
Abrechnungssysteme, Accountdatenbanken, Buchungssysteme, alles Sachen bei denen man auf Transaktionen getrost verzichten kann ?????? alte konzepte ??? die man nicht benötigt ??? Bin ich im falschen film ? Ich bin etwas verwirrt, sowas von einem "Profi" zu hören. Ich hoffe du betreibst keinen e-shop o.Ä. !! Gruß Helmut
Hallo, Helmut Zengerling schrieb am Montag, 30. August 2004 um 11:41:
dann hoffe ich darauf, dass bei meiner Bank, ebay und amazon Laien am werk sind, die sich gedanken um referentielle integrität machen, auf "profis" die das nicht tun kann ich gut verzichten !!!
Nicht jede Applikation braucht referentielle Integrität und Transaktionen. Und Transaktionen schützen dich auch nicht vor allem. Ich wüsste nicht, warum ich bei einem CMS generell Transaktionen brauche und referentielle Integrität nicht in der Applikationen sicherstellen kann [1]. Es ist zwar hip, die gesamte Business-Logik in die Datenbank zu verschieben, aber ob es immer sinnvoll ist, ist eine andere Frage.
Abrechnungssysteme, Accountdatenbanken, Buchungssysteme, alles Sachen bei denen man auf Transaktionen getrost verzichten kann ?????? alte konzepte ??? die man nicht benötigt ??? Bin ich im falschen film ?
Es gibt nicht-zeitkritische Applikationnen, das sind vor allem die, die du hier aufzählst. Da macht es nichts, wenn eine Query eine Sekunde oder 5 Sekunden rennt. Da wird auf andere Dinge Wert gelegt. Bei diesen ganzen Diskussionen Postgres vs. MySQL vs. MS-SQL vs. Oracle vs. DB2 wird immer vergessen, dass es vielleicht weniger kosten- und aufwandintensiv ist, mit einer angemessenen Lösung auf ein Problem zu schiessen. Oder: Warum brauche ich für einen RSS-Feed eine Sun Enterprise E15K und Oracle, wenn auch SQLite ausreicht? MySQL ist keine Konkurrenz für Oracle oder DB2. Das ist am anderen Ende der Skala. Gruss, Andreas [1] Eine atomare Operation reicht für die kleineren Wehwehchen in der Regel
Hallo, At 12:01 30.08.2004, Andreas Ahlenstorf wrote:
Hallo,
Nicht jede Applikation braucht referentielle Integrität und Transaktionen. Und Transaktionen schützen dich auch nicht vor allem. Ich wüsste nicht, warum ich bei einem CMS generell Transaktionen brauche und referentielle Integrität nicht in der Applikationen sicherstellen kann [1]. Es ist zwar hip, die gesamte Business-Logik in die Datenbank zu verschieben, aber ob es immer sinnvoll ist, ist eine andere Frage.
Das ist schon richtig, nur: weder das Datenvolumen noch das Anti-Argument "zeitgemäß" taugen als Entscheidungskriterien. Der Inhalt der Datenbank und die Art der Nutzung taugen dafür; und die Frage, ob genau ein Frontend mit den Daten umgeht oder evtl. verschiedene. Der Xetra-Handel (oder heißt der schon wieder anders?) dürfte eine durchaus zeitkritische Anwendung sein, aber auf Transaktionen und referentielle Integrität wird da ja wohl hoffentlich nicht verzichtet? Gruß, Sibylle Dr. Sibylle Koczian Universitaetsbibliothek, Abt. Naturwiss. D-86135 Augsburg Tel.: (0821) 598-2400, Fax : (0821) 598-2410 e-mail : Sibylle.Koczian@Bibliothek.Uni-Augsburg.DE
Hallo, Sibylle Koczian schrieb am Montag, 30. August 2004 um 12:57:
Das ist schon richtig, nur: weder das Datenvolumen noch das Anti-Argument "zeitgemäß" taugen als Entscheidungskriterien. Der Inhalt der Datenbank und die Art der Nutzung taugen dafür; und die Frage, ob genau ein Frontend mit den Daten umgeht oder evtl. verschiedene. Der Xetra-Handel (oder heißt der
Ich habe nicht das Gegenteil behauptet.
schon wieder anders?) dürfte eine durchaus zeitkritische Anwendung sein, aber auf Transaktionen und referentielle Integrität wird da ja wohl hoffentlich nicht verzichtet?
Bitte mir meine Aussagen nicht im Mund umdrehen. Ich habe ein paar rhetorische Fragen gestellt und keine Aussage bezüglich "so muss es sein" getroffen. Da würde ich mich auch hüten. Ich bin ein Fan von angemessenen Problemlösungen. Die Quintessenz: MySQL ist nicht die Antwort auf jedes Problem, genausowenig wie es Oracle oder DB2 sind. Erkläre mir dein Problem und ich sage dir, was mir dazu einfällt. Du hörst von mir entweder ein "das geht MySQL" oder ein "das geht nicht mit MySQL". Was du aber bei einem "das geht nicht mit MySQL" wählst, ist deine Sache und der Leute, die dich beraten. Ich werde sicher keine Aussage treffen, ob Oracle oder DB2 oder MaxDB die Lösung des Problems sind. Dafür habe ich zu wenig Ahnung der jeweiligen Systeme. Und für MySQL als Totschlagargument, nur weil ich MySQL-Lösungen verkaufe, fehlt mir die fundamentalistische Ader. Gruss, Andreas
Andreas Ahlenstorf wrote: [Monday 30 August 2004 12:01]
Helmut Zengerling schrieb am Montag, 30. August 2004 um 11:41:
Nicht jede Applikation braucht referentielle Integrität und Transaktionen.
Stimmt, z.B. die meisten Webanwendungen brauchen das gar nicht.
Und Transaktionen schützen dich auch nicht vor allem. Ich wüsste nicht, warum ich bei einem CMS generell Transaktionen brauche und referentielle Integrität nicht in der Applikationen sicherstellen kann [1].
Ein CMS kannst du sicherlich auch ohne Transaktionen bauen. Du kannst ziemlich viel in der Applikation nachbauen, was die Datenbank nicht leistet. Damit handelst du dir längere Entwicklungszeiten und fehleranfälligere Programme ein. Und höheren Warungsaufwand - neue Entwickler müssen bei jeder Applikation erst mal herausfinden, wie diesmal die ad-hoc Implementierung der Tranaktionen und referentiellen Integrität funktioniert. Wenn du referentielle Integrität durch die Applikation sicherstellen willst, dann mußt du absolute Kontrolle über alle Applikationen haben, die auf die Datenbank zugreifen. Fehler darfst du auch keine machen. Und wenn irgendwer mal händisch ein update auf der Datenbank macht... Womit willst du mir das verkaufen? Durch 10% Performance-Gewinn? ;-)
Es ist zwar hip, die gesamte Business-Logik in die Datenbank zu verschieben, aber ob es immer sinnvoll ist, ist eine andere Frage.
Nein, es ist unhip. Die "jungen Leute" haben ihre Queries lieber in der Java-Applikation oder dem PHP-Skript. Ob das immer sinnvoll ist, ist aber eine andere Frage. ;-) Vor allem, wenn die Business-Logic von mehreren Applikationen verwendet werden soll, die u.U. in verschiedenen Sprachen geschrieben sind oder komplexe Berechtigungs-Schemata benötigen.
Abrechnungssysteme, Accountdatenbanken, Buchungssysteme, alles Sachen bei denen man auf Transaktionen getrost verzichten kann ?????? alte konzepte ??? die man nicht benötigt ??? Bin ich im falschen film ?
Es gibt nicht-zeitkritische Applikationnen, das sind vor allem die, die du hier aufzählst. Da macht es nichts, wenn eine Query eine Sekunde oder 5 Sekunden rennt. Da wird auf andere Dinge Wert gelegt.
Ich glaube, das ist der Punkt dieser Diskussion: wer bei Anwendungen, bei denen die Integrität der Daten absolute Priorität hat, auf Transaktionen und r.I. verzichtet oder sie selbst ausprogrammiert, der gehört gefeuert - mit einer Kanone - in die Sonne. :-) Bei anderen Applikationen wiederum kann man darauf verzichten.
Bei diesen ganzen Diskussionen Postgres vs. MySQL vs. MS-SQL vs. Oracle vs. DB2 wird immer vergessen, dass es vielleicht weniger kosten- und aufwandintensiv ist, mit einer angemessenen Lösung auf ein Problem zu schiessen. Oder: Warum brauche ich für einen RSS-Feed eine Sun Enterprise E15K und Oracle, wenn auch SQLite ausreicht?
Beim Vergleich MySQL - Oracle stimme ich zu. Ich verstehe auch nicht, warum so viele Firmen ihr Geld mit Oracle-Lizenzen hinauswerfen und dann Applikationen dafür schreiben, die genausogut auf MySQL laufen würden. Nur verstehe ich nicht wirklich, wieso die Entscheidung MySQL - PostgreSQL so oft zugunsten von MySQL ausgeht. Während PostgreSQL natürlich noch lange nicht an Oracle heranreicht, kann man die beiden doch zumindest in wichtigen Teilbereichen vergleichen, ohne für einen Scherzbold gehalten zu werden.
MySQL ist keine Konkurrenz für Oracle oder DB2. Das ist am anderen Ende der Skala.
Genau. Thomas.
Hallo, Thomas Hofer schrieb am Montag, 30. August 2004 um 13:40:
diesmal die ad-hoc Implementierung der Tranaktionen und referentiellen Integrität funktioniert. Wenn du referentielle Integrität durch die Applikation sicherstellen willst, dann mußt du absolute Kontrolle über alle Applikationen haben, die auf die Datenbank zugreifen. Fehler darfst du auch keine machen. Und wenn irgendwer mal händisch ein update auf der Datenbank macht... Womit willst du mir das verkaufen? Durch 10% Performance-Gewinn? ;-)
Nein. Eine derartige Applikation würde ich aber auch nicht so aufziehen.
Nein, es ist unhip. Die "jungen Leute" haben ihre Queries lieber in der Java-Applikation oder dem PHP-Skript. Ob das immer sinnvoll ist, ist aber eine andere Frage. ;-) Vor allem, wenn die Business-Logic von mehreren Applikationen verwendet werden soll, die u.U. in verschiedenen Sprachen geschrieben sind oder komplexe Berechtigungs-Schemata benötigen.
+1
PostgreSQL so oft zugunsten von MySQL ausgeht. Während PostgreSQL natürlich noch lange nicht an Oracle heranreicht, kann man die beiden doch zumindest in wichtigen Teilbereichen vergleichen, ohne für einen Scherzbold gehalten zu werden.
Ah, das ist relativ einfach: - MySQL ist hip - Für MySQL gibt's MySQL AB ;) - MySQL hat Support - MySQL hat Schulung - MySQL ist noch einfacher - MySQL ist verbreiteter - MySQL-Kenntnisse (!) findest du mittlerweile schon auf dem Schulhof Sowas spielt halt oftmals doch noch eine ziemlich grosse Rolle. Gruss, Andreas
Am Montag, 30. August 2004 12:01 schrieb Andreas Ahlenstorf:
Helmut Zengerling schrieb am Montag, 30. August 2004 um 11:41:
dann hoffe ich darauf, dass bei meiner Bank, ebay und amazon Laien am werk sind, die sich gedanken um referentielle integrität machen, auf "profis" die das nicht tun kann ich gut verzichten !!!
Nicht jede Applikation braucht referentielle Integrität und Transaktionen.
Richtig. Aber jede Applikation, die eine etwas komplexere DB-Struktur hat und mehrere Inserts oder Updates in einer logisch (im Sinne der Anwendungslogik) zusammenhängenden Aktion vorsieht (siehe das berühmte Beispiel der Umbuchung von Beträgen zwischen zwei Konten) braucht das.
Und Transaktionen schützen dich auch nicht vor allem.
Das hat auch niemand behauptet. Sie stellen nur einen wichtigen Mechanismus zur Gewährleistung der Datenintegrität dar.
Ich wüsste nicht, warum ich bei einem CMS generell Transaktionen brauche und referentielle Integrität nicht in der Applikationen sicherstellen kann [1].
In einem CMS brauchst Du das evtl. nicht (ich kenne Deine DB-Struktur nicht), aber ein CMS ist auch nicht unbedingt das Killerbeispiel für anspruchsvolle DB-Anwendungen. Und nebenbei gesagt bin ich davon überzeugt, dass Du unter Ausnutzung der Möglichkeiten eines richtigen DBMS Dir sehr viel Arbeit innerhalb der Applikation sparen kannst - auch in einem CMS.
Es ist zwar hip, die gesamte Business-Logik in die Datenbank zu verschieben, aber ob es immer sinnvoll ist, ist eine andere Frage.
Kein Mensch hat behauptet, dass es _immer_ sinnvoll ist, die _gesamte_ Business-Logik in die DB zu schieben. Aber es ist nicht *hip*, sondern vernünftig, das in einem angemessenen Umfang zu tun, und zwar u. a. aus folgenden Gründen: - innerhalb des DBMS können Aktionen, die durch einen Verbindungsabbruch zwischen DB-Anwendung und DB-Server nicht beendet wurden sauber und einfach zurückgefahren werden. Beispiel: Kundenauftrag wird gebucht, Auftragspositionen sind gespeichert, Kopf, also z. B. Bankverbindung nicht (Verbindung abgerissen). Die DB macht einen Rollback - fertig. Ohne Transaktionen: Leichen in der Positionstabelle. - Trigger, Prozeduren usw. liegen in der DB prekompiliert vor und sind damit in der Regel deutlich schneller in der Ausführung als von der Anwendung generierte SQL-Statements. - Jede der Datenstruktur einer DB innewohnende Logik (z. B. MWSt-Berechnungen, Rabatt- oder Provisionsberechnungen), die immer unverändert auf die Daten losgelassen wird, ist in der DB selbst am besten aufgehoben. Dann ist es nämlich egal, mit welcher Anwendungs-SW Du drauf losgehst, es passt. Und Du musst den gleichen Algorithmus nicht dreimal implementieren. Sehr zweckmäßig z. B. bei Anwendungen, die als lokale C/S-Lösungen und parallel als Webanwendungen laufen (z. B. Anbindung von Außendienstmitarbeitern an Warenwirtschaftssysteme). - Auch das Generieren von verdichteten Daten (OLAP, Datamining) aus Warenwirtschafts- oder Buchungssystemen kann man einfach und problemlos innerhalb der DB - und zwar wieder sinnvollerweise transaktionsgeklammert - realisieren. Das ist meist viel einfacher und vor allem sicherer (Stichwort Konsistenz!) als es separat laufen zu lassen.
Abrechnungssysteme, Accountdatenbanken, Buchungssysteme, alles Sachen bei denen man auf Transaktionen getrost verzichten kann ?????? alte konzepte ??? die man nicht benötigt ??? Bin ich im falschen film ?
Es gibt nicht-zeitkritische Applikationnen, das sind vor allem die, die du hier aufzählst. Da macht es nichts, wenn eine Query eine Sekunde oder 5 Sekunden rennt. Da wird auf andere Dinge Wert gelegt.
Was hat eine Query mit referentieller Integrität zu tun? Maßnahmen zur Sicherung der Datenintegrität greifen bei Operationen zur Datenmanipulation, ein Select gehört sicher nicht dazu. Außerdem möchte ich mal sehen wie Du fluchst, wenn Dein Zug gerade in den Bahnhof einfährt und der Kartenautomat erstmal ne Gedenkminute einlegt. Sehr viele Buchungssysteme sind extrem zeitkritisch - gerade die!
Bei diesen ganzen Diskussionen Postgres vs. MySQL vs. MS-SQL vs. Oracle vs. DB2 wird immer vergessen, dass es vielleicht weniger kosten- und aufwandintensiv ist, mit einer angemessenen Lösung auf ein Problem zu schiessen.
Das wird nicht vergessen und das hat in diesem Thread auch keiner vergessen IMHO. Du kannst nebenbei bemerkt mit PostgreSQL genau so ein dumpfes Datengrab aufbauen wie mit MySQL - mit genauso wenig Aufwand - aber PostgreSQL bietet Dir zumindest die Möglichkeit, eine professionelle Lösung hochzuziehen, wo MySQL trotz der mittlerweile verfügbaren Transaktionssicherung und einiger anderer Features noch passen muss.
Oder: Warum brauche ich für einen RSS-Feed eine Sun Enterprise E15K und Oracle, wenn auch SQLite ausreicht?
Für einen RSS-Feed brauchst Du gar keine DB. Die meisten Sachen, für die SQLite oder MySQL im Web eingesetzt werden, ließen sich auch mit Plain-Textdateien und ein wenig Perl realisieren. Jan -- Linux-Quickies: http://www.jan-trippler.de PingoS: http://www.pingos.org
Carsten Weinberg wrote: [Monday 30 August 2004 10:56]
bei wirklich grossen Datenvolumen meidet der Profi aus Performanceüberlegungen übrigens solche Features wie "referentielle Integrität".
Ich glaube, du mußt deine MySQL Propaganda-Fibel updaten. Nachdem MySQL AB diese Features nun in ihren windigen Betas untergebracht hat, wurde ihr Status aufgewertet, glaube ich.
Das betrifft auch Transaktionssicherheit,
Oh Schmerz.
denn sehr viele der heutigen Anwendungsgebiete einer SQL Datenbank brauchen so etwas tatsächlich nicht, und der Erfolg von mysql stammt nicht unwesentlich daher, dass man den Menschen eben eine super flotte lightweight Lösung bietet, die sozusagen zeitgemäss ist und nicht mehr Konzepte mit sich herumschleppt, die man in Zeiten des Internets nicht mehr unbedingt benötigt.
Der Erfolg von MySQL rührt daher, daß 1. das Programm von einer Firma kräftig gepusht wird, 2. es auf Windows nativ läuft, und 3. die meisten Anwender (=Webentwickler) sowieso keine Ahnung von echten Datenbanken haben (und diese für die Entwicklung ihrer Webseiten auch gar nicht brauchen - ich möchte damit niemanden beleidigen). Wenn jemand behauptet, daß Transaktionssicherheit bei größeren Datenbankprojekten zu vermeiden ist, dann ist er, nun ja, ein typischer MySQL Anwender - wobei MySQL != RDBMS und MySQL == Filesystem per SQL. MySQL ist für die "Datenbank"-Bedürfnisse von durchschnittlichen Websites tatsächlich gut geeignet (schon einmal deswegen, weil die Unterstützung auf Seiten der Provider von allen OSS-Datenbanken zur Zeit am besten ist). Für "echte" Datenbankanwendungen würde ich eher PostgreSQL empfehlen. Thomas.
Hallo, Thomas Hofer schrieb am Montag, 30. August 2004 um 11:50:
Anwender (=Webentwickler) sowieso keine Ahnung von echten Datenbanken haben (und diese für die Entwicklung ihrer Webseiten auch gar nicht brauchen - ich möchte damit niemanden beleidigen).
Solche Sätze sind kontraproduktiv. Ich sage auch nicht, dass die meisten Leute, die nach Views und Stored Procedures schreien, keine Ahnung von einem guten DB-Design haben, obwohl das bisher in sämtlichen Fällen, die ich erlebt habe, der Fall war.
MySQL Anwender - wobei MySQL != RDBMS und MySQL == Filesystem per SQL.
Auch solch eine Aussage ist kontraproduktiv. Ausser du meinst nicht MySQL, sondern SQLite. Nach einem gewissen Edgar F. Codd gibt es 333 Regeln, die ein Datenbanksystem erfüllen muss, um sich Relationelles Datenbank-Management-System nennen zu dürfen. Und soweit ich weiss, erfüllt kein einziges RDBMS diese 333 Regeln. Nicht mal die ursprünglichen 12 Regel erfüllt jedes RDBMS. Also: Ball flach halten. MySQL unterstützt viele dieser Regeln, zwar nicht alle, aber viele. Zudem haben wir einen Daemon, der läuft, und eine Client-Library, mit der man entweder über einen Unix-Socket oder eine TCP-Verbindung auf den Server zugreift. Ergo haben wir einen Server und kein Filesystem auf SQL. Wenn du also den Leuten rätst, ihre MySQL-Propaganda-Bibel zu aktualisieren, solltest du das Gleiche tun und dich mit der Software ein bisschen auseinandersetzen. Dann endet das nicht in so einem jämmerlichen Troll-Versuch... Jedes Produkt hat seine Existenzberechtigung. MySQL ist genauso wie Postgres oder Oracle oder DB2 oder MaxDB kein Allheilmittel, das zur Behandlung jedes Problems eingesetzt werden kann. Auch mit Aspirin kann man nicht alles heilen. Gruss, Andreas
Andreas Ahlenstorf wrote: [Monday 30 August 2004 12:41]
Thomas Hofer schrieb am Montag, 30. August 2004 um 11:50:
Anwender (=Webentwickler) sowieso keine Ahnung von echten Datenbanken haben (und diese für die Entwicklung ihrer Webseiten auch gar nicht brauchen - ich möchte damit niemanden beleidigen).
Solche Sätze sind kontraproduktiv. Ich sage auch nicht, dass die meisten Leute, die nach Views und Stored Procedures schreien, keine Ahnung von einem guten DB-Design haben, obwohl das bisher in sämtlichen Fällen, die ich erlebt habe, der Fall war.
Ha, das ist jedenfalls eine gute Erwiderung. Inkompetenz existiert auf beiden Enden der Skala. Solange man gerade den Job macht, für den man kompetent ist, ist alles gut. Ich hätte das vielleicht weniger "flamig" formulieren sollen, jedoch war es nicht so gemeint.
MySQL Anwender - wobei MySQL != RDBMS und MySQL == Filesystem per SQL.
Auch solch eine Aussage ist kontraproduktiv. Ausser du meinst nicht MySQL, sondern SQLite. Nach einem gewissen Edgar F. Codd gibt es 333 Regeln, die ein Datenbanksystem erfüllen muss, um sich Relationelles Datenbank-Management-System nennen zu dürfen. Und soweit ich weiss, erfüllt kein einziges RDBMS diese 333 Regeln. Nicht mal die ursprünglichen 12 Regel erfüllt jedes RDBMS. Also: Ball flach halten.
Daß die Codd'schen Gebote nur spärlich implementiert sind, weiß ich auch. Davon habe ich eigentlich nicht gesprochen - ich habe das mehr praktisch gemeint, weniger theoretisch. Schon gar nicht 333 Regeln hoch...
MySQL unterstützt viele dieser Regeln, zwar nicht alle, aber viele. Zudem haben wir einen Daemon, der läuft, und eine Client-Library, mit der man entweder über einen Unix-Socket oder eine TCP-Verbindung auf den Server zugreift. Ergo haben wir einen Server und kein Filesystem auf SQL.
Du hast mich offensichtlich mißverstanden: Daß MySQL als Serverprozess läuft, der über TCP angesprochen wird ist mir natürlich bewußt. Wenn du Transaktionen, r.I., usw. wegläßt, dann arbeitest du auf einem Niveau ähnlich dem Filesystem - das war meine Aussage.
Wenn du also den Leuten rätst, ihre MySQL-Propaganda-Bibel zu aktualisieren, solltest du das Gleiche tun und dich mit der Software ein bisschen auseinandersetzen. Dann endet das nicht in so einem jämmerlichen Troll-Versuch...
Tief durchatmen. Transaktionen helfen hier nicht, aber vielleicht Aspirin.
Jedes Produkt hat seine Existenzberechtigung. MySQL ist genauso wie Postgres oder Oracle oder DB2 oder MaxDB kein Allheilmittel, das zur Behandlung jedes Problems eingesetzt werden kann. Auch mit Aspirin kann man nicht alles heilen.
Falls du aus meinem Posting herausgelesen hast, daß ich das anders sehe, dann hast du in deiner blinden Wut nicht genau genug gelesen. Oder ich habe mich mißverständlich ausgedrückt. Thomas. PS: Reply nur an die Liste würde auch reichen.
Hallo, Thomas Hofer schrieb am Montag, 30. August 2004 um 13:29:
Ha, das ist jedenfalls eine gute Erwiderung. Inkompetenz existiert auf beiden Enden der Skala. Solange man gerade den Job macht, für den man kompetent ist, ist alles gut. Ich hätte das vielleicht weniger "flamig" formulieren sollen, jedoch war es nicht so gemeint.
;) - Wie ich bereits in einer Nachricht gesagt habe, mir fehlt die fundamentalistische Ader. Und ich muss ganz ehrlich sagen: Ich habe mir auch schon ab und zu Subselects gewünscht, aber es liess sich bisher ohne grössere Schmerzen regeln, indem man ein paar Sachen auf Programmebene gelöst hat.
Du hast mich offensichtlich mißverstanden: Daß MySQL als Serverprozess läuft, der über TCP angesprochen wird ist mir natürlich bewußt. Wenn du Transaktionen, r.I., usw. wegläßt, dann arbeitest du auf einem Niveau ähnlich dem Filesystem - das war meine Aussage.
Wenn ich unsicher bin, lasse ich das Interpretieren und warte auf eine Präzisierung. Und mit deiner Präzisierung gebe ich dir recht. Wobei man auch sagen kann, dass wen man mit Oracle nur einfache SELECTs macht, auch Oracle so arbeitet - SCNR ;)
Falls du aus meinem Posting herausgelesen hast, daß ich das anders sehe, dann hast du in deiner blinden Wut nicht genau genug gelesen. Oder ich habe mich mißverständlich ausgedrückt.
Für Wut hat das nicht gereicht. Es hat sich nicht mal mein Blutdruck erhöht. Da braucht es andere Sachen. Ich habe einfach meine liebe Mühe mit dem Abqualifizieren gewisser Produkte, vor allem, wenn einige Argumente böse an die alten Trollversuche à la Heise-Forum erinnern (MySQL ist nur ein Textfile auf Drogen etc.). Meistens stellt sich heraus, dass diese Menschen nur die MyISAM-Storage-Engine kennen und für jeden Furz am liebsten gleich die Sun E15K plus Oracle auffahren...
PS: Reply nur an die Liste würde auch reichen.
Wäre die Liste gescheiter eingestellt, würde ich das auch machen. Wenn ich aber auf Reply drücke, erscheint nur deine Adresse. Erst mit Reply-to-all kommt auch die Suse-Liste. Und dann noch manuell mit der Maus im Adressfeld herumklicken zu gehen, bis deine Adresse verschwindet und nur noch die Suse-Adresse drin steht... auch wenn man es nicht glaubt, ich habe noch andere Dinge zu tun ;) Gruss, Andreas
Andreas Ahlenstorf wrote: [Monday 30 August 2004 13:42]
Thomas Hofer schrieb am Montag, 30. August 2004 um 13:29:
Ich habe einfach meine liebe Mühe mit dem Abqualifizieren gewisser Produkte, vor allem, wenn einige Argumente böse an die alten Trollversuche à la Heise-Forum erinnern (MySQL ist nur ein Textfile auf Drogen etc.). Meistens stellt sich heraus, dass diese Menschen nur die MyISAM-Storage-Engine kennen und für jeden Furz am liebsten gleich die Sun E15K plus Oracle auffahren...
Als Heise-Troll abqualifiziert zu werden trifft mich hart, darum war das angesprochene Aspirin eher für mich selbst gedacht. Aus dem bisher geschriebenen ersehe ich, daß wir im Prinzip einer Meinung sind, aber die Sache von entgegengesetzten Positionen aus betrachten. Dadurch haben wir unterschiedliche "Feindbilder" - wobei das unfundamentalistisch und blutdruckneutral gemeint ist. ;-) Heise-Trolle gehören natürlich blutrünstig vernichtet, das ist sogar nicht-Fundamentalisten klar. :-)
PS: Reply nur an die Liste würde auch reichen.
Wäre die Liste gescheiter eingestellt, würde ich das auch machen. Wenn ich aber auf Reply drücke, erscheint nur deine Adresse. Erst mit Reply-to-all kommt auch die Suse-Liste.
Bei KMail 1.6.2 habe ich jedenfalls die Option "Reply to Mailing-List", und das funktioniert recht gut.
Und dann noch manuell mit der Maus im Adressfeld herumklicken zu gehen, bis deine Adresse verschwindet und nur noch die Suse-Adresse drin steht... auch wenn man es nicht glaubt, ich habe noch andere Dinge zu tun
Auf meiner Seite sieht der Vorgang so aus, daß meine Filterregeln beide Mails in meine inbox schieben (weil meine persönliche Adresse darin vorkommt). Dann muß ich herausfinden, welche von beiden an die Liste ging, und diese dann in das suse-directory verschieben, damit ich es im Thread-Zusammenhang sehen kann. Man könnte argumentieren, daß ich meine Filterregeln weiterentwickeln könnte - allerdings habe ich auch noch andere Dinge zu tun. ;-) Thomas.
Hallo, Am Mon, 30 Aug 2004, Thomas Hofer schrieb:
Auf meiner Seite sieht der Vorgang so aus, daß meine Filterregeln beide Mails in meine inbox schieben (weil meine persönliche Adresse darin vorkommt).
Filtere vor der Regel, die in die inbox schiebt, nach dem 'X-Mailinglist'-Header. -dnh -- Wegen Bauarbeiten an der Signatur ist zwischen dem Beginn der Signatur und dem Ende des Artikels Signatur-Ersatzverkehr eingerichtet.
Liebe Leute, lasst es uns doch etwas lockerer angehen, hier geht's ja schliesslich um die Lösung von Problemen und nicht um ein Glaubensbekenntnis. Wir halten fest: Die modernen Profis mit großen Datenbanken von immerhin 5000 records können halt auf transaktionen, referentielle integrität, stored procedures und functions verzichten, Wir Laien aus der "alten Welt" mit ein "paar" millionen datensätzen wollen uns nur nicht von dem althergebrachten lösen ... :-) Ich wollte eh bald in Rente gehen ... Aber mal ganz im Ernst für ne datensammlung bei der es keine konkurierenden operationen gibt ist MySQL doch ok, oder ? Gruß Helmut PS: Wenn ich in Rente bin zahle ich nur noch bar !!! Irgendwie hab ich zu den Profis kein so richtiges Vertrauen mehr ... PS2: Es soll auch transaktionsorientierte Filesysteme geben ...
On Monday 30 August 2004 13:52, Helmut Zengerling wrote:
Liebe Leute,
lasst es uns doch etwas lockerer angehen, hier geht's ja schliesslich um die Lösung von Problemen und nicht um ein Glaubensbekenntnis.
Wir halten fest:
Die modernen Profis mit großen Datenbanken von immerhin 5000 records können halt auf transaktionen, referentielle integrität, stored procedures und functions verzichten, Wir Laien aus der "alten Welt" mit ein "paar" millionen datensätzen wollen uns nur nicht von dem althergebrachten lösen ...
:-)
Ich wollte eh bald in Rente gehen ...
Aber mal ganz im Ernst für ne datensammlung bei der es keine konkurierenden operationen gibt ist MySQL doch ok, oder ?
Gruß Helmut
PS: Wenn ich in Rente bin zahle ich nur noch bar !!! Irgendwie hab ich zu den Profis kein so richtiges Vertrauen mehr ...
PS2: Es soll auch transaktionsorientierte Filesysteme geben ...
Junge, Junge, wenn ich das gewußt hätte, hät ich die Frage nie so gestellt. Aber trotzdem kann ich mir viel aus den Antworten ziehen. Danke ! BTW: Helmut, was meinst Du mit konkurierenden Operationen. Das denke ich war einer meiner Hauptfragen, weil ich wissen wollte, wie es bei der Abarbeitung eines Formulars aussieht, daß gleichzeitig durch mehrere Benutzer parallel ausgefüllt und abgeschickt wird. Kanns hierbei zu ungewollten Timeouts kommen? Natürlich kann ich das mit PHP modifizieren, aber wenn ein Script ewig braucht, weil die Datenbank mit dem Abarbeiten nicht mehr hinterherkommt, ist das auch nicht wünschenswert. Gruß -- ------------------------------------------------------------------------------------------------- Wir sind Bill Gates! Widerstand ist zwecklos! Sie werden assimiliert! Ihre Datenbestände werden den unseren hinzugefügt! ------------------------------------------------------------------------------------------------- --
Junge, Junge,
wenn ich das gewußt hätte, hät ich die Frage nie so gestellt. Aber trotzdem kann ich mir viel aus den Antworten ziehen. Danke !
BTW: Helmut, was meinst Du mit konkurierenden Operationen. Das denke ich war einer meiner Hauptfragen, weil ich wissen wollte, wie es bei der Abarbeitung eines Formulars aussieht, daß gleichzeitig durch mehrere Benutzer parallel ausgefüllt und abgeschickt wird. Kanns hierbei zu ungewollten Timeouts kommen? Natürlich kann ich das mit PHP modifizieren, aber wenn ein Script ewig braucht, weil die Datenbank mit dem Abarbeiten nicht mehr hinterherkommt, ist das auch nicht wünschenswert.
Hallo Udo, die wichtige Frage ist, können verschiedene Benutzer gleichzeitig an denselben Daten arbeiten, bzw. sind die Daten in einem Formular abhängig von den Daten die andere Benutzer eingeben modifizierren oder löschen können, wenn irgendwas davon eintreten kann, kommst du z.B. um transaktionen nicht herum. Und referentielle Integrität in applikationen abzubilden ist PIA, die Gründe hierfür wurden in diesem thread schon genannt ... Timeouts sind das kleinere Problem , die kann man umschiffen ... Gruß Helmut
On Monday 30 August 2004 15:04, Helmut Zengerling wrote: ...
die wichtige Frage ist, können verschiedene Benutzer gleichzeitig an denselben Daten arbeiten, bzw. sind die Daten in einem Formular abhängig von den Daten die andere Benutzer eingeben modifizierren oder löschen können, wenn irgendwas davon eintreten kann, kommst du z.B. um transaktionen nicht herum. Und referentielle Integrität in applikationen abzubilden ist PIA, die Gründe hierfür wurden in diesem thread schon genannt ...
Timeouts sind das kleinere Problem , die kann man umschiffen ...
... Na ja, die Benutzer "benutzen" gemeinsame Daten (über Select-Boxes, etc), um diese in Ihrem eigene Account und damit eben in Tabellen zu speichern. Soweit ich das abschätzen kann, ist das das einzige, was die Benutzer gemeinsam nutzen. Wenn Daten gelöscht oder modifiziert werden, dann nur durch den Benutzer selber. Alle anderen können nur Lesend drauf zugreifen, oder nur einen Kommentar dazu schreiben. Es kann aber sein, daß mehrere Benutzer z.B. das gleiche Formular ausfüllen und gleichzeitig an die Datenbank abschicken. Gruß Udo -- ------------------------------------------------------------------------------------------------- Wir sind Bill Gates! Widerstand ist zwecklos! Sie werden assimiliert! Ihre Datenbestände werden den unseren hinzugefügt! ------------------------------------------------------------------------------------------------- --
Am Montag, 30. August 2004 15:22 schrieb Udo Gerhards:
On Monday 30 August 2004 15:04, Helmut Zengerling wrote: ...
[...]
Timeouts sind das kleinere Problem , die kann man umschiffen ...
Na ja,
die Benutzer "benutzen" gemeinsame Daten (über Select-Boxes, etc), um diese in Ihrem eigene Account und damit eben in Tabellen zu speichern. Soweit ich das abschätzen kann, ist das das einzige, was die Benutzer gemeinsam nutzen.
Dafür, dass lesend gemaeinsam zugegriffen wird braucht es sicher keine "referenzielle Integrität". :)
Wenn Daten gelöscht oder modifiziert werden, dann nur durch den Benutzer selber. Alle anderen können nur Lesend drauf zugreifen, oder nur einen Kommentar dazu schreiben. Es kann aber sein, daß mehrere Benutzer z.B. das gleiche Formular ausfüllen und gleichzeitig an die Datenbank abschicken.
Das hat auch weder etwas mit "Transactions" noch etwas mit "referenzieller Integrität" zu tun. Ich rate in diesem Fall auch zu MySQL, denn mehr wird nicht gefordert. Und um die ursprüngliche Frage wieder aufzugreifen: MySQL ist IMHO hier sicher die schnellere Datenbank, auf Grund des viel geringeren Overheads. Als weiter Vorteil kommt noch dazu, dass es ja, AFAIR darum gilt mit weiteren MySQL-Datenbanken zu kooperieren. lg, Andreas.
Am Montag, 30. August 2004 15:22 schrieb Udo Gerhards:
On Monday 30 August 2004 15:04, Helmut Zengerling wrote: ...
[...]
Timeouts sind das kleinere Problem , die kann man umschiffen ...
Na ja,
die Benutzer "benutzen" gemeinsame Daten (über Select-Boxes, etc), um diese in Ihrem eigene Account und damit eben in Tabellen zu speichern. Soweit ich das abschätzen kann, ist das das einzige, was die Benutzer gemeinsam nutzen.
Dafür, dass lesend gemaeinsam zugegriffen wird braucht es sicher keine "referenzielle Integrität". :)
Wenn Daten gelöscht oder modifiziert werden, dann nur durch den Benutzer selber. Alle anderen können nur Lesend drauf zugreifen, oder nur einen Kommentar dazu schreiben. Es kann aber sein, daß mehrere Benutzer z.B. das gleiche Formular ausfüllen und gleichzeitig an die Datenbank abschicken.
Das hat auch weder etwas mit "Transactions" noch etwas mit "referenzieller Integrität" zu tun. Ich rate in diesem Fall auch zu MySQL, denn mehr wird nicht gefordert. Und um die ursprüngliche Frage wieder aufzugreifen: MySQL ist IMHO hier sicher die schnellere Datenbank, auf Grund des viel geringeren Overheads. Als weiter Vorteil kommt noch dazu, dass es ja, AFAIR darum gilt mit weiteren MySQL-Datenbanken zu kooperieren. lg, Andreas.
Monday 30 August 2004 10:56, Carsten Weinberg wrote:
Helmut Zengerling wrote:
Hallo Udo,
ich denke mal, dass es in deinem Projekt auch irgendwie wichtig ist die referentielle Integrität der Daten sowie Transaktionssicherheit sicherzustellen, und soweit ich das in Erinnerung habe kann das MySQL nicht.
bei wirklich grossen Datenvolumen meidet der Profi aus Performanceüberlegungen übrigens solche Features wie "referentielle Integrität".
Das wäre mir neu ! Datenintegrität ist doch das überhaupt wichtigste. Was würden Banken und andere machen, wenn Buchungen nur zur hälfte ausgeführt werden würden ? Eine Datenbank wird meiner Meinung nach richtig sinnvoll, wenn mehrere Tabellen miteinander arbeiten. Außerdem werden so Fehler vermieden und man kann gar nicht erst falsche Daten eintragen. MySQL ist vieleicht schnell aber kann nicht viel. Und wer nicht viel zu arbeiten hat macht das was er tut eben schneller ist ja klar. Dafür gibt es bei großen Datenmengen Cluster und andere Möglichkeiten das System zu optimieren, und außderdem erledigt MySQL manche Aufgaben einfach falsch ! Guck dir mal die Seite an : http://sql-info.de/mysql/gotchas.html :o) MySQL ist ja noch nicht einmal eine ACID gerechte Datenbank was eigentlich eine Datenbank ausmacht. Wenn man sich eine Datenbank anschafft sollte man mal über sowas nachdenken, sonst kannst du dir doch direkt ein CSV nehmen oder ? Zeig mir mal einen von den Profis !
Ansonsten, wenn man auch ohne so etwas auskommen kann, warum nicht.
Das betrifft auch Transaktionssicherheit, denn sehr viele der heutigen Anwendungsgebiete einer SQL Datenbank brauchen so etwas tatsächlich nicht,
Welche denn ? Gästebücher ? Für alles was solche Sachen nicht braucht, kannst du SQL auch seinlassen und eine einfache Datei benutzen oder ?
und der Erfolg von mysql stammt nicht unwesentlich daher, dass man den Menschen eben eine super flotte lightweight Lösung bietet, die sozusagen zeitgemäss ist und nicht mehr Konzepte mit sich herumschleppt, die man in Zeiten des Internets nicht mehr unbedingt benötigt.
Natürlich wird so etwas noch benötigt z.b. bei Online Shops , Banken und vielen anderen ! Martin
Am Montag, 30. August 2004 10:56 schrieb Carsten Weinberg:
Helmut Zengerling wrote:
Hallo Udo,
ich denke mal, dass es in deinem Projekt auch irgendwie wichtig ist die referentielle Integrität der Daten sowie Transaktionssicherheit sicherzustellen, und soweit ich das in Erinnerung habe kann das MySQL nicht.
bei wirklich grossen Datenvolumen meidet der Profi aus Performanceüberlegungen übrigens solche Features wie "referentielle Integrität".
Was hat die referentielle Integrität mit dem Datenvolumen zu tun? Das entscheidende Kriterium ist nicht das Datenvolumen, sondern der Umfang und die Häufigkeit von Datenmanipulationen. Und Du kannst mir glauben - ich entwickle seit mehr als 10 Jahren DB-Anwendungen der unterschiedlichsten Art - _kein_ Profi verzichtet zugunsten der Performance auf Datenintegrität. Wenn die Performance mangelhaft ist, dann muss optimiert werden - ggf. das DB-Design überarbeitet werden. Aber die Integrität der Daten steht _immer_ an 1. Stelle. Wie würdest Du es finden, wenn Deine Bank Dein Konto nicht auf Heller und Pfennig genau führen würde, nur damit Dein Kontoauszug 2 Sekunden schneller da ist?
Das betrifft auch Transaktionssicherheit, denn sehr viele der heutigen Anwendungsgebiete einer SQL Datenbank brauchen so etwas tatsächlich nicht, und der Erfolg von mysql stammt nicht unwesentlich daher, dass man den Menschen eben eine super flotte lightweight Lösung bietet, die sozusagen zeitgemäss ist und nicht mehr Konzepte mit sich herumschleppt, die man in Zeiten des Internets nicht mehr unbedingt benötigt.
<IMHO-Modus> Der Erfolg von MySQL rührt nach meinen Erfahrungen unter anderem daher, dass sich mit dem Internet-Boom und der Dotcom-Blase auf einen Schlag ein Haufen ehemaliger Werbegrafiker auf einmal in Programmierung übten, ohne eine auch nur entfernte Ahnung davon zu haben, worauf sie sich z. B. mit einem Webshop einlassen. Ich habe die abenteuerlichsten DB-*Designs* gesehen - die sich dann in ebenso abenteuerlichen Anwendungen niederschlugen! </IMHO-Modus> MySQL ist sicher nicht die schlechteste Wahl, wenn es um Datengräber geht, die vorrangig abgefragt werden und Datenmanipulationen nur selten und nur in einfacher Form benötigen (Eintrag in einen Newsletter z. B. oder Gästebücher, ...). Sie ist garantiert nicht die 1. Wahl bei Systemen, bei denen Wert auf die Konsistenz von Daten gelegt werden muss und wo komplexere Aktionen auf der DB erfolgen müssen. Das ist z. B. immer dann der Fall, wenn verschiedene Systeme (Auftragsabwicklung, Buchungs- und Zahlungssysteme, Auskunftssysteme) im Spiel sind. Dann nämlich vervielfacht sich der Aufwand in der Anwendungsentwicklung unverhältnismäßig. Jan -- Linux-Quickies: http://www.jan-trippler.de PingoS: http://www.pingos.org
Hi Liste, Warum ist MySql so erfolgreich? Es war neben mSQL eine der ersten Datenbanken (wenn nicht die erste Datenbank), die royaltyfree im nicht kommerziellen Bereich, mit eine SQL-ähnlichen Syntax zur Verfügung stand. Postgress hatte eine eigenen Abfragesprache, erst später verstand Postgress auch SQL und heißt seit dem PostgreSQL. Das Hauptaugenmerk von MySQL lag auf niedrigem Resourcenverbrauch und hohe Abfragegeschwindigkeit, deshalb wurden auf Sachen wie Trigger, Stored Procedures und referentielle Integrität verzichtet. Letzteres hat man durch rIbB (Referentielle Integrität By Brain) ersetzten können: 1. Durch entsprechende Programmierung der Anwendung, 2. Das nur Personen, die die Datenbank in- und auswendig kennen einen anderen Zugriff als durch das Programm ermöglicht wird. Das ist auf einem Hostet-Webserver auch kein Problem. Dazu kommt noch das so ziemlich jeder Webhoster MySQL unterstützt, und das auch fast ausschließlich. @Udo Gerhards: Was meinst du mit CMS? [ ] CMS= Contact Managment System [ ] CMS= Contents Managment System Andreas Ahlenstorf wrote: [Monday 30 August 2004 12:41]
Thomas Hofer schrieb am Montag, 30. August 2004 um 11:50:
MySQL == Filesystem per SQL. Zudem haben wir einen Daemon, der läuft, und eine Client-Library, mit der man entweder über einen Unix-Socket oder eine TCP-Verbindung auf den Server zugreift.
Hat NFS auch.
Ergo haben wir einen Server und kein Filesystem auf SQL.
Ja, aber der Server stellt nur schreib- und lesezugriffe bereit. Ich programmiere auch noch in COBOL dort sind diese Zugriffe direkt in der Sprache integriert ( nennt sich indexed File). Der große Vorteil ist ja eben das der MySQL-Deamon eine SQL-ähnliche Sprache für dieses benutzt. Hat aber eben auch Nachteile. Wenn man obengesagte [Punkt 1 und 2] sicherstellen kann, ist MySQL eine Möglichkeit. Alternativ wäre dann auch über LDAP nachzudenken. Kann man obengesagte [Punkt 1 und 2] nicht sicherstellen, sollte man eine MySQL-Version nehmen, die referentielle Integrität unterstützt, sonst hat man unter umständen sehr schnell einen Datenbestand der nicht mehr zu gebrauchen ist. Ich persönlich verwende MySQL nicht mehr, bei Aktivierung der Resourcenverbrauch steigt, die Geschwindigkeit etwas leidet und ich keinen Precompiler für COBOL zur Verfügung habe. Letzteres ist auch für PostgreSQL Ausschlußkriterium. Anmerkung: Resourcenverbrauch und Geschwindigkeit bei MySQL: Diese Erkenntnis, beruht auf einen direkten Vergleich zwischen MySQL vs firebird mit realen Testdaten, also kein Benchmark, Ergebnis war damals: MySQL ohne Erweiterung: schneller und geringerer Resorcenverbrauch als firebird. MySQL mit Erweiterung: Geschwindigkeit und Resourcenverbrauch waren fast identisch, vielleicht meßbare Unterschiede. Da firebird auch unter einer OSS-Lizence steht, IMHO nicht so restrictiv wie MySQL (Stichwort: wo beginnt kommerziell) ist sie vielleicht ja eine, nicht so bekannte, Alternative. Hier der Link: www.firebirdsql.org Anleitungen finden sich zuhauf sowohl im Internet, wie auch im Buchhandel, allerdings muß man mit "interbase" suchen. Aproppos PostgreSQL: Eine 365/24 Anwendung würde ich damit nicht schreiben, weil regelmäßig ein VACUUM gefahren werden muß, laut Entwickler auf dem Chemnitzer Linuxtag, sollte man das nicht im laufenden Betrieb machen, zumindest nicht auf Productivsystemen. hth cu Gerald
On Monday 30 August 2004 16:36, Gerald Goebel wrote: ...
@Udo Gerhards: Was meinst du mit CMS? [ ] CMS= Contact Managment System [ ] CMS= Contents Managment System ..
Hallo Gerald, ich meinte damit ein Content-Management-System. Es soll das Framework für die eigentlich (Web-)Applikation bilden. Das CMS bringt seine eigene MYSQL-Datenbank mit und wir werden wohl nicht umhin kommen, unsere Entwicklung damit zu koppeln (z.B. soll die User-Authentifizierung komplett über das CMS abgewickelt werden.). Gruß Udo -- ------------------------------------------------------------------------------------------------- Wir sind Bill Gates! Widerstand ist zwecklos! Sie werden assimiliert! Ihre Datenbestände werden den unseren hinzugefügt! ------------------------------------------------------------------------------------------------- --
Hi Udo, hi Liste, Am Montag, 30. August 2004 16:50 schrieb Udo Gerhards:
ich meinte damit ein Content-Management-System. Es soll das Framework für die eigentlich (Web-)Applikation bilden. Das CMS bringt seine eigene MYSQL-Datenbank mit und wir werden wohl nicht umhin kommen, unsere Entwicklung damit zu koppeln (z.B. soll die User-Authentifizierung komplett über das CMS abgewickelt werden.).
in diesem Fall, würde ich die bestehende Datenbank aber nur erweitern und nicht eine zusätzliche benutzen, es sei denn es gibt einen trifftigen Grund dafür. cu Gerald
Hallo zusammen! Hat schon jemand Erfahrung mit dem "Open X-Change" gemacht (Installation, Konfiguration, Zuverlaessigkeit etc)? http://mirror.open-xchange.org/ox/EN/product/ Gruss, Oliver Cavelius
Am Montag, 30. August 2004 16:36 schrieb Gerald Goebel: [...]
Aproppos PostgreSQL: Eine 365/24 Anwendung würde ich damit nicht schreiben, weil regelmäßig ein VACUUM gefahren werden muß, laut Entwickler auf dem Chemnitzer Linuxtag, sollte man das nicht im laufenden Betrieb machen, zumindest nicht auf Productivsystemen.
Hallo, ich verfolge die Diskussion zeitverzögert, aber sehr interessiert. Was bitte ist - bezogen auf PostgreSQL- ein VACUUM? Ich vermute, dass delete * from ... damit nicht gemeint sein kann, obwohl das bei regelmäßiger Anwendung natürlich eine schlanke Datenhaltung erreichen würde... Gruß, Wolfgang
Hi Wolfgang, hi Liste Am Donnerstag, 2. September 2004 12:45 schrieb Wolfgang Hinsch:
Am Montag, 30. August 2004 16:36 schrieb Gerald Goebel:
Aproppos PostgreSQL: Eine 365/24 Anwendung würde ich damit nicht schreiben, weil regelmäßig ein VACUUM gefahren werden muß, laut Entwickler auf dem Chemnitzer Linuxtag, sollte man das nicht im laufenden Betrieb machen, zumindest nicht auf Productivsystemen.
ich verfolge die Diskussion zeitverzögert, aber sehr interessiert. Was bitte ist - bezogen auf PostgreSQL- ein VACUUM? Ich vermute, dass delete * from ... damit nicht gemeint sein kann, obwohl das bei regelmäßiger Anwendung natürlich eine schlanke Datenhaltung erreichen würde...
In PostgreSQL muss aus mehreren Gründen regelmäßig der Befehl VACUUM ausgeführt werden: - Um den von aktualisierten oder gelöschten Zeilen belegten Speicherplatz wiederzugewinnen. - Um die vom PostgreSQL-Anfrageplaner verwendeten Datenstatistiken zu aktualisieren. - Um sich gegen den Verlust sehr alter Daten durch Überlauf der Transaktionsnummern zu schützen. Ab Version 7.2 kann man dieses auch während des laufendes Betriebs machen, vorher war es zwingend die Datenbank vom Netz zu nehmen Aber mir wurde davon abgeraten dieses zu tun. hth cu Gerald.
participants (13)
-
Andreas Ahlenstorf -
Andreas Scherer -
Carsten Weinberg -
David Haller -
Gerald Goebel -
Helmut Zengerling -
Jan.Trippler＠t-online.de -
Martin Kremers -
Oliver Cavelius -
Sibylle Koczian -
Thomas Hofer -
Udo Gerhards -
Wolfgang Hinsch