PureBoard

Das ging ja flott. DANKE!
Ich brauche aber erst noch eine Mütze Schlaf bevor ich es mir anschauen kann.

Ja, die kleinsten Kerle wollen immer die größten Kisten schleppen. Und wundern sich dann wenn sie nicht die Treppe rauf kommen.
Vielleicht sollte ich kleinere Brötchen backen.

Ich sag es mal so. Das Umsetzen der Weiterleitung von SQL-Commands und den Ergebnissen sollte auch nicht so sehr das Problem sein. Problematischer sehe ich da eher die Absicherung der Verbindung bzw. den Zugang. Eine Zugriffskontrolle sollte der Server auf jeden Fall haben. Die Verbindung sollte sauber authorisiert werden.

Die Schnittstelle ist da wieder ein anderes Thema. Wenn die Motivation nur darin besteht, die Datenbanken mit PureBasic kompatibel zu halten, dann kann man das Protokoll zwischen Client und Server ja selbst festlegen. Wenn ich an einer Lösung arbeiten würde, dann würde ich über REST gehen und SQL abstrahieren. Der Vorteil wäre, das die Datenbank mit fast jeder Sprache funktionieren würde. Und PureBasic wäre mit dem cURL Header und ganz kurzer Einarbeitung auch mit der Datenbank kompatibel.

Für REST könnte man die Datenbank entweder mit FastCGI schreiben und hinter einen sehr schlanken Server spannen (Hiawatha z.B. hat gerade einmal 8,5 MB entpackt, ist portabel und unterstützt TLS-Zertifikate) oder verwende einen Embedded-Server wie Mongoose oder baue selber einen ein.

Aber wie gesagt. Wenn die Datenbank nur für PureBasic sein soll, dann kann man das Protokoll ja frei definieren. Achte aber wirklich darauf, noch mit Benutzernamen und Passwörtern zu arbeiten, damit es da keine bösen Überraschungen gibt

booooahhh,

erstmal vielen Dank für die ganzen kompetenten Antworten,
gut das ihr euch damit so gut auskennt, was mich betrifft.......naja

Ich möchte bzw. bin dabei eine Anwendung zuschreiben, die Artikel in verschiedenen Regalen erfassen soll,
das ganze soll in einem Intranet funktionieren, so das verschiedene Rechner auf die Datenbank zugreifen können.
Generell brauche ich dafür keine so mächtige Datenbank, vom Prinzip wäre SQLite super, aber kann ich die im Intranet nutzen??
Vom Gedankengang her ist das doch wie ein Heimnetzwerk, da müsste ich doch von Rechner a ein Programm auf Rechner b starten können, oder??
Im Moment bin ich dabei das ganze mit Postgresql zu realisieren, versuchen werde ich natürlich auch die portable Version, die hört sich gut an, aber wie gesagt, so mächtig braucht sie eigentlich nicht zu sein.
Müsste lediglich Daten ablegen, ändern, löschen und suchen können.

mfg

Hallo Baba_Smurf,

was das so gut auskennen angeht, was mich betrifft.......naja
Ich denke ich habe einen ganz guten Rundumblick. Aber wenn es in die Tiefe geht wird es schnell dünn.
Mit SQL habe ich mal vor über zehn Jahren für ein paar Wochen ein wenig gemacht.

Deine Anforderung klingt für mich nun ganz anders.
Das mit dem Intranet vereinfacht die Sache sehr.
Das mit dem Stick bzw. der CD bedeutet nur, dass auf den Geräten nichts installiert werden soll/darf?
Dann kannst Du meinen Ansatz für diese einfache Aufgabe vergessen.

Von Rechner a ein Programm c auf Rechner b starten geht, wenn auf Rechner b schon ein Programm d läuft das dies tut. Am naheliegensten wäre es, dass Programm d ein Lisener ist der als Dienst läuft - automatisch beim Hochfahren startet und im Hintergrund darauf wartet bis das Signal zum Starten von Programm c kommt.

Dann kommen noch andere Themen auf. Bei unterschiedlichen Rechnern wird der Stick z.B. unterschiedliche Laufwerksbuchstaben haben. Der Listener müsste also erst mal Suchen.

Aber unabhängig davon: Ja, ein zentraler SQL-Server und Clients mit einem portablen PB-Programm das darauf zugreift würde gehen. Das ist schon sehr oft so gemacht worden und da gibt es hier viel Erfahrung und Quelltexte, Tips, etc.

Es stellt sich nur die Frage wieso Du dafür nicht einfach einen fertigen SQL-Server (Firebird, PostgreSQL, oder was auch immer) nehmen willst.


Mein Vorschlag wäre aber:
Gehe noch einmal einen Schritt zurück.
Brauchst Du dafür wirklich eine Datenbank?
Muß auf den Clients wirklich ein Programm von Dir laufen?
Kannst Du davon ausgehen, daß es bei diesen Anforderungen bleibt, oder solltest Du mögliche zukünftige Anforderungen jetzt schon mit berücksichtigen?

Für mich klingt das nun nämlich eher nach einem kleinen Webserver.

Da kannst Du fertige Lösungen wie Apache, NGINX oder lighttpd nehmen. Unter Windows wird gerne auch der Internet Information Servicer von MS genommen, da er eine (i.d.R. nachinstallierbare) Komponente des Betriebssystems ist.
Normalerweise ist allein das richtige Aufsetzen eines Webservers schon eine Wissenschaft für sich - bei der ich auch nur an der Oberfläche gekratzt habe. Im Intranet ist die Hürde aber (weil nicht so sicherheitskritisch) nicht so groß.

Alle vier haben eine FastCGI-Schnittstelle - lassen sich also mit TroaX's PBExpress nutzen.
Das bedeutet es gibt auch dafür schon fertige Lösungen auf denen Du aufsetzen kannst.
Der Vorteil der Webserver-Variante ist, daß sie kein spezielles Programm auf dem Client benötigt.
Ein Browser genügt. Dadurch sparst Du Dir nicht nur die Programmierung und Pflege (Updates, Updateverteilung, Sicherstellen dass keine alten Versionen genutzt werden) der Client-Software. Sondern profitierst auch davon, dass es Browser auch auf Geräten gibt die sich via PB gar nicht programmieren lassen - Smartphones.

Ob Du nun wirklich eine Datenbank brauchst bezweifle ich bei der Aufgabenstellung.
Wenn doch kannst Du die auch von (D)einem FastCGI-PB-Programm aus ansprechen.
Eventuell genügt dann sogar das PB eigene SQLite. Wenn nicht siehe oben.

Eigentlich könntest Du sogar den Webserver selbst schreiben. Dann brauchst Du auch kein FastCGI.
Brauchbare Ansätze gibt es hier oder im engl. Board. Der wäre dann schlanker und für ein Intranet wohl ausreichend.

Zumindest etwas Lernaufwand hast Du aber auf jeden Fall. Und es gibt ein Thema bei dem Dir hier niemand komplett helfen kann: Das Design der Daten bzw. ggf. Datenbank.

Ich habe vor über 15 Jahren mal ein Webschop-Projekt für Büromöbel übernommen an dem u.a. ein angehender Wirtschaftsinformatiker schon lange gearbeitet hat. Neben vielen anderen gravierenden Fehlern (z.B. Access-DB) gabe es dort eine sehr große Tabelle mit z.B. einer Spalte "Armlehne J/N". Die galt dann auch für Tische, Container, Schränke, ...
Abgesehen davon gibt es auch Stühle bei denen man nicht nur wählen kann ob sondern auch welche Armlehne man gerne hätte.

Bei der Suche nach der richtigen Technik oder bei technischen Problemen gibt es i.d.R. schnell viele Antworten und Lösungen von außen. Bei Denkfehlern wird es schon schweiriger. Wenn die dann auch noch auf einem Tunnelblick beruhen gibt es nur noch einen der helfen kann - man selbst.

Ich habe die Postgres Portable getestet und eines ist sicher. Man muss sich mit der PSQL Konsole auskennen. Ansonsten ist das ganze eben nicht portable. Die portable Variante setzt die Arbeit mit PSQL ausnahmslos vorraus. Du kannst zwar pder pg_ident.conf den Benutzernamen des Rechners auf die Datenbankbenutzer mappen. Nur dann startet PSQL die Datenbank nicht und Postgres findet die Umgebungsvariable PGDATA nicht. Du musst dann leider beim start der Datenbank über das postgres-Executable imemr den weg zur Konfiguration als Parameter mit angeben.

Ansonsten funktioniert das ganze eigentlich problemlos. Wie gesagt ist halt nur die Bindung an PSQL, wenn du es portabel haben willst, ein wenig nervig ^^

Lege über PSQL einen neuen Nutzer an, gebe ihn ein Passwort als MD5-String, lege eine Datenbank an und weise diesem den neuen Benutzer zu. Und dann arbeite mit HeidiSQL an der neu erstellten Datenbank weiter. Auch zu empfehlen ist DBeaver. Das ist aber nicht mehr portabel.

Was Webserver angeht: Lighttpd ist als Binary nur für Linux verfügbar, Der IIS ist eine Hölle zu konfigurieren. Apache ist für Webserver das, was MySQL/MariaDB für Datenbanken ist. Unnötig riesig und aufgeblasen ohne Ende. NGINX ist eine gute Lösung. Aber ich favorisiere definitiv Hiawatha. Der Webserver ist ebenfalls direkt portable und lässt sich binnen wenigen Minuten konfigurieren.

Was PBExpress angeht: Bitte bedenkt dabei, das PBExpress das Ziel hat, die Entwicklung von Webanwendungen zu erleichtern. Sehr wichtige Features hat das Framework zwar schon. Aber es fehlst noch jede Menge. Es ist weder Feature-Fertig, noch kann ich aktuell den Einsatz in Produktiv-Systemen empfehlen. Allerdings habe ich was SQLite angeht eine gute Nachricht. SQLite lässt sich vor dem ausführen der PBExpress::RunServer() Prozedur in das Programm einhängen und bleibt während der kompletten Laufzeit eingehängt, was die Geschwindigkeit der Anwendung stark erhöht. Eines der größten Performanceprobleme von SQLite ist wie z.B. in PHP das ständige ein und aushängen der Datenbank.

Und noch eine Kleinigkeit: Die SQL-Datenbanken sind alles relationale Datenbanken. Da Speicherplatz und Rechenressourcen immer günstiger werden, wurde teilweise auf die Relationsfähigkeiten verzichtet und NoSQL-Datenbanken entwickelt. Reicht es dann nicht vielleicht sogar, wenn du deine "Datenbank" einfach über das Dateisystem aufbaust und dann auch zusammen mit dem RAM (Caching) ein ausgeklügeltes System baust? Gerade für Projekte, die relativ wenig zugriffe haben, kannst du dir das ganze Zeug mit Datenbanken eigentlich auch sparen. PureBasic besitzt 2 mächtige Varianten, um Daten Strukturiert in Dateien abzulegen. XML und JSON. So kannst du theoretisch dir eine eigene dokumentorientierte Datenbank in deinen Server basteln.

Wenn du aber bisher mit Postgres gearbeitet hast und deine Anwendung schon relativ weit ist, dann würde ich jetzt dabei bleiben. Die portable Version der Datenbank funktioniert und sie ist auch etabliert. Außerdem ist sie kompakt im Vergleich zu vielen anderen DBMS-Systemen. Ich würde wie gesagt dabei bleiben.

@TroaX
Danke für den Hiawatha-Tipp!
Der gefällt mir jetzt schon bevor ich ihn herunter geladen habe.
Abgesehen von schlank und portabel gefällt mir daran, daß ich da jemanden kenne, der sich damit auskennt, hilfsbereit ist und deutsch spricht.

Auszug aus Ubuntuusers (wo ich auch das erste mal auf den Server gestoßen bin!):

https://wiki.ubuntuusers.de/Hiawatha/
Hiawatha {en} ist ein schlanker Webserver, der sich durch einfache Konfiguration, hohe Performance, interessante Sicherheitsfunktionen und plattformübergreifende Unterstützung (Linux, BSD, Mac OS X und Windows) auszeichnet. Das Programm unterstützt verschiedene Interpreter-Sprachen (PHP, Perl, Python und Ruby), die Anbindung von Datenbanken wie MySQL oder MariaDB und die Internet-Protokolle IPv4 und IPv6. Bei HTTPS-Verbindungen kommt mbed TLS zum Einsatz, so dass Hiawatha vom Heartbleed-Bug Anfang 2014 nicht betroffen war.

Das bereits seit 2002 bestehende, aber relativ unbekannte Open-Source-Projekt reiht sich wie lighttpd und nginx in die Liste der Apache-Alternativen ein.

Sicherheitsfunktionen:

Wie eingangs erwähnt, bietet Hiawatha standardmäßig diverse Sicherheitsfunktionen gegen die wichtigsten Angriffsvektoren wie:

• Denial of Service (DoS) und DDoS
• SQL-Injection
• Cross-Site-Scripting (XSS)

an. Dabei können Angriffe nicht nur präventiv identifiziert, sondern auch aktiv abgewehrt werden. Während Apache für diesen Zweck nachladbare Module verwendet (siehe Apache/Sicherheit), sind diese Funktionen bei Hiawatha integriert.

Nur so einmal nebenbei ^^

uweb hat geschrieben:@TroaX
Danke für den Hiawatha-Tipp!
Der gefällt mir jetzt schon bevor ich ihn herunter geladen habe.
Abgesehen von schlank und portabel gefällt mir daran, daß ich da jemanden kenne, der sich damit auskennt, hilfsbereit ist und deutsch spricht.

WICHTIGER HINWEIS ZU HIAWATHA
Es kommt zu Fehlern bei großen Dateidownloads. Der Fehler kommt daher, das Hiawatha zwar Uploads cached, aber keine Downloads, wodurch das Senden von Dateien über z.B. WriteCGIFile fehlschlägt. Der Fehlschlag wird dadurch ausgelöst, weil die Datenübertragung zwischen Webserver und FastCGI-Anwendung in den allermeisten Fällen schneller ist als zwischen Client und Webserver. Wenn alle 3 Programme auf einem Rechner getestet werden, funktioniert es noch, so lange kein Download-Prompt verwendet wird. Will man sich aber den Speicherort der Datei aussuchen, dann wird sich der Browser mit dem Hinweis melden, das er die Zieldatei nicht mehr lesen kann. Ebenfalls ohne diesen Cache ist es nicht möglich, über WriteCGIFile und dem entsprechenden Header ein MP4-Video direkt abzuspielen. Denn das caching von größeren Videos führt zu fehlern aus genannten Gründen.

FastCGI funktioniert über NGINX dagegen hervorragend.

@TroaX
Danke für den Besser-Nicht-Hiawatha-Tipp!

Im Moment habe ich noch gar nicht angefabgen.
Es ist aber gut so etwas vorher zu wissen.
Da hätte ich sonst wohl lange nach einem Fehler in meinen Sourcen gesucht.

uweb hat geschrieben:@TroaX
Danke für den Besser-Nicht-Hiawatha-Tipp!

Im Moment habe ich noch gar nicht angefabgen.
Es ist aber gut so etwas vorher zu wissen.
Da hätte ich sonst wohl lange nach einem Fehler in meinen Sourcen gesucht.

Bin auch nur durch Zufall darauf gestoßen, weil ich in einem Testvideo nicht hin und herspulen konnte, da die Übertragung selbst Systemintern ab ca. 250 MB so asynchron wurde, das der Rest des Videos nicht mehr im Browser ankam. Bei kleineren Videos darunter klappte alles bestens. Als ich dann Dateien per attachment ausgeliefert habe (also nur Download), bekam ich beim Auswählen des Zielverzeichnisses immer den Hinweis, das die Quelldatei nicht mehr gelsen konnte. Ein Kuzer Test mit NGINX bzw. PHP-FPM unter Hiawatha bestätigen es. Selber Fehler mit PHP. Unter NGINX weder mit PHP-FastCGI noch mit meinem FastCGI. Der Fehler liegt also definitiv beim Server.

Alternative: http://nginx.org/

Ebenfalls einfach zu konfigurieren, ebenfalls portabel, aber deutlich mächtiger.

PS: Bin auch gerade an einem eigenen Embedded-Server am basteln. Soll kein großes Ding werden und auch nur die einfachsten Sachen ermöglichen. Aber es sind ja oftmals die kleinsten Dinge, die am meisten Spaß machen und auch am meisten bewirken ^^