Am Sonntag, 12. Oktober 2003 16:43 schrieb Al Bogner:
Am Sonntag, 12. Oktober 2003 15:32 schrieb Ralf Schuchardt:
Hallo Al,
Am Sonntag, 12. Oktober 2003, 13:54:26, schriebst du:
Ich überlege nun schon seit langem wie ich meine Mac-Datenbanken nach Linux portieren soll und nehme mal wieder einen Anlauf :-)
Wenn es um etwas weitergehende Datenbankfeatures geht, empfehle ich auf jeden Fall einen Blick auf PostgreSQL zu werfen.
Ist es ein Problem vorerst MySQL und PostgreSQL gleichzeitig laufen zu lassen?
Nein, aber ich würde an Deiner Stelle gleich mit PostgreSQL loslegen. Die Einarbeitung ist etwas langwieriger, aber 1. ist die Dokumentation IMHO sehr gut 2. kann PostgreSQL sehr viel mehr als mysql (auf zum DB-Flame ;) - einen wesentlichen Aspekt hat Ralf schon genannt: Stored Procedures (z. B. für schnelle, DB-interne Konvertierungen) 3. sind die DB-Größen und Tabellengrößen, die Du genannt hast, bei gutem Design der DB nicht wirklich ein Problem - sowas ist noch handlich und niedlich zu nennen ;)
Ich bin mir nicht klar, ob ich die Datenbank via Browser ansprechen will. Einerseits wäre es flexibler, weil man dann die Datenbank browser- und OS-unabhängig einfach ins Intranet stellen könnte, andererseits scheint mir die Ergonomie zur schnellen Eingabe von vielen Datensätzen mit einem Browser nicht gegeben zu sein.
Welche Scriptsprache bzw. Frontends empfehlt ihr mir als nicht gelernten Programmierer? Kompatibilität zu Mac und Win wäre schön, aber nicht unbedingt notwendig.
Was für Vor- und Nachteile hätte Kylix gegenüber php oder perl?
PHP dient hauptsächlich zur Entwicklung von Web-Anwendungen, was auch wunderbar einfach funktioniert. Aber man hat halt keine Kontrolle über die Benutzeroberfläche und sowas "... bei der Eingabe bei Verlassen des _Feldes_ ..." geht damit natürlich nicht.
Ok, das hilft mir schon mal weiter. Dann scheidet PHP mal aus.
Kylix erlaubt die Erstellung nativer Anwendungen für Linux (und mit Delphi auch Windows) und ist ebenfalls sehr einfach zu programmieren. Leider bleibt der Mac aussen vor.
Auch unter OS X, das ist ja sehr unix-ähnlich? Das "alte" Mac-OS wird ja früher oder später aussterben.
Gibts denn ein Kylix (oder zumindest eine entspr. Runtime) für Mac von Borland? Ansonsten ACK - mit Borlands IDE kriegst Du alles aus einem Guss und das zugrunde liegende Object-Pascal kriegst Du relativ schnell auf die Reihe.
Perl ist für alles und nichts zu gebrauchen ;).
Manchmal dachte ich mir schon, dass es gut wäre, wenn ich etwas perl könnte. Ist das bei Datenbanken relativ langsam und umständlich?
IMHO nicht - aber mit Perl hast Du entweder das gleiche Problem wie mit PHP (als cgi auf Serverseite), oder Du musst Dich mit GUI-Programmierung (z. B. Perl::Tk) abplagen - was nach meiner Erfahrung tatsächlich als Plage definiert werden sollte.
Eine Überlegung wert sind vielleicht eine Reihe weiterer Toolkits, die eine plattformübergreifende Entwicklung erlauben: etwa QT (http://www.trolltech.com/) oder wxWindows (http://www.wxwindows.org/). Die werden zwar beide eigentlich in C++ programmiert, aber es gibt Bindungen für eine Reihe weiterer Programmiersprachen.
Das sind aber Toolkits, die C++ als Programmiersprache erwarten - nicht wirklich eine Empfehlung für einen Programmieranfänger.
Aber eigentlich würde ich wirklich Java empfehlen, da
- relativ gut zu programmieren - erlaubt Web- und Client-Frontends; d.h. du könntest bei richtiger Planung später wechseln - plattformübergreifend - meist ausreichend schnell (und vielleicht kannst du einen Teil der Logik auch in die Datenbank verlagern, schneller gehts dann nicht mehr)
Die Geschwindigkeit finde ich nicht so toll, wenn ich mir zB die Java-Programme zur Auerswald-Telefonanlage ansehe, außerdem stürzen die Programme oder Blackdown-Java(?) immer wieder ab bzw. es kommt mit diesen Programmen zu einer Kernel-Panic. Für die paar Datensätze mit Telefongesprächen reicht das, bei mehr bin ich aber skeptisch.
Versuchs mal mit dem SDK von Sun. Wenn Du die DB richtig aufbaust und den Tipp von Ralf beherzigst, die Logik, die in der Struktur der DB liegt, auch vom DB-Server verarbeiten zu lassen, solltest Du schon stabile und hinreichend schnelle Java-Clients hinkriegen. Java ist IMHO deutlich einfacher zu erlernen als z. B. C++ und bietet recht komfortable Klassen für den DB-Zugriff. Jan