mit welche Programmiersprache ist es am einfachsten unter Windows Desktop-Anwendungen zu erstellen, die auf externe Datenbanken zu greifen?
Wenn ich z.B. Lazarus mit MySQL nutzen will, mu ich f r die jeweilige MySQL-Version die immer gleichlautende *.dll ins Windows-Verzeichnis kopieren (bei Zugriff auf verschiedene MySQL-Versionen ziemlich mistig)
"Delphi XE2" kann erst ab der "Enterprise" von Haus aus MySQL,
davor nur mit Fremdkomponenten.
So wie es im Moment aussieht, wird "Delphi XE3 Pro" gar nicht mehr auf externe Datenbanken zugreifen k nnen - auch nicht mit Fremdkomponenten,
weil es die Eula verbietet.
Wie sieht es bei den anderen Sprachen aus?
M ssen dort auch Dlls ins Windows-Verzeichnis?
Und muss man f r jede Datenbank alles neu machen oder ndert man nur den Connector?
> mit welche Programmiersprache ist es am einfachsten unter Windows > Desktop-Anwendungen zu erstellen, die auf externe Datenbanken zu
> greifen?
Am einfachsten mit einer, die in ein fertiges Datenbankfrontend mit
einem breiten Zugriff auf Backends integriert ist. Wie z.B. MS-Access,
OO-Base u. .
> Wenn ich z.B. Lazarus mit MySQL nutzen will, mu ich f r die jeweilige
> MySQL-Version die immer gleichlautende *.dll ins Windows-Verzeichnis > kopieren (bei Zugriff auf verschiedene MySQL-Versionen ziemlich
> mistig)
Man hat mit allen Programmiersprachen mindestens die Alternativen, auch
die windowseigenen APIs zu benutzen oder das Backendprotokoll selbst zu
implementieren.
> So wie es im Moment aussieht, wird "Delphi XE3 Pro" gar nicht mehr auf
> externe Datenbanken zugreifen k nnen - auch nicht mit
> Fremdkomponenten, weil es die Eula verbietet.
Entweder man aktzeptiert so bescheuerte Lizenzmodelle und zahlt f r die
Komponenten die man braucht oder man nimmt dies zum Anlass, diese
Programmierumgebung gar nicht erst in Erw gung zu ziehen.
> Wie sieht es bei den anderen Sprachen aus?
> M ssen dort auch Dlls ins Windows-Verzeichnis?
Die Backendanbindung ist kein Programmiersprachenproblem.
> Und muss man f r jede Datenbank alles neu machen oder ndert man nur
> den Connector?
Ohne Abstraktionsschicht ist alles was ber select feld from tabelle
hinausgeht backendspezifisch und zieht bei jedem Datenbankwechsel viele nderungen nach sich. Wenn aus Stabilit tsgr nden die komplette
Datenlogik im Backend steckt, kommt ein Wechsel einer Neuerstellung
gleich.
> mit welche Programmiersprache ist es am einfachsten unter Windows
> Desktop-Anwendungen zu erstellen, die auf externe Datenbanken zu greifen?
Du fragst das in d.c.d.misc und wei t selbst schon die Antwort. Am einfachsten ist es immer in der Programmiersprache, die einem vertraut ist und die man sicher beherrscht.
> Wenn ich z.B. Lazarus mit MySQL nutzen will, mu ich f r die jeweilige
> MySQL-Version die immer gleichlautende *.dll ins Windows-Verzeichnis
> kopieren (bei Zugriff auf verschiedene MySQL-Versionen ziemlich mistig)
> "Delphi XE2" kann erst ab der "Enterprise" von Haus aus MySQL,
> davor nur mit Fremdkomponenten.
Leider fragtest Du nach Datenbanken und f hrst MySQL an. Dabei hast Du bersehen, dass Delphi in (fast) allen Versionen, sowie auch Lazarus, nativen Zugriff auf viele freie (und erwachsene) Datenbanken bietet. Der Zugriff ber die ODBC-Treiber von Windows ist ebenfalls m glich.
> So wie es im Moment aussieht, wird "Delphi XE3 Pro" gar nicht mehr auf
> externe Datenbanken zugreifen k nnen - auch nicht mit Fremdkomponenten,
> weil es die Eula verbietet.
Willst Du Lazarus nutzen oder richtig Asche in Delphi investieren?
> Wie sieht es bei den anderen Sprachen aus?
> M ssen dort auch Dlls ins Windows-Verzeichnis?
Ja.
> Und muss man f r jede Datenbank alles neu machen oder ndert man nur den
> Connector?
Nur den Connector zu ndern - der Traum jeden Programmierers.
Solange Du nur einfach(st)es SQL verwendest, k nnte es funktionieren. Guck Dir einfach mal die Implementation der SQL-Standards in die heute zur Auswahl stehenden freien Datenbanken an. Egal wo Du die Datenlogik ansiedelst - ob in der DB oder in Deinem Programm - ein Wechsel ist so ohne weiteres kaum m glich - zumindest ohne Abstraktionsschicht. Da wirds dann aber auch schon kompliziert - Du fragtest ja nach einfachen L sungen :-)
mit welche Programmiersprache ist es am einfachsten unter Windows
Desktop-Anwendungen zu erstellen, die auf externe Datenbanken zu greifen?
Wenn ich z.B. Lazarus mit MySQL nutzen will, mu ich f r die jeweilige
MySQL-Version die immer gleichlautende *.dll ins Windows-Verzeichnis
kopieren (bei Zugriff auf verschiedene MySQL-Versionen ziemlich mistig)
"Delphi XE2" kann erst ab der "Enterprise" von Haus aus MySQL,
davor nur mit Fremdkomponenten.
So wie es im Moment aussieht, wird "Delphi XE3 Pro" gar nicht mehr auf
externe Datenbanken zugreifen k nnen - auch nicht mit Fremdkomponenten,
weil es die Eula verbietet.
Wie sieht es bei den anderen Sprachen aus?
M ssen dort auch Dlls ins Windows-Verzeichnis?
Und muss man f r jede Datenbank alles neu machen oder ndert man nur den
Connector?
MfG
Heiko
C# oder VB.NET in Verbindung mit MS-SQL-Server ist eine ideale Kombination. Der Zugriff auf MS-SQL ist bereits im .NET integriert, die SQL-Version ist dabei nahezu egal (solange man keine Spezifika der jeweiligen Version nutzt).
Das Unterst tzen mehrere Datenbanken ist ein hehres Ziel, was in der Praxis wenig gedankt oder gew nscht wird. Die Konzentration auf eine bestimmte DB - und das perfekte Beherrschen dieser - f hrt oft schneller zum Ziel.
Am Thu, 30 Aug 2012 19:46:06 +0200 schrieb Heiko Rompel:
[verschiedene Fragen rund um Datenbankapplikationen]
Am besten fängt man mit einer hinreichend genauen Spezifikation an. Wenn die festgezurrt ist, kann man auch beginnen, die Fragen nach Programmiersprachen (nachrangig), Schichtung (Client-Middleware-Server-DB Server) und Verteilung der Logik (wichtig!) und der zu benutzenden Datenbank gezielt stellen und, ggf. mit kleineren Tests oder vergleichen mit existierenden Systemen, beantworten.
> So wie es im Moment aussieht, wird "Delphi XE3 Pro" gar nicht mehr auf > externe Datenbanken zugreifen können - auch nicht mit Fremdkomponenten,
> weil es die Eula verbietet.
Huch? Kann ich kaum glauben, die sind doch nicht total verblödet und sägen sich einen von den Ästen ab, auf denen sie sitzen.
Die restlichen Fargen sind einfach zu früh gestellt und zu unpräzise in der Zielvorgabe, um sie konkret zu beantworten.
Willst Du/Chef die Datenbank wechseln können? -> Logik in der Zwischenschicht auf dem Server oder im CLient oder ein Persistenz-
Framework benutzen.
Demgegenüber steht die Forderung nach hoher Geschwindigkeit, geringem zu übetragenen Datenvolumen über's Netz und bestmöglicher Integrität -> Logik in der DB in deren proprietärer Sprache, Client relativ simpel.
Usw.
da wollte ich wohl das Pferd vom falschen Ende auszäumen.
Ich dachte, bei der Vielzahl der Programmiersprachen mit Ihren Stärken und Schwächen hätte sich eine als besonders gut für egal welche Datenbank hervorgetan.
Ich werde mich dann mit dem was ich jetzt habe und dem Thema Datenbanken
weiter aus einander setzen und schauen, wie dort Anbindungen an MySQL, Microsoft SQL, Firebird und Co umzusetzen sind ohne das man viel an der Oberfläche und der dafür benötigten Komponenten ändern muss.
Am Wed, 05 Sep 2012 11:12:39 +0200 schrieb Heiko Rompel:
> Ich werde mich dann mit dem was ich jetzt habe und dem Thema Datenbanken
> weiter aus einander setzen und schauen, wie dort Anbindungen an MySQL,
> Microsoft SQL, Firebird und Co umzusetzen sind ohne das man viel an der
> Oberfläche und der dafür benötigten Komponenten ändern muss.
Für grundsätzliche Informationen zu dem Themenkreis könntest Du mal die frei verfügbaren Aufsätze von Scott Ambler lesen. HAben zwar viel Werbung für seine Bücher, aber trotzdem wertvollen Inhalt.
> mit welche Programmiersprache ist es am einfachsten unter Windows
> Desktop-Anwendungen zu erstellen, die auf externe Datenbanken zu greifen?
Wie w rs mit Java/JDBC?
[...]
> So wie es im Moment aussieht, wird "Delphi XE3 Pro" gar nicht mehr auf
> externe Datenbanken zugreifen k nnen - auch nicht mit Fremdkomponenten,
> weil es die Eula verbietet.
> Und muss man f r jede Datenbank alles neu machen oder ndert man nur den
> Connector?
Man w hlt Oracle als DB, findet jemanden der die horrenden Lizenzkosten
bezahlt und ist ein gl cklicher Entwickler ;-) SCNR
Gru
Peter
-- Climb the mountain not to plant your flag, but to embrace the challenge,
enjoy the air and behold the view. Climb it so you can see the world,
not so the world can see you. -- David McCullough Jr.
> Am Wed, 05 Sep 2012 19:12:57 +0200 schrieb Peter Schneider:
>> Am 30.08.2012 19:46, schrieb Heiko Rompel:
>>> Und muss man für jede Datenbank alles neu machen oder ändert man nur
>>> den Connector?
>> Man wählt Oracle als DB, findet jemanden der die horrenden Lizenzkosten
>> bezahlt und ist ein glücklicher Entwickler ;-) SCNR
> Ah, hat Orakel jetzt eine Embedded Version? Und eine, die auch auf 'nem
> Netbook läuft? Prima, da warte ich ja schon lange drauf ...
Um Embedded ging's ja in dem OP gar nicht.
Würde man da nicht eher sowas wie Berkeley DB (also auch Oracle) nehmen, oder allenfalls SQLite?
Obwohl, Oracle 11gR2 Enterprise Edition auf dem Smartphone, um das Telefonbuch zu verwalten, das wäre doch eigentlich ganz nett. Wenn man besonders viele Kontakte hat, könnte man z.B. die Partitioning Option verwenden etc. Der Gedanke hat was ;-))
Gruß
Peter
-- Climb the mountain not to plant your flag, but to embrace the challenge,
enjoy the air and behold the view. Climb it so you can see the world,
not so the world can see you. -- David McCullough Jr.
Jetzt schon, aber dort geht man nicht auf die verschiedenen XE3-Versionen ein. Wenn es hei t das XE3 das und das kann, ist das f r ie Enterprice-Version ja zutreffend.
Am Wed, 05 Sep 2012 20:39:41 +0200 schrieb Peter Schneider:
> Obwohl, Oracle 11gR2 Enterprise Edition auf dem Smartphone, um das
> Telefonbuch zu verwalten, das wäre doch eigentlich ganz nett. Wenn man
> besonders viele Kontakte hat, könnte man z.B. die Partitioning Option
> verwenden etc. Der Gedanke hat was ;-))
Stimmt. Nur würde der Tornister mit SAN und Blei-Gel-Akkus vielleicht etwas schwer ... :D
> Jetzt schon, aber dort geht man nicht auf die verschiedenen
> XE3-Versionen ein. Wenn es heißt das XE3 das und das kann, ist das für
> ie Enterprice-Version ja zutreffend.
Als Nutzer von FPC & Lazarus (neben anderm) habe ich die Diskussion nicht verfolgt, aber da gab es wohl noch Änderungen, daß die Einschränkung der DB-Zugriffslizenz nur für eine bestimmte Zugriffstechnik gelten soll.
Wer's genau wissen will muß mal bei Borland/Inprise/Borland/CodeGear/
Embarcadero (oder wie der aktuelle Name ist) nachgucken ...
