AppSheet (Google Workspace): Einbinden einer externen Datenbank

Habe gerade vom Google Support erfahren, dass unser Paket "Appsheet Core" keine Anbindung externer Datenbanken erlaubt.

Möglich ist das erst im kostspieligen Paket "Appsheet Business". Das Kleingedruckte : ( Mist.

In der Appsheet Community hatte man mir auch Postgres empfohlen, obwohl dort bekannt war, dass wir nur "Appsheet Core" haben. Pech.

Also kann ich Postgres für Appsheet knicken. Mir bleibt nur, Postgres zum Üben lokale zu installieren. Aber ohne Apps ist das Üben natürlich weit weniger attraktiv.
 
Werbung:
Ja die schöne neue Welt in der Cloud. AppSheet ist sicherlich ganz nett und für Kleinigkeiten würde ich mir das auch mal anschauen. Aber ich warne auch oft vor zu viel Abhängigkeiten. Einen Webseiten-Hoster wird man immer finden aber eine SaaS-Lösung wie AppSheet kann man nicht selber hosten und du kannst das auch nicht einfach wo anders hin migrieren wenn du, aus welchen Gründen auch immer, mal nicht mehr bei Google sein möchtest.

Es kommt also auf den Anwendungsfall an. Einen geschäftskritischen Prozess würde ich nach Möglichkeit nicht von AppSheet abhängig machen.
 
Ja, Abhängigkeiten muss man definitiv im Auge behalten.

Das Hauptmotiv für meinen Wunsch Postgres zu verwenden, war das Bewahren von Unabhängigkeit.

Der Kern einer App ist das Datenbankschema. Ich wollte es auf einer FreeOpenSource-Datenbank entwickeln.

Die Hoffnung war, dass es in Zukunft auch mal selbst zu hostende freie oder mindestens bezahlbare Software geben könnte, die das kann, was Appsheet kann.

Eine Analagie ist ja ein CMS für Websites. Es erlaubt Nutzern ohne Kenntnisse im Programmieren, in der Markupsprache HTMl und der Gestaltungssprache CSS selber Websites zu erstellen.

Mit allen Einschränkungen der Möglichkeiten, die bei "No Code" immanent sind.
Ich kann das für HTML und CSS gut beurteilen, weil ich das sehr gut im Quelltext beherrsche.

Wenn ich euch richtig verstehe, liest hier niemand mit, der andere "No/Low-Code" und zu Appsheet vergleichbare Ansätze ausprobiert hat und was dazu sagen kann.

Eines möchte ich klarstellen: ich finde es ehrenwert von Google, dass sie sowohl Workspace als auch Appsheet Core für NonProfits kostenfrei bereitstellen. Darüber freuen wir uns. Insbesondere Workspace ist extrem nützlich in unserem gemeinnützigen Verein.
 
Eines möchte ich klarstellen: ich finde es ehrenwert von Google, dass sie sowohl Workspace als auch Appsheet Core für NonProfits kostenfrei bereitstellen. Darüber freuen wir uns. Insbesondere Workspace ist extrem nützlich in unserem gemeinnützigen Verein.
Naja, das Prinzip bzw. das Problem hat @ukulele schon erklärt. Deine Gedanken zur DB sind richtig, aber am anderen Ende gehst Du halt in die Vendor Lock Falle.
Google macht und bietet viele tolle Sachen. Das ist im Idealfall praktisch und auch kein Problem. Wenn Google bspw. seinen Drive Dienst einstellen würde, nimmt man halt einen anderen. In Deinem Fall ist es leider nicht so. Google ist nicht selbstlos, genausowenig wie Apple, Microsoft oder Amazon. Man darf getrost darauf vertrauen, dass sie sehr(!) genau wissen, was sie umsonst anbieten und warum. Wenn ich bspw. sehe, wieviel Leute hier neuerdings mit Access am Start sind, dann wünsche ich denen allen, dass sie nicht bald ziemlich enttäuscht sind. Aber MS macht halt mit seiner Marketing Abteilung gute Arbeit. Muss man auch neidlos anerkennen.

Auch wenn es nicht 100 pro passt, würde ich Dich bezüglich Deiner Vorkenntnisse noch mal an das Angebot von Andreas erinnern.
cypex
Ist zwar kommerziell, aber es kommt Deinem Bedarf und offenbar Deinen Fähigkeiten (HTML, ..) sehr nahe. Und es basiert vollkommen auf dem gegebenen Datenmodell, database driven, also Deinem favorisierten Ansatz. Ggf. gibt es da einen Non Profit Ansatz zur Nutzung. Am besten einfach fragen.
Und falls das nicht in Frage kommt, wenn ich mich richtig erinnere, basiert cypex auf PostgREST, womit Du neben einer FOS DB auch noch einen FOS Rest Server geschenkt bekommst, der handinhand mit Postgres arbeitet.
 
Hi.

Andreas hatte ich schon privat angeschrieben, ob es für cypex Ansätze für Non Profits gibt. Leider nicht.

Sie hosten auch kein Postgres in der Cloud. Ob PostgREST Documentation eine sichere Option für den Zugriff von außen bietet, kann ich mangels Kenntnissen nicht sagen. Ich habe keinerlei Erfahrung in der Serveradministration und möchte in dem Bereich nicht aktiv werden. Viel zu anspruchsvoll, als Laie für Sicherheit sorgen zu können.

Unabhängig vom oben Gesagten benötige ich eine Zugriffsverwaltung für maximal 30 Vereinsmitglieder.

Ob es irgendeine Option gibt, sowas sehr kostengünstig hinzubekommen: keine Ahnung.

Sie haben in Berlin für diese Saison so stark die Mittel gekürzt wie noch nie. Wir haben einfach kein Budget und hoffen überleben zu können. Ich sage das nicht um hier zu jammern, nur damit der Kontext klar ist.
 
Unabhängig vom oben Gesagten benötige ich eine Zugriffsverwaltung für maximal 30 Vereinsmitglieder.
Gut, dann muss man vielleicht auch mal hinterfragen, wie groß die Kanone sein soll, mit der man auf die Spatzen schießt.*
Ich meine, ich hatte schon angeregt, nach etwas fertigem zu schauen. Deine funktionalen Anforderungen sind nicht sehr hoch und ehrlich gesagt verstehe ich nicht ganz, warum Du vor dem gesamten Hintergrund überhaupt auf diese Art an die Sache ran gehst.

Internetsuche 3.Treffer von oben:
Demo OMOC.interactive - Your customer access - Registration

* Damit ist nicht die Größe der Lösung gemeint, sondern der Aufwand, eine handgefertigte Individualsoftware zu erstellen. (Eingedenk, dass es Dutzende solcher Lösungen gibt)

Wenn sich irgendein Softwareprofi für 20 Euro pro h findet (finden sollte) und der arbeitet dafür 12h, dann ist für das gleiche Geld die Software oben für 1 Jahr gemietet. Man kann natürlich ehrenamtlich auch für 0 Euro die Stunde arbeiten, theoretisch, aber ob es zu einer wirklichen Lösung führt und ansatzweise den persönlichen Aufwand rechtfertigt, wage ich zu bezweifeln.
 
Gut, dann muss man vielleicht auch mal hinterfragen, wie groß die Kanone sein soll, mit der man auf die Spatzen schießt.
Meine Intention war nie mit größter Effizienz eine einzelne konkrete Aufgabe (Raumnutzungsapp) zu lösen. Das würde natürlich in der Tat mit einer fertigen Software am besten gehen.

Ich hatte es hier ja schon erwähnt: mich reizt das Erlernen der Datenbankmodellierung an einem praxisnahen Projekt und mich reizt, herauszufinden, was mit Anwendungen wie Appsheet (wenn eine saubere Datenbank die Basis bildet) mittlerweile geht, wo die Fallstricke liegen, etc.

Hier im Forum ist Appsheet kein Thema. Ist ja kein Problem.
 
Als Lernprojekt kann man sowas natürlich machen. Rein vom Betriebswirtschaftlichen Standpunkt her hat @dabadepdu natürlich Recht. Machst du halt bei deinem AG ein paar Überstunden, erhöhst das BIP, zahlst Steuern, bekommst Geld, spendest das dem Verein, bezahlst die Software und sparst dabei Lebenszeit :)
Hier im Forum ist Appsheet kein Thema. Ist ja kein Problem.
Das Forum ist recht klein, was regelmäßig aktive Benutzer angeht. Jeder hat irgendwo seinen Schwerpunkt. Das kann man gut am Access Forum sehen. Bis vor kurzem gab es da viele Fragen aber wir haben uns eher einen abgebrochen weil keiner so richtig viel mit Access macht. Seit einiger Zeit ist @andyfau dort aktiv und ich freue mich, das er viele Beiträge beantwortet zu denen ich nie im Leben etwas sinnvolles beitragen könnte.

Insofern schön, wenn du hier mit ließt. Wenn ich mal AppSheet austeste, dann weiß ich, wo ich jemanden Fragen kann.
 
Werbung:
Ich gebe gerne an euch weiter, was ich zu AppSheets gelernt habe : )
Am besten eine PM, weil ich hier ja nicht permanent mitlese.

Eine für mich sehr erstaunliche Sache kann ich schonmal teilen:

Die Software Appsheet und Gsheet stammen beide von Google.
Gsheet (also Tabellen) können in Appsheet als Datenbasis verwendet werden.

Appsheet bietet genau 33 Datentypen an.
Gsheet bietet genau 11 an.

In Appsheet müssen (selbstverständlich) Datentypen angegeben werden.
Sie können von denen der eingebundenen Datenbasis aus Gsheet verschieden sein.

Es gibt keinerlei Automatismus, keine systematische Prüfung, keine spezifischen Warnmeldungen, wenn sie verschieden sind.

Das war für mich total überraschend, da ich fest davon ausging, dass für eine Stabilität der App es höchste Priorität hat, Probleme aus nicht kompatiblen Datentypen zu vermeiden.

Das ganze Feld der No/Low-Code-Anwendungen scheint mir noch sehr unreif zu sein.

Nun ja, ich werde mich damit arrangieren, im Maul des geschenkten Gauls die Zähne selber zu putzen, also manuell für kompatible Datentypen zu sorgen, nicht nur einmal, sondern bei jeder einzelnen Änderung eines Datentyps.

Mein beruflicher Hintergrund ist Usability.
In Appsheet existiert das Konzept der Responsiveness bisher gar nicht. Als ich das realisiert habe, stand mein Mund länger vor Verwunderung offen.

Es ist so uralt und so simpel mit CSS umzusetzen. Auch das werte ich als Beleg für meine These "alles noch sehr unreif".

Zur Zeit ist es also unmöglich eine spezifische Darstellung der App zu erreichen, die abhängig ist von der Breite des Displays und der Sehkraft des Nutzers (der sich seine spezifische Schriftgröße auf seinem Device konfiguriert hat).

Schönes WE!
 
Zurück
Oben