Zitat von
Alfredo:
1) Ihr solltet euch mit dem Thema Datensicherung auseinandersetzen
- Ihr werdet feststellen, dass diese bei Progress mit einem hohen
Aufwand verbunden ist.
Was ist an pg_dump mit hohem Aufwand verbunden, wenn man erstmal die passenden Parameter für sich gefunden hat?
Zitat von
Alfredo:
2) Auf welchem Betriebssystem läuft in Zukunft der Postgress-Server?
a) Ich habe es unter Fedora aufgegeben mit Postgress zu arbeiten
- beim Update müssen alter und neuer Sever parallel laufen
b) Postgress wird derzeit intensiv gepflegt, was ja zunächst sehr
positiv ist, aber es wird dadurch ein regelmäßiger Updateauf-
wand verursacht
- wenn dann auch noch das Betriebssystem laufend hochgezogen
wird, dann geht das einem selbst und auch dem Kunden ganz
schön auf die Nerven
- es genügt eine einzige Fehlentscheidung und man hat richtig
Stress(z.B. hochziehen des Betriebssystem, ohne vorher einen
Dump der
DB gezogen zu haben)
Sowohl unter Windows, als auch Linux. Da es bei unseren Kunden nicht darauf ankommt, dass ihre Anlage rund um die Uhr läuft, haben wir bei Updates sicher nicht so den Stress, dass wir zwei Datenbank-Server parallel betreiben müssen. Außerdem werden wir sicherlich nicht jedes Mini-Update umgehend einspielen, sondern eher nur Major-Versions, sofern sie sinnvolle Verbesserungen bieten, von denen wir auch profitieren.
Zitat von
Alfredo:
3) Einfach die
DB zu wechseln ist Theorie.
- Postgress hat eine andere Schreibsyntax wie Firebird.
Was jetzt aber nicht wirklich ein Punkt gegen Postgres ist, sondern genauso gut einer gegen Firebird, bzw. eigentlich gegen so gut wie jedes
DBMS, oder? Mir ist schon klar, dass ein
DB-Wechsel nicht von heute auf morgen zu machen ist, aber von Postgres auf Firebird zu wechseln ist genauso schwierig, wie von Firebird auf
mySQL oder was auch immer, möchte ich mal behaupten. Oder ist Postgres soooo viel spezieller als die anderen genannten Systeme?
Zitat von
Alfredo:
4) Zeos ist nicht frei von Problemen
- lies einfach mal im ZEOS-Forum mit
Welche Software ist das schon? Zeos ist zumindest open-source, was bei mir persönlich ein besseres Gefühl hinterlässt, als auf eine closed-source Variante zu setzen. Nicht zuletzt auch ein weiterer Grund für Postgres.
Zitat von
Alfredo:
5) Heute ein neues Projekt mit D7 aufzusetzen ist auch nicht unproblematisch
- siehe die UTF8-Geschichte
Soll ich nun deswegen den Compiler wechseln? Letztendlich lag es ja nur an einem nicht gesetzten Client-Encoding. Und genau dafür ist die Option ja da, damit man sie auch verwendet. Eine Codezeile hat das Problem bereits gelöst, also ist es ja im Nachhinein eigentlich nicht mal wirklich ein Problem gewesen.
Zitat von
Bernhard Geyer:
Zitat von
Infect:
Auch das ist mir klar. Ich wollte wissen was du mit "Transparente Codierung UTF8 <->
Unicode" gemeint hast.
Transparent heißt das du außerhalb der Zugriffskomponenten nicht bemerkst ob die
DB UTF8 ist oder nicht (Außer das ohne UTF8 z.B. Kyrilisch und Arabisch nicht gemeinsam geht)
Durch das Setzen des Client-Encodings auf LATIN9 als Options-property innerhalb der Zeos-Connection, bemerke ich doch ausserhalb der Zugriffs-Komponente überhaupt nicht, welcher Zeichensatz von der Datenbank physikalisch nun verwendet wird. Man legt den Client-Zeichensatz an EINER Stelle in der Client-Anwendung fest (da nur eine Connection verwendet wird) und der Fisch ist geputzt?!?
Zitat von
Bernhard Geyer:
Zitat von
Infect:
Die Zeos-Connection unterstützt ca. 8 verschiedene Datenbanken, außerdem noch
ADO. Ich sehe nicht, wieso ich mich damit auf einen Anbieter, in diesem Fall Postgres, kastrieren würde?!?
Es unterstützt es, aber wenn du den Aufbau von
SQL-Anweisungen zu stark im Quellcode streust hast du hohen aufwand auf andere
SQL-Syntax zu wechseln.
OK, das leuchtet mir ein. Du würdest also eine Schnittstellen-
Unit vorschlagen, die z.B. Funktionen beinhaltet a la
function Select(const Select, From, Where: string): ResultSet;
Also dass die richtige und für das
DBMS passende
SQL-Syntax intern nur an einer Stelle zusammengestellt wird? Bei simplen
SQL-Statements der Form "SELECT spalte FROM table WHERE column = value;" mag das ja noch gut machbar sein, aber wenn die Statements mal richtig komplex werden? Man kann ja nicht für jede Eventualität eine Schnittstellen-Funktion schreiben? Was würdest du da vorschlagen? Wie gesagt, den Sinn davon sehe ich ein.