Pantry DB

  • Hallo zusammen, für ein weiteres kleines Projekt zum lernen brauche ich mal wieder eure Gedanken zur Struktur einer MySQL Datenbank. Ihr könnt euch das vorstellen wie eine Pantry, also Speisekammer.


    In dieser Speisekammer gibt es mehrere Regale, Regalböden, Kisten und Taschen.
    Die Speisekammer an sich hat rund 500 Produkte, welche entweder einzeln auf den Regalböden stehen, oder in Kisten sind (welche natürlich auch auf Regalböden stehen), oder sogar in Taschen welche in entsprechenden Kisten gelagert werden.

    Ziel ist es, die komplette Pantry übersichtlich auf einer Seite darzustellen, um
    a) Sofort zu sehen wo z.B. die Tafel Schokolade gelagert ist
    b) Das MHD anzuzeigen, und ggf. farblich zu markieren
    Aber um die Gestaltung etc. mache ich mir später Gedanken, meine eigentliche Frage ist:

    Wie strukturiere ich die Datenbank?
    1. Packe ich alle 500 Produkte in eine Tabelle oder mache ich eine Tabelle pro Regal? Oder ganz was anderes?
    2. Manche Produkte lagern in unterschiedlicher Stückzahl an verschiedenen Orten (fragt nicht), also zum Beispiel 5x Schokolade in Regal A und 10x Schokolade in Regal B. Da muss ich dann trotzdem pro Lagerort eine extra Zeile für das gleiche Produkt anlegen, oder?

    3. Wie baue ich die Tabelle dann für die jeweiligen Produkte auf?

    Sollte mir das Projekt gelungen sein, möchte ich einmal im Monat mit einem Cronjob eine Seite abrufen, welche mir dann eine E-Mail mit gefährdeten MHD´s schickt etc.

    Vielen Dank schon einmal - wie immer - für eure Hilfe :)

    [RS] 2000 G9 | Cyber Quack

    [VPS] 1000 G9 | 200 G8 | Secret | A | mikro G11s | 4x nano G11s
    [WH] 2x 8000 SE | 4000 SE | 2000 SE

  • Also von MySQL hab ich gar keine Ahnung, kann mich aber an ein MS Access 2010 Seminar erinnern. Vom Prinzip her packst Du die Artikelstammdaten, Regale, Boxen, Kisten und Böden jeweils in eigene Tabellen und verknüpfst die nachher nur.. Und dann noch das MHD dazu.

    RS 3000 G9.5 SE auch genannt OST22 L - 24 GB RAM, 8 Kerne, AMD Epyc, 960 GB SSD

    Webhosting 8000 SE BF22

  • Kommt drauf an wie Du die DB nutzen möchtest.
    Wonach sollte man suchen können?


    Ich würde wohl eine Tabelle mit den Regalen machen, eine mit den Produkten und eine mit den möglichen Verfügbarkeiten. Als Detail evtl. noch eine Tabelle nach den Zutaten.

    Die Attribute der Produkte kannst Du in der DB zuordnen und das dann über SELECT abfragen wie gewünscht.

  • Bei größeren Datenbanken überführt man das Schema häufig in die dritte Normalform, um Redundanzen zu vermeiden :)


    Für die Abfragen kann man sich dann alles zusammen joinen, wie man es braucht.

  • Eine Tabelle für Produkte: ID int identity(1,1), Bezeichnung

    Eine Tabelle für die Speicherorte: ID int identity(1,1), Bezeichnung varchar, ParentID int

    Die oberste Lagereinheit hat ParentID=Null

    Eine Tabelle für die Mengen: ProduktID, SpeicherortID, Menge

    mit PrimaryKey (ProduktID,SpeicherortID)


    Wenn Du Hilfe bei den Abfragen brauchst sag Bescheid.

  • Hallo zusammen, für ein weiteres kleines Projekt zum lernen brauche ich mal wieder eure Gedanken zur Struktur einer MySQL Datenbank. Ihr könnt euch das vorstellen wie eine Pantry, also Speisekammer.

    Nur mal so gefragt.. kannst Du schon MySQL oder lernst Du es grade erst? Falls ja, wie und wo? Finde das auch mega interessant und spannend, hab mir deshalb jetzt mal (lokal auf nem Pi) eine MariaDB und Adminer installiert, und fange mal ganz klein an:

    Externer Inhalt www.youtube.com
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.

    RS 3000 G9.5 SE auch genannt OST22 L - 24 GB RAM, 8 Kerne, AMD Epyc, 960 GB SSD

    Webhosting 8000 SE BF22

  • Wie strukturiere ich die Datenbank?
    1. Packe ich alle 500 Produkte in eine Tabelle oder mache ich eine Tabelle pro Regal? Oder ganz was anderes?
    2. Manche Produkte lagern in unterschiedlicher Stückzahl an verschiedenen Orten (fragt nicht), also zum Beispiel 5x Schokolade in Regal A und 10x Schokolade in Regal B. Da muss ich dann trotzdem pro Lagerort eine extra Zeile für das gleiche Produkt anlegen, oder?

    3. Wie baue ich die Tabelle dann für die jeweiligen Produkte auf?

    Du suchst etwas, das nennt sich Normalisierung:
    https://de.wikipedia.org/wiki/…_(Datenbank)#Normalformen

    Generell willst du definitiv zur zweiten Normalform kommen, am besten zur Dritten.
    Zum Modellieren empfehle ich https://www.draw.io und die UML Sektion.
    Ich habe mal ein eigenes Beispiel aus der Lehre angehängt.
    Jeder dieser UML "Blöcke" entspricht einer Tabelle, die Referenzen zwischen den Tabellen (Foreign Key) liegen, abhängig von der Kardinalität, entweder in einer Tabelle (1:n Beziehung) oder in einer Tabelle aus Referenzen (N:N), lässt sich auch als UML darstellen.

    Screenshot_20230130_181759.png

  • Hier mal ein Beispiel.
    Alles nutzt eine numerische ID, da diese nur intern verwendet werden, und in keiner weise geändert werden müssen, im Gegensatz zu beispielsweise Namen. Deshalb sind Namen kein guter Key. (Eindeutigkeit von Namen lässt sich auch enforcen, dafür müssen das nicht die Primärschlüssel sein).

    Hier mal eine Version die es erlaubt dass Produkte sowohl so im Regalboden stehen, als auch in Kisten. Außerdem speichere ich alle Produkte erst mal nur mit dem Kaufdatum ab, eine Referenz auf die Produktdetails vereinheitlicht dann den Namen und die Haltbarkeit, das Ablaufdatum wird in meiner Version also anhand Kaufdatum + Haltbarkeit berechnet (was natürlich quatsch ist, weil du das Ablaufdatum ja nach Aufschrift nutzen musst, aber mal als Idee). Letztlich hat jedes Regal dann mehrere Regalböden und diese dann Kisten. Zum identifizieren nutze ich jetzt einfach Freitext, vielleicht hast du ja auch GPS Koordinaten oder ähnliches, lässt sich ja anpassen ;) Was auch gänzlich fehlt ist die Menge. Ich gehe hier bspw einfach von "Packung Nudeln" oder "Glas Marmelade" aus, die Menge ist dann Bestandteil des Produkts. Und wenn du halt 7x Marmelade hast, dann packst du 7x die Referenz zu der Kiste / Regalboden

    Damit sind wir bei 7 Tabellen.

  • Für mysql/mariadb kannst du natürlich phpmyadmin nutzen um herum zu experimentieren, das nimmt einem anfänglich das erstellen von dem ganzen SQL ab und ermöglicht visuelles editieren. Für PostgreSQL gibts gleich 'ne ganzen admin oberfläche mitgeliefert. Phpmyadmin bitte _nicht_ öffentlich zugänglich machen, zur not pack es passwortgeschützt in einen Ordner aus 20 Zeichen an Zufall.

  • Ich würde Produkt als Relation zwischen

    Produkt

    -----------

    Kaufdatum

    Ablaufdatum


    und


    Produktart

    --------------

    Name

    Beschreibung

    Hersteller


    modellieren.


    (Also eigentlich würde ich das alles gar nicht machen, sondern eine dokumentenbasierte Datenbank nehmen. Aber vermutlich ist der OP in der Auswahl der Datenhaltungsprodukte eingeengt.)

  • was spricht dagegen

    Ich bekomme genug Botanfragen ob ich net phpmyadmin drauf habe, und ich möchte nicht ausprobieren wie gut mein system hier mit einem login DDOS leben kann, oder ob alle Datenbanken hier auch gute Passwörter verwenden. Es ist eine indirekte Schnittstelle zur Datenbank, welche normalerweise extra nur auf localhost reagiert. Außerdem gibt es ja extra eine Config-Option für auto login.. Daher lieber garnicht erst zugänglich machen.

  • was spricht dagegen? da dürfte ich auch kein webmail zugänglich machen.

    Die Zugangsdaten der Postfächer sind in der Regel aber sowieso von extern nutzbar. Bei Datenbanken limitiert man den Zugriff der User meistens auf localhost bzw. kann man diese Limitierung mit phpMyAdmin schön umgehen.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • das trifft auf jeden anderen service auch zu: wordpress, webmail, imap, smtp, ssh, cal-, carddav, webdav, …

    Dein Wordpress wird von vielen Leuten betrieben und entsprechend eingerichtet mit dem Wissen, dass dieses von außen erreichbar ist. Gilt erst recht für alle anderen Anwendungen die du genannt hast.

    Mein PhpMyAdmin kommt nachträglich auf eine DB-Installation welche vorher nie damit konfrontiert wurde, dass sie jetzt von außen mit Logins rechnen muss. Weitere mögliche Problematik: Socketauth. Dann ist der Login in dem Moment geschehen wo der Web-User auf den Socket connected.


    Alles in allem mag das alles gehen, ich packe aber eine Administrationsoberfläche mit php, welche auf meine zentrale Datenbank zugreift lieber hinter irgendeine Form der Absicherung. Und sei es ein Verzeichnis mit gewürfeltem Namen. Dann ersparst du dir im übrigen die Menge an Fail2Ban Einträgen, welche alle mal den 0815 Kram im Login durch probieren. Ich werde daher für eine unbekannte Konfiguration im Forum eher davon abraten sich eine potenzielle Sicherheitslücke ins Boot zu holen. Erst recht weil es eine weitere Applikation ist, welche Updates erhalten muss, ansonsten wird der PHP-Code selbst das nächste Einfallstor. Und seien wir ehrlich: Wer updated sein phpmyadmin regelmäßig ?


    P.S.: Bei den Wordpressinstallationen gibts ja auch genug Angriffe und Suchen nach /admin bereichen.. Scheint sich also auch hier zu lohnen.

    Edit: Kenne auch Mysql installationen mit anonymen default user für stats, dann ist hoffentlich nix falsch in den Rechten gesetzt..

  • ist der begriff softwareless-server schon etabliert? damit ich mich um keine updates kümmern muss? oder der begriff single-user-for-everything?


    und wer seine services nicht auf vhosts betreibt dem kann man eh nicht helfen. aber ist vielleicht auch nur eine frage der zeit bis die abgegrast werden.


    jeder größere webhoster hat phpmyadmin zugänglich.