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.
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?
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.
(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
)