PostgreSQL <-> Arctica

[Manfred]

Hi,

in Anbetracht der Tatsache, das Arctica vor der Türe steht (hat aber noch nicht geklingelt, oder sich sonst wie bemerkbar gemacht das es rein will) und somit unser Spektrum auf PostreSQL erweitert wird, würde mich einmal interessieren, wer sich denn bisher schon mit PostgreSQL beschäftigt hat hier aus dem Forum? Bzw. es demnächst vor hat.

Ich habe es mal auf 90 Tage gesetzt, weil dann ja die Chance besteht, Arctica in die Finger zu bekommen.

[Alfred]

Hallo Manfred,

ich habe mich von PostgreSQL wieder verabschiedet, weil es mich genervt hat.

Versuche dich mal mit dem Thema Update und Datensicherung zu beschäftigen.
Ist wirklich spannend, wenn man zu viel Zeit hat.

Ganz entscheidend ist auch auf welchem Betriebssystem der Server laufen soll.

Was Du auch nicht aus den Augen verlieren solltest, da Du ja für andere Leute
Programme entwickelst, dass SQL-Datenbanken vor Ort sehr viel Ärger
bereiten können. Wenn man nur einmal eine Datei einfach anlegen und wieder löschen
möchte, kommt richtig Freude auf.

Gruß
Alfred

[Jan]

Natürlich ist es klar, daß man für PostgreSQL mehr Verwaltungsaufwand benötigt als für eine einfache dbf. Man muß sich dann aber selber klar machen, was man braucht. Wenn ich nur eine kleine Rezeptverwaltung schreibe, dann ist das wohl mit Kanonen auf Spatzen geschossen. Aber bei einer kompletten Warenwirtschaft könnte das schon interessanter werden. Das muß jeder selber entscheiden.

Außerdem kann ich mir vorstellen, daß die Gemeinschaft der Xbase++-Entwickler da recht schnell Ideen entwickeln wird, wie man die PostgreSQL-Installation sauber und möglichst einfach in die normale Programminstallation integrieren kann.

Ich denke es wäre falsch, Arctica gleich komplett zu verdammen.

Jan

[brandelh]

Hi,

in Xbase++ nutzt man Befehle und Funktionen um DBF, Indexe etc. anzulegen und zu löschen.

Ich erwarte, dass für diese Aufgaben auch für SQL Server Funktionen enthalten sein werden.
Keinesfalls darf man von Seiten Alaskas davon ausgehen, dass dafür der Datenbankadministrator zuständig ist,
denn den gibt es bei den meisten nicht

Dieser Punkt wird sicherlich einer der wichtigsten bei der Frage des Erfolgs von Xbase++ 2.ff sein.
Wegen der Performance bei sauberer SQL Programmierung mache ich mir keine Sorgen.
Wenn ich an die ODBCDBE denke, befürchte ich eher, dass zuviel DBF Denke in PostgreDBE landet

[Jan]

Hallo Hubert,

schön wärs ja. Das würde in jedem Fall die Einstiegsschwelle wesentlich niedriger legen. Steffen hat ja auch schon mehrfach gesagt, daß Migrationstool geben wird, um bestehende Daten auf eine PostgreSQL bringen kann. Ich lasse mich mal überraschen, wie umfangreich diese Tools sein werden.

Jan

[brandelh]

Hallo Jan,

ein "Migrations-Tool" braucht man für den Übergang von der Alt in die Neuwelt ... danach nicht mehr.
Wenn die ordentliche Verwaltung in der neuen Welt sauber gelöst ist, ist es eine leiche Übung die Daten selbst zu migrieren.

[Alfred]

Hallo Jan,

die PostgreSQL-Installation sauber und möglichst einfach in die normale Programminstallation integrieren kann.

gerade dass ist eben technisch ein massives Problem. Wenn z.B Linux-Server richtig administriert werden, kann
eben nur ein authorisierter User auf die Verzeichnisse. Kein richtiger Administrator wird Dir dass per Programm
gestatten.

Dass was ich schrieb, ist nicht gegen Arctica und PostgreSQL gerichtet, sonder ein grundlegendes Problem
der Nutzung von SQL-Datenbanken beim Kunden.

Gruß
Alfred

[Tom]

Hallo, Hubert.

Wenn ich an die ODBCDBE denke, befürchte ich eher, dass zuviel DBF Denke in PostgreDBE landet

Wenn wirklich das eintreten soll, was versprochen wurde, nämlich die Migration von Artica mit nur wenigen Zeilen Code, kann es überhaupt nicht anders sein. Datensatzbasierte Navigation erhebt eben einzelne Datensätze, zeigt immer nur auf einzelne Datensätze, während SQL mengenbasiert arbeitet, also "Current Record Sets" zurückliefert. Eine Workarea mit aktiven Pointern auf bestimmte Records kriegt man m.E. nur hin, indem man vom Server eben auch einzelne Datensätze "abholt". Insofern bin ich eigentlich sicher, dass zumindest die erste Stufe von Artica ziemlich viel "DBF-Denke" enthalten wird. Ohne "DBF-Denke" geht's ja immerhin mit SQLExpress und anderen Tools.

[Alfred]

Hallo Hubert,

Ich erwarte, dass für diese Aufgaben auch für SQL Server Funktionen enthalten sein werden.

Da muss ich dich leider enttäuschen. Der SQL-Standard ist nur ein sehr kleiner Befehlssatz,
der aber unterstellt, dass der Server läuft und dass ist der ganz entscheidende Knackpunkt.

Auch die Datensicherung ist Teil der jeweiligen Datenbank und nicht Teil von SQL.

Ein einfaches Beispiel: In Firebird ist es z.B: ohne einen Kopfstand nicht möglich eine Kopie einer
Tabelle anzulegen.

Gruß
Alfred

[Jan]

Wir sollten uns hier nicht die Köppe einrennen mit irgendwelchen Spekulationen. Warten wir doch mal ab, was Alaska uns da liefert. Solange wir nicht wissen, was Alaska uns bietet und mitliefert, ist es müßig, hier solche Punkte kontrovers zu diskutieren.

Abgesehen davon: Wie oben schon gesagt gibt es sehr wohl Anwendungen, wo der administrative Aufwand gerne in Kauf genommen wird. Wenn das einmal erledigt ist dann ist der große Teil ja abgehakt. Es kommt drauf an, was gewünscht wird und erreicht werden soll.

Jan

[Alfred]

Hallo Jan,

Wir sollten uns hier nicht die Köppe einrennen mit irgendwelchen Spekulationen. Warten wir doch mal ab, was Alaska uns da liefert.

Ihr braucht euch nicht die Köppe einrennen. Ihr könnt dass alles was ich geschrieben habe ja im Vorfeld schon einmal
ausprobieren, dann seht ihr selbst wo die Probleme liegen.

Alaska kann doch nur den SQL-Standard abdecken. Die Administration der DB ist doch zeitlich gar nicht möglich.

Gruß
Alfred

[Jan]

Die Administration der DB ist doch zeitlich gar nicht möglich.

Alfred, noch einmal: Es gibt Programme, wo das absolut gerne in Kauf genommen wird, um die Vorteile einer SQL nutzen zu können. Das in Bausch und Bogen zu verdammen zeugt nicht wirklich von Professionalität. Oder von Unüberlegtheit.

Jan

[Manfred]

Hi,

dadadatdada ich liebe es.

Meine Themen sind doch immer wieder toll, oder?

Ich habe mir ein Buch über PostgreSQL aus dem I-Net heruntergeladen und lese es gerade mal mehr oder weniger oberflächlich durch. Nur mal so um zu sehen, worum geht es da überhaupt. Es ist natürlich etliches dabei, von dem ich sage: "Ja, prima, gut das wir darüber gesprochen haben!" Einige Dinge, so finde ich, sagen mir:"Prima, alte Socken, werden hier demnächst als Top verkauft." Andere wiederum:"Interessant, was es doch alles gibt, was eine Datenbank so übernimmt, unsereiner aber kompliziert nachbilden muß." Ich denke einmal, es wird dadurch evtl. deutlicher, was z.b. ADS so alles macht, oder was ich denke, was ADS so alles macht.
Auf jeden Fall ist es doch sehr gut, zumindest mal etwas darüber gelesen zu haben. Das hilft mir jetzt ein paar Dinge zu verstehen, warum sie so sind, wie sie sind.

[brandelh]

Hallo Hubert,

Ich erwarte, dass für diese Aufgaben auch für SQL Server Funktionen enthalten sein werden.

Da muss ich dich leider enttäuschen. Der SQL-Standard ist nur ein sehr kleiner Befehlssatz,
der aber unterstellt, dass der Server läuft und dass ist der ganz entscheidende Knackpunkt.
Auch die Datensicherung ist Teil der jeweiligen Datenbank und nicht Teil von SQL.

Ich habe zwar wirklich nicht viel mit SQL gemacht und dann meist mit SQLExpress, aber ...
Bei MySQL kann man SQL Dumps (also Komplettsicherungen mit Strukturbeschreibung) erstellen.
Diese sind SQL Anweisungen, die narülich einen laufenden SQL Server benötigen und
die Kennwörter für den Zugriff, aber dann zuerst alle Tabellen löschen (drop) und danach
wieder aufbauen und die Daten importieren.

So in der Art meinte ich das.

Wenn man einen Kunden hat, der einen SQL-Server-Admin hat, dann soll der natürlich
die Datenbank anlegen und Zugriffsrechte verwalten.
Bei meiner Beispielinstallation zu Hause habe ich ein MySQL Schema mit 3 Usern erzeugt.
Einer mit weitreichenden Admin Rechten NUR AUF DIESEM, einen mit normalen und
der letzte mit Nur Lesen. Der Rest wird in meinem PowerBasic Ladeprogramm erledigt.
Windows verwaltet den Zugriff auf das Programm, das Programm entscheidet je nach
Aufgabe und angemeldetem User (Windows) welchen MySQL-Schema-User es nutzt.

Wie gesagt, wenn ein Server Admin da ist und die Sicherheit wichtig ist,
muss der das von Hand erledigen, im Normalfall ist aber meine vereinfachte Version
immer noch wesenlich sicherer, als direkt in DBF oder anderen flat files zu schreiben

@TOM

was du schreibst muss so nicht sein (auch wenn ich es befürchte ) ...
Der SQL Server gibt ein Resultset zurück und die DBE könnte dieses dem
Programm gegenüber als normale Tabelle ausgeben (ähnlich wie QuickBrowse() oder Browse() auf Arrays).
Intern müsste er dann bei Änderungen (einstellbar) update commands absetzen.

Wie auch immer, lassen wir uns überraschen ...

@Manfred,

... lass http://WWW.WO-FINDE-ICH-DAS.DE wachsen

[Manfred]

Hubert,

Du schaffst es mal wieder mich vollkommen perplex in der Ecke stehen zu lassen. Was soll mir diese leere Seite sagen?

[Alfred]

Hallo Jan,

Das in Bausch und Bogen zu verdammen zeugt nicht wirklich von Professionalität. Oder von Unüberlegtheit.

Manfred hat nach Erfahrungen gefragt und die gebe ich hier wieder.

Ich arbeite seit 2 Jahren mit verschiedenen Datenbanken und wenn man alle Klippen kennt geht das auch.

Nur eben nicht so wie man dass mit einer *.dbf gewöhnt ist. Nicht mehr und weniger wollte ich mit
meinen Ausführungen sagen.

Ich habe zudem den Vorteil, dass ich den direkten Zugriff auf meine Technik habe, den Dienstleister wie
ihr eben nicht immer haben werdet.

Ich verdamme nichts in Bausch und Bogen, ich kann mir jedoch beim besten Willen nicht vorstellen, dass
Alaska eine Administrationsoberfläche für die Datenbank programmiert, wenn der Low-Level-Zugang schon
diese lange Zeit in Anspruch nimmt.

Hier mal ein kleine Beispiel aus der Praxis:

Laut Sybase kann man den ADS und Foxpro parallel betreiben.

Als ich meine erste kleine Maske fertig und am laufen hatte, musste ich feststellen, dass der Befehl
"pack" die Datei kopiert und umbenennt. Fatal an der Geschichte ist, dass danach der ADS die Datei
nicht mehr kennt, weil der Owner der User ist, der den "pack" abgesetzt hat. Der ADS aber nur Dateien
akzeptiert die dem Advantage gehören. Betriebssystem des Servers Linux mit Sambazugriff.

Ich kann nur jedem, der beabsichtigt zukünftig mit einer DB zu arbeiten, raten sich einen Server zu installieren,
bitte keinen Embedded und mit einem Administrationstool zu bearbeiten, dann versteht ihr sicher besser
von was ich hier spreche. Ich könnte ein ganzes Buch damit füllen.

Gruß
Alfred

[Manfred]

Alfred,

Jan hat das auf keinen Fall böse gemeint. Der will doch nur spielen.

Nee, mal im Ernst, wenn Du ein ganzes Buch damit füllen kannst, dann weißt Du ja, was demnächst auf Dich zukommt, oder zukommen könnte.

[brandelh]

Hubert,
Du schaffst es mal wieder mich vollkommen perplex in der Ecke stehen zu lassen. Was soll mir diese leere Seite sagen?

Das war ein Wink mit dem Zaunpfahl, dass du uns die Stelle per LINK bekannt gibst, wo du
dein PostgreSQL eBook bekommen hast ...

@ Alfred,

ich meinte NICHT, dass Alaska uns eine GUI Oberfläche zur Verwaltung von SQL Servern zur Verfügung stellen soll !
Sowas gibt es ja in vielen Formen.

Ich meinte, dass Befehle wie z.B. dbStruct(), dbCreate(), OrdCreateIndex() etc. analog für die
Erstellung und automatische bzw. interne Verwaltung einer PostgreSQL Datenbank - nicht des Servers selbst -
benötigt werden. Vor einer GUI muss man sitzen (Fernwartung ?) ich möchte aber vom aus Programm auf dem
SQL Server Tabellen anlegen, ändern, anpassen etc.

[Manfred]

http://www.postgresql.org/docs/books/pghandbuch.html.de

[Alfred]

Hallo Huber,

Vor einer GUI muss man sitzen (Fernwartung ?) ich möchte aber vom aus Programm auf dem
SQL Server Tabellen anlegen, ändern, anpassen etc.

meine Erfahrung ist die, dass man erst mit dem Tool sich den SQL-Befehl zusammenbastelt und
dann erst in das Programm einsetzt.

Ich meinte, dass Befehle wie z.B. dbStruct(), dbCreate(), OrdCreateIndex()

Ich bin ja nicht der Entwicklungschef von Alaska ,
ich gehe aber davon aus, dass man "nur" den SQL-Standard abbilden wird. Dass tun alle
meine Zugriffskomponenten, die ich für Delphi getestet oder auch gekauft habe und
die bilden die Datenbank dann alle in einem Dataset ab, welches wiederum die
Schnittstelle zur Anzeige und zur Bearbeitung ist.

Gruß
Alfred

[Alfred]

Hallo Manfred,

Du benötigst kein PostgreSQL-Buch. Viel wichtiger ist ein SQL-Buch, dass nur den reinen
SQL-Standard abbildet. Leider gibt es Bücher, die einem erst sehr spät darauf hinweisen,
dass sie eine bestimmte Datenbank verwenden und reiten dann auf den Besonderheiten
dieser Datenbank herum.

Gruß
Alfred

[Jan]

Alfred,

warum reitest Du eigentlich immer auf "reinem SQL" so rum? Steffen hat ganz eindeutig gesagt daß Alaska die PostgreSQL gewählt hat, weil die die erweiterten Fähigkeiten hat, die Alaska unterstützenswert sieht. Wenn das nicht so wäre, dann hätte das ja auch MySQL nehmen können oder MSSQL.

Jan

[Manfred]

Hi Jan,

ich meine mich erinnern zu können, das auch irgendwie das Wort Lizenzbedingungen gefallen ist. Die scheinen wirklich bei PostgreSQL eindeutig zu sein: "Für alles und jeden und für alle Bedingungen frei nutzbar" Das ist bei den anderen nicht der Fall.

[Jan]

Hallo Manfred,

mag sein. Daran kann ich mich jetzt nicht mehr erinnern. Aber auf jeden Fall war ein wichtiges Argument auch das, daß ich oben angeführt habe. Er hat damals auch Beispiele gebracht, aber die weiß ich nicht mehr.

Jan

[Alfred]

Hallo Jan,

warum reitest Du eigentlich immer auf "reinem SQL" so rum?

leidvolle Erfahrung. Der reine SQL-Befehlssatz ist ein weltweit genormter Standard und damit bei jeder
SQL-Datenbank gleich. Somit kann ich, wie Du schon richtig angemerkt hast, auf eine andere Datenbank
umsteigen und dazu gibt es leider des öfteren Anlass(z.B. MySQL Lizenzrecht bei gewerblicher Nutzung,
Sortierung......).

Steffen hat sicher bei seinen Aussagen die direkte Schnittstelle zwischen der Programmierumgebung
und der Datenbank im Auge. Da hören aber meine Kenntnisse derzeit vollständig auf. Ich denke hier
geht es den Profis sicher um die Problemkreise Stabilität der Schnittstelle, Dokumentation, wie oft
wird ein Update angeboten.

Gruß
Alfred