MYSQL oder MSDE

[Hansi]

Für eine ziemlich flache aber große Datenbank möchte ich entweder MYSQL oder MSDE einsetzen, welche ist die bessere Variante.
- Es soll eine Hauptdatenbank sein mit bis zu mehreren 1000 Tabellen, die einzeln erstellt werden sollen.
- In jeder Tabelle sollen min. pro Tag ca 10 Spalten befüllt werden; dies könnte sich aber noch erhöhen, sodass die 10 Spalten mehrmals täglich befüllt werde (für alle Tabellen genauso)

Welche Erfahrung habt Ihr? Welche ist schneller? Welche einfacher zu handhaben?

[Bernhard Geyer]

Nach den Anforderungen fällt keine DB raus.

Hier ein paar Entscheidungskriterien:
- Replikation nötig? -> MS-SQL
- Multi-Versions-Konzept (nur bei Transaktionen relevant) nötig -> MySQL
- Plattformunabhängig? -> MySQL
- (Möglichst) geringe Kosten? -> MySQL oder MSDE ("kastrierter MS-SQL-Server)

[Robert_G]

Ich könnte niemanden mySQL empfehlen, das Ding kann einfach zu weing.
Wenn es groß und performant sein sollte, könnte Caché das Mittel der Wahl sein. Da du dort Tabellen von einander ableiten kannst, werden aus 1.000 Tabellen ganz schnell 100. ;)
Sein Opensource pendant PostGreSQL sei hier auch erwähnt.
Die MSDE hat eine eingebaute Bremse, die ab 6 gleichzeitigen Usern zieht -> das macht sie für dich sicher komplett uninteressant.
Gerade unter Caché ist die Programmierung einfach nur genial. SELECT per ODBC und DML direkt an den Objekten per COM. :love:

[Hansi]

Für mich kommt eine DB in Frage die kostenlos ist. Ein Vergleich hinkt natürlich meistens wenn man eine kostenlose DB mit einer sehr teuren DB vergleicht.

Cache werde ich mir mal anschauen...

[UweR]

Schau dir auch mal Firebird an. Kann eigentlich alles was du brauchst und kostet halt auch nichts.

[Hansi]

Kennst Du Dich mit Firebird aus. Kannst Du es empfehlen?
Wo sind die Stärken und wo die Schwächen gegenüber den anderen DB?

[Jelly]

Zitat:

Zitat von Hansi

Wo sind die Stärken und wo die Schwächen gegenüber den anderen DB?

Gegenüber MySQL in erster Linie:

• Transaktionen (Commit und Rollback)
• Stored Procedures
• Views
• Triggers

Un gegenüber der MSDE:

• Plattformunabhängig
• Multiuserfähig

Ich kann Firebird wirklich nur empfehlen. Hab vor ungefähr 5 Jahren einem Kunden ein Interbase 6.5 auf seinem Bürorechner installiert (das war der Vorgänger von Firebird, damals in der Version 6.5 auch kostenlos), und seitdem läuft das Ding, und es läuft und läuft. Da gabs in all den Jahren noch keinen einzigen Zwischenfall, obwohl die Datenbank in einem 5 Mann Netz hängt.... Reicht das als Erfahrungsbericht :zwinker:

Was die Performance angeht, zwischen MySQL und Firebird hab ich leider keine direkten Werte. MySQL ist schnell, dafürs ist es bekannt, aber mit Firebird hatte ich bis jetzt auch noch keine nennenswerte Probleme. Bedenke aber, eine DB ohne die oben genannten Punkte hat in meinen Augen nicht den Namen Datenbank verdient, jedenfalls nicht C/S Multiuser Datenbank.

Gruß,

[woki]

Hi,

bei Borland gibt es ein Whitepaper zum Thema Interbase versus MySQL, und das dürfte im wesentlichen ja so auch auf Firebird versus MySQL zutreffen.

Grüße
Woki

[Strophi]

Hi Forum,

ich finde arbeiten ist auch mit MySQL möglich. Ich hab' brilliante MySQL-Anwwendungen gesehen. Grottenschlechte Cache-Anwendungen wird es auch zu geben, kann ich jetzt nichts zu sagen, ich kenne niemanden, der mit Cache arbeitet.
Aber wenn es die anderen Entwicklungsumgebungen topt, kann es ja nicht mehr lange dauern, bis sie vom Markt gefegt sind :)

Zitat:

Zitat von Robert_G

Ich könnte niemanden mySQL empfehlen, das Ding kann einfach zu weing.

Ich finde, wenn die Industrie MySQL unterstützt, kann es so schlecht nicht sein.

http://www.mysql.com/customers/

Und Millionen PHP-Programmierer verlassen sich drauf, sie wissen oft, was sie tun.

Also nicht für ungut, aber MySQL als nicht empfehlenswert zu klassifizieren, und dann sagen Cache ist die Lösung finde ich seltsam...

Natürlich hat jedes System Limits.
Die PHP-FAQ äußert sich zu MYSQL so:
http://www.php-faq.de/q/q-mysql-eignung.html

mfg

Strophi

[Robert_G]

Zitat:

Zitat von Strophi

...ich finde arbeiten ist auch mit MySQL möglich. Ich hab' brilliante MySQL-Anwwendungen gesehen. Grottenschlechte Cache-Anwendungen wird es auch zu geben, kann ich jetzt nichts zu sagen, ich kenne niemanden, der mit Cache arbeitet.
Aber wenn es die anderen Entwicklungsumgebungen topt, kann es ja nicht mehr lange dauern, bis sie vom Markt gefegt sind :)

Komischerweise nicht. Ich bin auch nur zufällig drüber "gestolpert" und ärgere mich mittlerweile schon _fast_ meine Anwendungen für Oracle geschrieben zu haben. Es ist zwar sehr gewöhnungsbbedürftig seine Tabellen als Klassen zu definieren, aber es gibt einem auch viele nette Möglichkeiten. :)
Die PR-Abteilung von Intersystem scheint nicht viel zu taugen. :mrgreen:
Außerdem wagen/wollen viele Entwickler den Sprung vom angestaubten relationen Konzept zum objekt-relationalen / objekt-orientierten Konzept nicht.
Als kostenlose Altenative gibt's da noch www.PostGreSQL.org. pgSQL ist zwar nicht so objekt bezogen wie caché 5, aber an Funktionalität und Leistungsfähigkeit steckt es sicher so manche teure DB in die Tasche.


Wenn es günstig/kostenlos sein soll ist Caché wohl nix für dich. ;)
1.000 Tabellen in FireBird/Interbase? :shock:
Bleiben also nur noch mySQL & PostgreSQL im Rennen...


Ein kleiner Ausblick auf die Leistungsfähigkeit von PL/pgSQL (ähnlich zu Oracle's PL/SQL :) )

PostgreSQL Doku:

Example 35-2. Porting a Simple Function from PL/SQL to PL/pgSQL

Here is an Oracle PL/SQL function:

SQL-Code:

CREATE OR REPLACE FUNCTION cs_fmt_browser_version(v_name IN varchar,
                                                  v_version IN varchar)
RETURN varchar IS
BEGIN
    IF v_version IS NULL THEN
        RETURN v_name;
    END IF;
    RETURN v_name || '/' || v_version;
END;
/
show errors;

Let's go through this function and see the differences to PL/pgSQL:

Oracle can have IN, OUT, and INOUT parameters passed to functions. INOUT, for example, means that the parameter will receive a value and return another. PostgreSQL only has IN parameters, and hence there is no specification of the parameter kind.

The RETURN key word in the function prototype (not the function body) becomes RETURNS in PostgreSQL. Also, IS becomes AS, and you need to add a LANGUAGE clause because PL/pgSQL is not the only possible function language.

In PostgreSQL, the function body is considered to be a string literal, so you need to use quote marks or dollar quotes around it. This substitutes for the terminating / in the Oracle approach.

The show errors command does not exist in PostgreSQL, and is not needed since errors are reported automatically.


This is how this function would look when ported to PostgreSQL:

SQL-Code:

CREATE OR REPLACE FUNCTION cs_fmt_browser_version(v_name varchar,
                                                  v_version varchar)
RETURNS varchar AS $$
BEGIN
    IF v_version IS NULL THEN
        RETURN v_name;
    END IF;
    RETURN v_name || '/' || v_version;
END;
$$ LANGUAGE plpgsql;

@Strophi
Solange mySQL für das absolute Fehlen von db-seitiger Logik steht, wüsste ich nicht wofür ich es gebrauchen könnte. :gruebel: (keine SP, keine Trigger, keine Sequences, kein... kein gar nichts :? )
Wenn man _sämtliche_ Logik in einem WebService verpackt hat, ist mySQL sicherlich nicht uninteressant (Wenn es um schnörkelloses SQL geht, ist mySQL ja auch verdammt schnell ;) )