Firebird und Window 10

[RSF]

Zitat von jobo:

OT
Postgres schlägt m.E. im Opensource Bereich alles was ich kenne. Gerade ist eine neue Version 9.6 erschienen. Seit ich das verfolge und nutze (ca ab V9.2), liefert jede Version tolle neue Features. Viele der Features gehen allerdings weit über eine 0815 Blackbox Datenhaltung hinaus. Wenn man RDBMS nur für einfache Datenhaltung (Zahlen, Texte, Datums) und Relationen nutzt, bemerkt man davon nur einen kleinen Teil.
Allein die Typen Stärke bspw. ist klasse, Robustheit, Funktionsvielfalt, Extensions, Performance, Indextypen, XML und JSON Unterstützung sind es ebenso.

/OT

Ich habe mir Postgres auch "angetan" .
Ich bin positiv überrascht wie Umfangreich dieses System ist. Auch eine komplette Administration ist von Haus aus dabei (PGAdminIII). Läuft problemlos alles unter Win 10.

[bra]

Also Firebird 2.5 funktioniert unter Windows 10 ohne Probleme. Zugriff auf die DB mit dem EMS SQL Manager. Wie es mit FB 3.0 aussieht weiss ich nicht, da viele Tools den noch nicht unterstützen.

[Rollo62]

Mit IbExpert und etwas Gefummel geht es jetzt auch.

Das Problem scheint das fehlende Zugriffsrecht auf die Security2.fdb zu sein, wenn es als App installiert wird.

Als Service geht es dann auch mit Fb3.0, der Service scheint auf security3.fdb zugreifen zu dürfen.

Jedenfalls scheinen alle möglichen FreeWare Tools nicht richtig zu arbeiten, vielleicht ist (noch) Java/JayBird nicht kompatibel.

Mit Delphi und IbExpert geht es jedenfalls.

Aber eine "coole" Installation ist das Handgefummel nicht (so wie ich das von V1.5 oder V2.0 kannte).
Das könnte auch etwas eleganter ablaufen, um den Erstinstall-Frust zu nehmen.

Z.B. läuft bei Postgre die Installation wunderbar durch, mit allen möglichen Tools, und ich habe nach 5 Min. ein OOOOhh-Erlebnis.
Während bei FB nach 2 Tagen der Wunsch zum Wegwerfen kommt.
Ich würde da dringenst mal die Usability des Setups überarbeiten, oder zumindest vernünftige Installationsanleitungen angeben ...

Unser Student hat sich daran die Zähne ausgebissen, und mit Java/Postgre läuft alles glatt.

Wenn man mit Delphi/Firebase bei den (Java)-Studenten etwas punkten möchte dann sollte das mehr plug-and-play werden, und vielleicht wäre damit auch der Nachwuchs gerettet


Rollo

[mkinzler]

In des Setup zum SR. 3.0.1 wurde ein Assistent zur Auswahl der Authentifizierung/Anlage Security3.fdb integriert.

[MichaelT]

Der FB3 hat einen neue Security implementiert. Du kannst den Modus zurückschalten auf FB 2.x wie im Thread bereits erwähnt.

New Authentication....

Ich habe den FB3 vor einiger Zeit in Beta mal unter die Lupe genommen und mir auch nicht erwartet, dass die Tools usw.nachgezogen wurden. Ich habe damals einfach die Security auf 2.x umgestellt.

Zitat von Rollo62:

Mit IbExpert und etwas Gefummel geht es jetzt auch.

Aber eine "coole" Installation ist das Handgefummel nicht (so wie ich das von V1.5 oder V2.0 kannte).
Das könnte auch etwas eleganter ablaufen, um den Erstinstall-Frust zu nehmen.



Rollo

[jobo]

ot

Zitat von Lemmy:

sicher liegt die Postrges Datenbank am Ende in einem Ordner. Aber eben nicht die einzelnen Bestandteile wie Daten, Index, Blob/Memofelder in einzelnen Dateien sondern eben als Inhalt einer Datenbank

ich war anfänglich sehr skeptisch, aber ich muss sagen, der Einstieg hat sich jetzt schon gelohnt. Bisher so einfach wie Firebird aber mit deutlich mehr Möglichkeiten.

Jein, die Postgres Datei "Kultur" ist m.E. nicht nicht vergleichbar mit bspw. Oracle oder MS, auch nicht mit FB. Es gibt nicht eine oder ein paar fette Files, wo alles drin ist. Da fliegt eine Menge Zeug rum, Details kenn ich nicht, muss aber auch nicht, steht hier beschrieben (und ist mir eigentlich egal, solange es funktioniert):
https://www.postgresql.org/docs/curr...le-layout.html

Und ja, Postgres funktioniert klassisch, einfach wie jede andere namehafte Db per SQL. Auch das ganze Drumrum, Connectivity usw. problemlos, filigrane Client-Zugriffskonfiguration (schon unabhängig von SQL Privileges).
On Top bekommt man sehr viel geschenkt, das es häufig erlaubt, auch exotische Probleme einfach zu lösen. Ich arbeite bspw. mit XML Daten in der Regel per SQL Zugriff, sehr angenehm. Und wenn das nicht reicht, findet man häufig gute Extensions.

@RSF
PGAdmin würde ich fast schon eher als Schwachstelle von Postgres sehen, es ist nicht super komfortabel, aber man kann alles machen, was man braucht.
/ot

[MichaelT]

Oracle wird cool, wenn man das Oracle eigene File System nimmt. Da rattert die Mühle noch mal gewaltig hurtiger. Stored Procedures kann man gegebenenfalls noch auf den gcc schicken oder den MS C/C++. Oracle auf Windows ist 'nur' ein Teil der ganzen Wahrheit. Oracle war nie etwas anders als ein Lösung für große Installation. Verkauft wurde die Lösungen klarerweise jeden glaubte er würde damit glücklich (in Wahrheit hatte sie keinen Kopierschutz ).

Bei der Oracle liegen genug Files herum keine Sorge. Die Starter Databases auf Oracle sind einfach konzpiert. Wenn du aber nur eine Starter DB brauchst reicht an sich Postgres, stimmt. Man kommt auch einer Starter Database heute relativ weit.

NexusDB ist ganz gut. Die Idee Bilder bspw. als Datentyp zu abstrahieren usw.. wäre ausbaufähig. In allgemeineren DB Werkzeugen wird zwar der BLOB erkannt in Fall des Bildes, aber man kommt klarerweise von BLOB nicht auf Bild. Das ist ein wenig ein Showstopper. Der Flash Filer war ein Recordserver - eine Art Btrieve, so in die Richtung.

Diese Server waren extrem effizient beim Zugriff auf Einzelsätze und klar definierte Datenmengen am besten entlang von passenden Indizes, da die Filter einfach aus einem packed record als binärer Suchstring konnten abgeleitet werden (Art QBE) und beinhart RAW. Seit dem die Varchars begannen zu dominieren, obwohl die intern auch auf fixe Größen ausgerichtet sind, ist die Methode der Strings fixer Länge nicht mehr so der Heuler.

Record Server sind aber keine SQL Datenbanken wie heut zumeist als Page-Server implementiert. Die haben bestenfalls einen SQL Überbau. In dem Sinne ist die NexusDB ein sehr luxuriöser Record Server.

Postgres ist von Open Source Datenbanken bei weitem der fortgeschrittenste Kompromiss. Die Ingres Leute waren nicht schlecht, die haben nicht das Geld gehabt in den 90ern mit Oracle mitzuhalten. Denen hat eine Milliarde gefehlt.

Geschäft war auch nicht viel zu machen. Dann kam die Postgres. Die hat sich über die Versionenverwaltung der Datensätze rausgemausert, denn es gab eine Periode in der die OO Konzepte wie Objekt-Versionierung hochgejubelt wurden.

Diese einfach Datenbanken haben ein massiven Vorteil. Man stelle sich vor ein Anwendung in einem Stahlwerk in dem auf einem Schirm alles abgebildet wird (in Delphi geschrieben) und eine simple DB auf der Serverseite. In dem Stahl ist eine hektischen Reparatur in Gange gleich zeitig schmiert Filesystem auf einem Server ab und nurmehr Lesezugriff geht. Support war nicht zugegen (schon länger her). Die User haben sich die Daten kopiert vom Server die Files auf einen anderen Server gelegt (Abteilungsserver), den Pfad verbogen und die Reparaturarbeiten gingen weiter. Bei solch einer Hektik ist immer besser, wenn die Materialentanhme gleich gebucht wird und dem richtigen Teil bei der Anlage wird zugewiesen. Um 3 Uhr morgens ...

Zitat von jobo:

ot

Zitat von Lemmy:

sicher liegt die Postrges Datenbank am Ende in einem Ordner. Aber eben nicht die einzelnen Bestandteile wie Daten, Index, Blob/Memofelder in einzelnen Dateien sondern eben als Inhalt einer Datenbank

ich war anfänglich sehr skeptisch, aber ich muss sagen, der Einstieg hat sich jetzt schon gelohnt. Bisher so einfach wie Firebird aber mit deutlich mehr Möglichkeiten.

Jein, die Postgres Datei "Kultur" ist m.E. nicht nicht vergleichbar mit bspw. Oracle oder MS, auch nicht mit FB. Es gibt nicht eine oder ein paar fette Files, wo alles drin ist. Da fliegt eine Menge Zeug rum, Details kenn ich nicht, muss aber auch nicht, steht hier beschrieben (und ist mir eigentlich egal, solange es funktioniert):
https://www.postgresql.org/docs/curr...le-layout.html

Und ja, Postgres funktioniert klassisch, einfach wie jede andere namehafte Db per SQL. Auch das ganze Drumrum, Connectivity usw. problemlos, filigrane Client-Zugriffskonfiguration (schon unabhängig von SQL Privileges).
On Top bekommt man sehr viel geschenkt, das es häufig erlaubt, auch exotische Probleme einfach zu lösen. Ich arbeite bspw. mit XML Daten in der Regel per SQL Zugriff, sehr angenehm. Und wenn das nicht reicht, findet man häufig gute Extensions.

@RSF
PGAdmin würde ich fast schon eher als Schwachstelle von Postgres sehen, es ist nicht super komfortabel, aber man kann alles machen, was man braucht.
/ot