Werte in Datenbank speichern und auslesen

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

Aufgrund der Corona-Krise: Die Veröffentlichung von Stellenangeboten und -gesuchen ist bis 31.3.2023 kostenfrei. Das beinhaltet auch Angebote und Gesuche von und für Freischaffende und Selbstständige.

  • Werte in Datenbank speichern und auslesen

    Servus Zusammen,

    ich habe heute eine für mich sehr knifflige Frage für euch vorbereitet.
    Und zwar habe ich geplant, einen Counter einzuführen, bei dem man sehen kann wie viele Rezepte bereits gekocht wurden.
    Zum Ablauf:
    Ich wähle ein Rezept, koche dieses und drücke anschließend auf den Button "Fertig gekocht".
    Dann soll hierdurch eine Meldung an eine Datenbank gemacht werden und einfach ein Zahlenwert um eins erhöht werden.
    Auf der Startseite soll man dann sehen wie viele Gerichte von allen zusammen bereits gekocht wurden, durch die einfache abfrage der Zahl in der
    Datenbank.

    Ist so etwas möglich, bzw. hat jemand von euch damit vielleicht schon Erfahrungen sammeln können?

    Liebe Grüße und ein schönes Wochenende,

    Ferdinand :thumbup:
  • Wie häufig von mir keine kurze Antwort :)

    Wenn Du es wirklich nur "quick & dirty" möchtest, könntest Du den Zähler einfach entweder lokal in den UserDefaults speichern oder - um iCloud-Synchronisierung zu unterstützen - im Key-Value-Store ablegen.

    Aber wäre es nicht eleganter, für jedes Rezept ein zusätzliches boolsches Attribut "gekocht" einzuführen? Dieses wäre standardmäßig FALSE und würde über den o. g. Button auf TRUE gesetzt. Für die Startseite würdest Du dann einen Fetch mit entsprechendem Predicate machen, der Dir einfach die Anzahl der als gekocht geflaggten Rezept-Objekte gibt. Dieser Ansatz wäre auch korrekt, wenn z. B. Rezepte mal entfernt werden oder Du die gekochten Lieblingsrezepte anzeigen willst oder ... oder ... oder.

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • Vielen dank für deine Antwort :thumbsup:

    Du hast recht, die zweite Variante klingt viel vielversprechender und schöner! :thumbup:

    Ich denke ich werde mich mal durch Variante eins probieren und wenn das klappt anschließend auf Variante zwei umsteigen, so habe ich beide
    Varianten mal getestet :saint:

    Generell könnte ich es schon über die Userdefaults speichern, jedoch ist ja der Sinn des Zählers, damit alle sehen wie viele Gerichte beispielsweise
    diesen Monat schon von allen Gemeinsam gekocht wurden :saint:

    Braucht man hierfür nicht eigentlich eine komplizierte Datenbank Lösung?


    Liebe Grüße,
    Ferdinand
  • Ferdinand schrieb:

    Braucht man hierfür nicht eigentlich eine komplizierte Datenbank
    Anders gefragt: Wo liegen denn die Rezepte? Ich habe hier eine DB (im Backend) angenommen, aber nun klingt es, als liefertest Du sie lokal mit der App aus.

    Falls es so ist, würde ich über ein Redesign nachdenken ... @Thallius und @322 haben genau die richtigen Stichworte geliefert.

    Mattes

    Edit: Auch wenn mich jetzt manche:r steinigen möchte: Man könnte Rezepte auch als Text-Dateien (z. B. JSON) auf einem ganz normalen Webserver ablegen und per HTTPS-Request holen ... um für einen Einsteiger die Komplexität zu reduzieren. Elegant ist natürlich anders :)
    Diese Seite bleibt aus technischen Gründen unbedruckt.

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von MyMattes ()

  • MyMattes schrieb:

    Ferdinand schrieb:

    Braucht man hierfür nicht eigentlich eine komplizierte Datenbank
    Edit: Auch wenn mich jetzt manche:r steinigen möchte: Man könnte Rezepte auch als Text-Dateien (z. B. JSON) auf einem ganz normalen Webserver ablegen und per HTTPS-Request holen ... um für einen Einsteiger die Komplexität zu reduzieren. Elegant ist natürlich anders :)
    im Gegenteil. Finde ich für so eine Anwendung vollkommen legitim. Ist halt für den Einstieg einfacher, Problem ist, das du früher oder,später dann eben doch bei einer Datenbank landen wirst,
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • Ferdinand schrieb:

    Ich habe mich am Wochenende mal ein wenig mit der Thematik FireBase auseinandergesetzt.
    Quasi eine kostenlose Datenbank Lösung mit vielen Tutorials und aufschrieben.
    Bisher klingt das ganze sehr interessant und ich denke dass damit alles gut realisiert werden kann.
    Habt ihr bereits Erfahrungen mit FireBase sammeln können?

    Liebe Grüße,

    Ferdinand
    Vorab: Firebase wird ohne großes B geschrieben... ;)

    Ich persönlich habe alle meine privaten Projekte mit Firebase gelöst, da du später theoretisch recht einfach über Android Apps auf deine Datenbank zugreifen kannst, Firebase viele Tutorials hat, eine gute Dokumentation und es mir optisch zugesagt hat (falls der Punkt überhaupt relevant ist :p).
    Darüber hinaus bietet es sehr gute Dashboard über Zugriffe, Zugriffszeiten und Crashlytics. Einbindung von Facebook login, Github login, grundsätzliches Nutzerhandling ist da sehr einfach gelöst und vieles mehr...

    Habe mit dem Cloud Storage sehr gute Erfahrungen im Bezug zu Nutzerfotos gemacht und mit der Realtime Database habe ich für einen Kunden mal >10k .json Zeilen eingelesen, was auch super komfortabel mit einem einfachen JS Skript war...
    Nutze für meine persönlichen Datenbanken aber eher die Cloud Firestore Datenbank.. Den Unterschied zur Realtime DB habe ich persönlich noch nicht gefunden, aber Google nutzt da so Buzzwords wie "Flexibility", "Expressive querying", "Designed to scale" und so eine schwarze Magie...
    Habe einfach mit der Cloud Firestore zuerst angefangen und mit der Realtime DB nur Berührungspunkte wegen eines Kundenprojektes gehabt ..^^

    Einziger Nachteil aus meiner Sicht: Es ist eine NoSQL Datenbank...
    Ich bin Informatik Student gewesen und habe SQL lernen und lieben gelernt und auf der Arbeit auch schon einige SQL Datenbanken aufgesetzt...
    Da is eine NoSQL Datenbank schon etwas gewöhnung.. Aber da ich vermute, dass du noch keine SQL Berührungspunkte hast, ist der Punkt für dich ja quasi zu vernachlässigen.

    Btw. wenn du dich damit beschäftigst, solltest du auch wissen was eine .json ist. Und vielleicht schaust du dir dazu auch mal ein paar Sachen an.. Was ist eine .json, wie ist sie aufgebaut und was für Datenstrukturen könnten darin enthalten sein.
    Einfach so als kleine Hilfestellung ;)
    ''Ich stelle immer Getränke auf meinen PC, da ist noch nie etwas passiert..''
    - 'Aber.. dieses mal ist es dir doch in den Lüfter gelaufen?!'
    ''Ja, aber sonst nicht''
    8| :thumbsup:
  • ashtari schrieb:

    Einziger Nachteil aus meiner Sicht: Es ist eine NoSQL Datenbank...
    Naja, den viel größeren Nachteil finde ich, dass ich damit alle Daten an Goole weitergebe die in meiner App gespeichert werden. Ich bin gar nicht sicher ob man nicht beim ersten benutzen der App den User darauf aufmerksam machen muss und ihm die Möglichkeit geben es abzulehnen? Aber wahrscheinlich macht man dann irgendwelche hundert Seiten lange AGB's die der User akzeptieren muss wo das eben auch mit drinsteht, wo man aber weiß das der User gar keinen Bock hat sich das durchzulesen. Und so wundern wir uns dann, dass Google mittlerweile wirklich so ziemlich alles über uns weiß.
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • Thallius schrieb:

    ashtari schrieb:

    Einziger Nachteil aus meiner Sicht: Es ist eine NoSQL Datenbank...
    Naja, den viel größeren Nachteil finde ich, dass ich damit alle Daten an Goole weitergebe die in meiner App gespeichert werden. Ich bin gar nicht sicher ob man nicht beim ersten benutzen der App den User darauf aufmerksam machen muss und ihm die Möglichkeit geben es abzulehnen? Aber wahrscheinlich macht man dann irgendwelche hundert Seiten lange AGB's die der User akzeptieren muss wo das eben auch mit drinsteht, wo man aber weiß das der User gar keinen Bock hat sich das durchzulesen. Und so wundern wir uns dann, dass Google mittlerweile wirklich so ziemlich alles über uns weiß.
    Sehe ich nicht so.

    Es kommt auf die Zielgruppe an. Die 2% der Technerds die der Meinung sind, man könne Google umgehen, werden keine Zielgruppe von Ferdinand mit einer "Rezept- und Kochapp" sein. Oder anders... Die Zielgruppe ist zu vernachlässigen. Zumal ein .. ich sage mal vorsichtig "Amateur" wie Ferdinand wohl keine Ahnung hat wie er sich eine eigene Datenbank von der Pike auf aufsetzen kann und sie dann, sobald sie wächst, auch skalieren kann.

    Am Ende ist es das selbe wie mit Apple..
    Irgend einem Unternehmen "vertraust" du deine Daten an. Und da ist es mir ehrlicherweise egal ob Apple oder Google, denn ich will eine gute, smarte und moderne Lösung für mein Produkt, welches ich im besten Fall einfach migrieren kann. Und das bietet Firebase.

    Aber mal eine etwas offtopic Frage...
    Dieses "böse, böse Google" höre ich immer und immer wieder... Nutzt ihr kein Youtube? Habt ihr keinen FireTV-Stick? Eine Alexa?
    Und neben den Google Produkten... Wie ist es mit Microsoft? Habt ihr keine Bedenken bzgl. eure Spotify Musik? Bestellt ihr nichts auf Amazon?
    Aber bei Apple ist aus eurer Sicht alles okay?

    Am Ende verkaufen alle Unternehmen eure Daten und ich finde zu sagen "weil alle Daten an google gehen ist es ein Nachteil Firebase einzusetzen" ist für mich recht haltlos.

    Will euch damit wirklich nicht auf den Schlipps treten, aber die Logik zu sagen Google ist böse, Apple ist aber gut oder Microsoft oder irgend ein anderes FAANG Unternehmen wären total toll, dass ist aus meiner Sicht zu einfach. Nach dem Prinzip ginge nämlich nur die Lösung der eigenen Datenbank im Keller... ;)
    ''Ich stelle immer Getränke auf meinen PC, da ist noch nie etwas passiert..''
    - 'Aber.. dieses mal ist es dir doch in den Lüfter gelaufen?!'
    ''Ja, aber sonst nicht''
    8| :thumbsup:
  • ashtari schrieb:

    Am Ende ist es das selbe wie mit Apple..
    Hier sehe ich einen grossen Unterschied: Während das Geschäftsmodell der einen Unternehmen auf den Daten seiner Nutzer (nicht seiner Kunden!) beruht, bieten die anderen Dienstleistungen, bei denen Daten anfallen bzw. die auf Daten beruhen.

    Oder anders ausgedrückt: Womit verdienen Google und Meta ihr Geld und wer sind ihre Kunden? Und wie ist es bei Apple oder Microsoft?

    Ich sehe dort einen grossen Unterschied: Auch wenn ich sensible Dateien keinem der Genannten anvertrauen würde, sträuben sich mir bei Google und Meta eher die Haare. Faktisch spiegelt sich das in den von @Thallius angesprochenen Nutzungsbedingungen - insbesondere der Rechteüberlassung von Inhalten - wieder.

    Aber das will ja keiner mehr hören, sondern lieber über Whatsapp chatten und Videos auf Tiktok sharen. Aber bitte später nicht angeweint kommen, wenn Wahlmanipulationen über Social Media stattfinden... Sorry, aber Ihr habt da einen meiner wunden Punkte getroffen.

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.

  • Will euch damit wirklich nicht auf den Schlipps treten, aber die Logik zu sagen Google ist böse, Apple ist aber gut oder Microsoft oder irgend ein anderes FAANG Unternehmen wären total toll, dass ist aus meiner Sicht zu einfach. Nach dem Prinzip ginge nämlich nur die Lösung der eigenen Datenbank im Keller...

    Wenn ich sowas lese, dann weiß ich warum ich mir sicher bin das die Welt zugrunde geht….

    Nein, die Lösung einer eigenen Datenbank ist damit nicht im Keller, sie kostet nur halt Geld! Warum glauben heute eigentlich alle, dass heute alles umsonst ist? Nichts ist umsonst…
    Keiner hindert dich daran einen Datenbank bei einem Hoster für sagen wir 5 Euro im Moment anzumieten und schon bekommen weder *Google noch Apple oder Microsoft diese Daten. Für 5 Euro im Monat!!!
    aber das ist ja viel zu teuer, da verkaufe ich lieber die Daten,,,.

    Leute denkt doch einfach mal nach wohin diese Mentalität führen wird….
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • Thallius schrieb:

    ashtari schrieb:

    Einziger Nachteil aus meiner Sicht: Es ist eine NoSQL Datenbank...
    Naja, den viel größeren Nachteil finde ich, dass ich damit alle Daten an Goole weitergebe die in meiner App gespeichert werden.
    Ich sehe da noch einen weiteren. Einfach mal nach Firebase bei Google suchen. Da finden sich dann jede Menge Erfahrungsberichte von Entwicklern, denen die Kosten davon gelaufen sind...
  • Guten Morgen zusammen,

    ich hab mir jetzt einige Tutorials und Videos zu Google Firebase angeschaut und mich ein wenig in die Materie eingelesen.
    Ich denke für meine Zwecke ist das am Anfang recht ausreichend :thumbup:

    Ich arbeite mich mal durch die Quick and Dirty Methode und versuche mich sobald das klappt auf einen sauberen weg einzustellen und alles noch mal
    neu zu bearbeiten :saint:

    Liebe Grüße,
    Ferdinand