Allgemeine Fragen zu SQLAlchemy und Pandas

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Kalysto
User
Beiträge: 117
Registriert: Freitag 14. April 2017, 15:28

Hallo Zusammen,

Ich bin hier in diesem Forum einmal darauf angesprochen worden (ca. 1 Jahr her) das man besser mit SQLAlchemy arbeiten sollte anstatt mysql.connector wie ich es gemacht hatte. (konnte das vorher nicht umsetzten da das Python-Script unter IOS Pythonista läuft)
Ich verwende nun SQLAlchemy in Verbindung mit dem mysql.connector und wollte hier schon einmal fragen ob das "gut" ist ?

Mein Anfang sieht nun wie folgt aus:

Code: Alles auswählen

from sqlalchemy import create_engine
import pandas as pd

db_connection_str = 'mysql+mysqlconnector://USER:PASSWD@IP:PORT/DB_NAME'
db_connection = create_engine(db_connection_str)
der Code für die Verbindung Funktioniert soweit und ich habe zugriff.

mit Pandas hatte ich vor meine DB's in ein Array zu laden um damit arbeiten zu können um nicht immer wieder erneut abfragen stellen zu müssen:

Code: Alles auswählen

df = pd.read_sql('SELECT * FROM datanorm', con=db_connection)
print(df)
Ausgabe:
ID qr_code ean_code ... date_create date_update date_out
0 1 0001 4013456553781 ... 2020-09-04 2022-11-01 2023-05-08
1 2 0002 4013456531994 ... 2020-09-04 2022-07-06 2023-05-05
2 3 0003 4013456470408 ... 2020-09-04 2022-09-18 2022-09-25
3 4 0004 4013456545915 ... 2020-09-04 2022-07-17 None
4 5 0005 4013456548244 ... 2020-09-04 2022-07-17 2022-10-20
... ... ... ... ... ... ... ...
2115 2116 1304 4049759137014 ... 2022-12-22 2022-12-23 None
2116 2117 1305 4049759069353 ... 2022-12-22 2022-12-23 None
2117 2118 58/00001 3250613140557 ... 2022-12-22 None 2022-12-23
2118 2119 58/00011 3250614200540 ... 2022-12-22 None 2022-12-23
2119 2120 1301 4250184105473 ... 2022-12-22 None None

[2120 rows x 32 columns]

Würde man das bis hier her so gestalten oder ist meine Idee und vorgehen totaler Quatsch..
und muss man die Verbindung auch wieder Schließen oder geht das automatisch ?

ein SELECT mit dem mysql.connector sieht aktuell so aus:
(nicht auf die Schreibweise achten bin ich am überarbeiten)

Code: Alles auswählen

self.cursor_SQL.execute(
    """
    SELECT
        ID,
        qr_code,
        IFNULL(ean_code, 'keine Angabe'),
        user_name,
        IFNULL(user_name_update, 'keine Angabe'),
        sort_number,
        manufacturer_ID,
        manufacturer,
        manufacturer_designation,
        manufacturer_designation__short,
        IFNULL(manufacturer_number, 'keine Angabe'),
        IFNULL(supplierMoster_number, 'keine Angabe'),
        deactivatedMoster,
        IFNULL(supplierRexel_number, 'keine Angabe'),
        deactivatedRexel,
        IFNULL(supplierOther_number, 'keine Angabe'),
        IFNULL(supplierOther_name, 'keine Angabe'),
        deactivatedOther,
        IFNULL(count, 'keine Angabe'),
        IFNULL(material_inventory, 'keine Angabe'),
        perPiece,
        IFNULL(purchasing_price, 'keine Angabe'),
        IFNULL(selling_price, 'keine Angabe'),
        IFNULL(update_price, 'keine Angabe'),
        cutting,
        inventory,
        inventory_lite,
        IFNULL(inventory_query, 'keine Angabe'),
        IFNULL(inventory_order_quantity, 'keine Angabe'),
        date_create,
        IFNULL(date_update, 'keine Angabe'),
        IFNULL(date_out, 'keine Angabe')
    FROM datanorm
    ORDER BY sort_number
    """
)
for (
    datanorm__ID,
    datanorm__qr_code,
    datanorm__ean_code,
    datanorm__user_name,
    datanorm__user_name_update,
    datanorm__sort_number,
    datanorm__manufacturer_ID,
    datanorm__manufacturer,
    datanorm__manufacturer_designation,
    datanorm__manufacturer_designation__short,
    datanorm__manufacturer_number,
    datanorm__supplierMoster_number,
    datanorm__deactivatedMoster,
    datanorm__supplierRexel_number,
    datanorm__dactivatedRexel,
    datanorm__supplierOther_number,
    datanorm__supplierOther_name,
    datanorm__deactivatedOther,
    datanorm__count,
    datanorm__material_inventory,
    datanorm__perPiece,
    datanorm__purchasing_price,
    datanorm__selling_price,
    datanorm__update_price,
    datanorm__cutting,
    datanorm__inventory,
    datanorm__inventory_lite,
    datanorm__inventory_query,
    datanorm__inventory_order_quantity,
    datanorm__date_create,
    datanorm__date_update,
    datanorm__date_out
) in self.cursor_SQL:
    createDatanormArray.append(
        [
            datanorm__ID,
            datanorm__qr_code,
            datanorm__ean_code,
            datanorm__user_name,
            datanorm__user_name_update,
            str(datanorm__sort_number),
            str(datanorm__manufacturer_ID),
            datanorm__manufacturer,
            datanorm__manufacturer_designation,
            datanorm__manufacturer_designation__short,
            datanorm__manufacturer_number,
            datanorm__supplierMoster_number,
            datanorm__deactivatedMoster,
            datanorm__supplierRexel_number,
            datanorm__dactivatedRexel,
            datanorm__supplierOther_number,
            datanorm__supplierOther_name,
            datanorm__deactivatedOther,
            datanorm__count,
            datanorm__material_inventory,
            datanorm__perPiece,
            datanorm__purchasing_price,
            datanorm__selling_price,
            datanorm__update_price,
            datanorm__cutting,
            datanorm__inventory,
            datanorm__inventory_lite,
            str(datanorm__inventory_query),
            datanorm__inventory_order_quantity,
            datanorm__date_create,
            datanorm__date_update,
            datanorm__date_out
        ]
    )
so eine Abfrage kommt dann x mal da ich jedes mal alles einzeln abfragen würde was ich nun verbessern und anpassen möchte.
1. Im Bezug auf "Platz"
2. Nicht mehr so viele Abfragen
3. Schnelligkeit
4. Sauerer Code

Gibt es bei SQLAlchemy in dem UPDATE auch eine Prüfung sodass der Eintrag erfolgreich und korrekt erstellt worden ist ?


sollte man Variablen deutsch benennen oder doch im Englischen bleiben was meint ihr dazu noch ?

wäre für Vorschläge bsp. etc. offen

Gruß
Kalysto
Sirius3
User
Beiträge: 17754
Registriert: Sonntag 21. Oktober 2012, 17:20

Ohne zu wissen, welches Problem Du lösen möchtest, ist es schwierig etwas zum Code zu sagen.
Es ist komisch, dass Du gar keine Filterung hast. Es ist ja selten nötig, mit allen Daten zu arbeiten, das nutzt die Funktionalität der Datenbank gar nicht.

Die Daten die Du da in eine Tabelle gestopft hast, sind ein wildes Samelsurium. Da fehlen eindeutig ein bis zwei Stufen Normalisierung.
Ich sehe da einen User, einen Manufacturer, einen Supplier, ein Produkt, ein Inventory, also mindestens 5 einzelne Tabellen.
Kalysto
User
Beiträge: 117
Registriert: Freitag 14. April 2017, 15:28

Sirius3 hat geschrieben: Samstag 13. Mai 2023, 18:43 Ohne zu wissen, welches Problem Du lösen möchtest, ist es schwierig etwas zum Code zu sagen.
Es ist komisch, dass Du gar keine Filterung hast. Es ist ja selten nötig, mit allen Daten zu arbeiten, das nutzt die Funktionalität der Datenbank gar nicht.
Naja, das Problem wie gesagt das ich weniger "Platz" für den Code benötige und das ich nicht x abfragen erstellen muss sondern immer auf das Array zurückgreifen kann was mit SQLAlchemy und Pandas erstellt wurde.
In diesem Fall benötige ich immer alle Daten der Tabelle da ich über eine Tabelle das jeweilige Material auswähle und mir so alle Details des Materials anzeigen lasse und auch bearbeiten kann.
Sirius3 hat geschrieben: Samstag 13. Mai 2023, 18:43 Die Daten die Du da in eine Tabelle gestopft hast, sind ein wildes Samelsurium. Da fehlen eindeutig ein bis zwei Stufen Normalisierung.
Die Daten haben schon ihren sinn! Wie gesagt das sind alles Material angaben von Herstellern mit Preisen etc.
Was meinst du genau mit "Normalisierung" ?
Sirius3 hat geschrieben: Samstag 13. Mai 2023, 18:43 Ich sehe da einen User, einen Manufacturer, einen Supplier, ein Produkt, ein Inventory, also mindestens 5 einzelne Tabellen.
Wie 5 einzelne Tabellen ?
Ich Hatte ja unten eine Ausgabe dargestellt welche ja Zeigte was darin ist:
es sind zur Zeit 2120 Zeilen (Verschiedene Materialien) in 32 Spalten in der kompletten Datenbank enthalten.
Benutzeravatar
__blackjack__
User
Beiträge: 13116
Registriert: Samstag 2. Juni 2018, 10:21
Wohnort: 127.0.0.1
Kontaktdaten:

@Kalysto: https://de.wikipedia.org/wiki/Normalisi ... Datenbank)

Und danach ist das falsch was Du da machst. Tabellen in relationalen Datenbanken sind nicht das was man beispielsweise in einer Excel-Tabelle speichern würde. Dort kann man neben der gleichen Hersteller-ID auch immer wieder den gleichen Herstellernamen usw. speichern. Das verletzt aber in relationalen Datenbanken die Normalform. Wenn Du das da so speicherst, stellt sich die Frage warum überhaupt eine SQL-Datenbank verwendet wird. Die Frage stellt sich ebenfalls wenn Du sowieso immer den kompletten Datenbestand in den Speicher lädtst.
„All religions are the same: religion is basically guilt, with different holidays.” — Cathy Ladman
Kalysto
User
Beiträge: 117
Registriert: Freitag 14. April 2017, 15:28

__blackjack__ hat geschrieben: Sonntag 14. Mai 2023, 18:58 @Kalysto: https://de.wikipedia.org/wiki/Normalisi ... Datenbank)

Und danach ist das falsch was Du da machst. Tabellen in relationalen Datenbanken sind nicht das was man beispielsweise in einer Excel-Tabelle speichern würde. Dort kann man neben der gleichen Hersteller-ID auch immer wieder den gleichen Herstellernamen usw. speichern. Das verletzt aber in relationalen Datenbanken die Normalform. Wenn Du das da so speicherst, stellt sich die Frage warum überhaupt eine SQL-Datenbank verwendet wird. Die Frage stellt sich ebenfalls wenn Du sowieso immer den kompletten Datenbestand in den Speicher lädtst.
Naja, worin sollte ich es denn sonst speichern wenn nicht in einer SQL-Datenbank ?
Das war ja einer der Fragen ob ich den Datenbestand einmal zu beginn einlese und damit weiter arbeite oder ob man diesen immer nur einliest wenn dieser auch benötigt werden würde.?
Benutzeravatar
__blackjack__
User
Beiträge: 13116
Registriert: Samstag 2. Juni 2018, 10:21
Wohnort: 127.0.0.1
Kontaktdaten:

@Kalysto: Wenn die Daten als *eine* Tabelle vorliegen, die in einen Pandas-DataFrame geladen werden, gibt es doch einen ganzen Haufen Speicherformate. CSV-Dateien, Excel, HDF5, Feather, Parquet, …

Wenn man eine SQL-Datenbank verwendet, würde man die Daten eben nicht *so* speichern, sondern einen relationalen Datenbankentwurf machen.
„All religions are the same: religion is basically guilt, with different holidays.” — Cathy Ladman
Sirius3
User
Beiträge: 17754
Registriert: Sonntag 21. Oktober 2012, 17:20

Im Moment sieht es so aus, als ob eine einfache csv-Datei den selben Effekt hat, weil Du eh die Datenbank so nutzt, wie man Datenbanken nutzt.
Kann natürlich sein, dass es tatsächlich besser wäre, eien Datenbank zu benutzen, dazu hast Du aber noch nicht verraten, was Du eigentlich machen willst.
Benutzeravatar
grubenfox
User
Beiträge: 432
Registriert: Freitag 2. Dezember 2022, 15:49

__blackjack__ hat geschrieben: Montag 15. Mai 2023, 20:36 @Kalysto: Wenn die Daten als *eine* Tabelle vorliegen, die in einen Pandas-DataFrame geladen werden, gibt es doch einen ganzen Haufen Speicherformate. CSV-Dateien, Excel, HDF5, Feather, Parquet, …
Da hat das mal wer getestet... The Best Format to Save Pandas Data
Benutzeravatar
__blackjack__
User
Beiträge: 13116
Registriert: Samstag 2. Juni 2018, 10:21
Wohnort: 127.0.0.1
Kontaktdaten:

”Best” ist halt immer auch eine Frage wonach man das bemisst. Ich finde beispielsweise oft interessanter als Geschwindigkeit wie gut ein Format die verschiedenen Datentypen unterstützt. Also zum Beispiel ob so etwas wie `Categorical`-Spalten das speichern und laden ohne extra Code überleben.
„All religions are the same: religion is basically guilt, with different holidays.” — Cathy Ladman
Kalysto
User
Beiträge: 117
Registriert: Freitag 14. April 2017, 15:28

Sirius3 hat geschrieben: Montag 15. Mai 2023, 20:54 Kann natürlich sein, dass es tatsächlich besser wäre, eien Datenbank zu benutzen, dazu hast Du aber noch nicht verraten, was Du eigentlich machen willst.
Ich bin der Meinung das es besser ist ja, weil ich muss auch gewisse Daten mitten in der Tabelle anpassen können.

Ich zeig euch nun einmal alles wie ich es damals gedacht und erstellt habe!

Datenbank Aufbau:
  • EE-7E4-3744 (DB-Name)
    • customers (13) [Angaben aller Kunden] / Einträge gesamt: 62
      • ID (AUTO_INCREMENT)
      • customer_ID (Angabe einer Kundennummer / einmalig je Kunde)
      • is_company (True = Firmen Kunde; False = Privat Kunde)
      • is_favorite (Kunde als Favoriten hinterlegen sodass er hervorgehoben wird und an erster Stelle steht)
      • user_name (Benutzer Name des Kunden Erstellers)
      • user_name_update (Benutzer Name welcher Anpassungen an dem Kunden gemacht hat)
      • company (nur bei Firmen: Firmenname)
      • first_name (Nur bei Privatkunden)
      • last_name (Nur bei Privatkunden)
      • place (Ort des Kundens)
      • customer_projects (Kunden Projekte)
      • date_create (Datum der Erstellung des Kunden)
      • date_update (Letzte Anpassung des Kundens)
    • datanorm (32) [Hier stehen alle Daten der Materialien drin] / Einträge gesamt: 2146
      • ID (AUTO_INCREMENT)
      • qr_code (Eigenerstellter QR-Code)
      • ean_code (13-Stellige EAN-Codes der Hersteller)
      • user_name (Benutzer Name welcher das Material in die DB hinzugefügt hat)
      • user_name_update (Benutzer Name wer Anpassungen an dem Material gemacht hat)
      • sort_number (Sortierungsnummer)
      • manufacturer_ID (Hersteller ID: kommt von der Tabelle: manufacturers)
      • manufacturer (Hersteller Name)
      • manufacturer_designation (Materialbeschreibung lang)
      • manufacturer_designation__short (Materialbeschreibung kurz)
      • manufacturer_number (Hersteller Best. Nr.)
      • supplierXyz_number (Lieferanten Best. Nr.) xyz = Anonymisiert
      • deactivatedXyz (True, False ob das Material ein Preis Update erhalten soll) xyz = Anonymisiert
      • supplierXyz_number (Lieferanten Best. Nr.) xyz = Anonymisiert
      • deactivatedXyz (True, False ob das Material ein Preis Update erhalten soll) xyz = Anonymisiert
      • supplierOther_number (Andere Lieferanten Nummern)
      • supplierOther_name (Lieferantenname)
      • deactivatedOther (True, False ob das Material ein Preis Update erhalten soll)
      • count (Anzahl der Materialeinträge Summe aller Projekte [Wird bei der Eintragung aktualisiert])
      • material_inventory (Materialbestand des Materials)
      • perPiece (Herstellerangabe ob 1 Stk., 100 Stk.)
      • purchasing_price (Einkaufspreis)
      • selling_price (Verkaufspreis)
      • update_price (Zuletzt aktualisiert)
      • cutting (True, False bei Schnittkosten Kabel und Leitungen)
      • inventory (Materialbestand, mit Bestelllisten)
      • inventory_lite (Materialbestand nur Info)
      • inventory_query (Info wenn Material Bestand unterschreitet)
      • inventory_order_quantity (Max. Lagerware des Materials)
      • date_create (Material hinzugefügt am)
      • date_update (Zuletzt Aktualisiert am:)
      • date_out (Material zuletzt in einem Projekt verwendet)
    • manufacturers (11) [Hersteller] / Einträge gesamt: 85
      • ID (AUTO_INCREMENT)
      • manufacturer_ID (Angabe einer „Herstellerkundennummer“ / einmalig je Hersteller)
      • user_name (Benutzer Name der Hersteller Erstellung)
      • user_name_update (Benutzer Name welcher Anpassungen an dem Hersteller getätigt hat)
      • manufacturer (Herstellername)
      • area_from (Erstellung für die Sortierungsnummern von: 5)
      • area_to (Erstellung für die Sortierungsnummern bis: 100)
      • in_use (Hersteller Materialien gelistet))
      • max_use (Herstellermaterialien max. begrenzt durch Sortierungsnummer: 95)
      • date_create (Hersteller erstellt am)
      • date_update (Letzte Anpassung am Hersteller)
    • materials (22) [Materialien mit Zuordnungen der Kunden (Materialdaten kommen von der datanorm)] / Einträge gesamt: 2575
      • ID (AUTO_INCREMENT)
      • datanorm_ID (datanorm ID)
      • customer_ID (Angabe der Kundennummer)
      • project_ID (Angabe der Projektnummer)
      • user_name (Benutzername welcher das Material erstellt hat)
      • user_name_update (Benutzername welcher zuletzt dieses Material eingetragen hat)
      • sort_number (Sortierungsnummer für die PDF-Datei bei Abschluss)
      • manufacturer_ID (Hersteller Identifikationsnummer)
      • manufacturer (Herstellername)
      • manufacturer_designation (Materialbeschreibung lang)
      • manufacturer_designation__short (Materialbeschreibung kurz)
      • manufacturer_number (Hersteller Best. Nr.)
      • supplierXyz_number (Lieferantennummer) xyz = Anonymisiert
      • supplierXyz_number (Lieferantennummer) xyz = Anonymisiert
      • comment (Material Komentare)
      • count (Material Anzahl)
      • count_interim_bill (Anzahl bei Zwischenrechnung)
      • selling_price
      • update_price
      • date_create (Ersteintragung des materials)
      • date_update (Letzte Eintragung des Materials)
      • date_closed (Abgeschlossen)
    • projects (12) [Alle Kundenprojekte] / Einträge gesamt: 105
      • ID (AUTO_INCREMENT)
      • customer_ID (Angabe der Kundennummer)
      • project_ID (Projektnummer / einmalig je Projekt)
      • user_name (Benutzername welcher das Projekte erstellt hat)
      • user_name_update (Benutzername welcher zuletzt an dem Projektdaten Anpassungen gemacht hat)
      • user_name_closed (Benutzername welcher das Projekt abgeschlossen hat / Freigabe für Rechnung)
      • customer_project (Projekt Name)
      • interim_bill (True, False ob Zwischenrechnung erstellt wurde)
      • closed (True, False ob Rechnung erstellt wurde)
      • date_create (Datum der Erstellung des Kunden)
      • date_update (Letzte Anpassung des Kundens)
      • date_closed (Datum des Abschlusses)
    • users (6) [Benutzer] / Einträge gesamt: 3
      • ID (AUTO_INCREMENT)
      • device_ID (IOS Identifikationsnummer zur Anmeldung)
      • name (Benutzer Name)
      • mail
      • role (Zugriffsrechte)
      • password
    • version (7) [Version der IOS App] / Einträge gesamt: 2
      • ID (AUTO_INCREMENT)
      • file (Applikation: app, ini)
      • version
      • build
      • file_stamp (ohne Funktion)
      • update_needed (App auf Update Prüfen)
      • update_price (Preisaktualisierung in Arbeit App wird bzw. ist dann gesperrt)
Datenbank Einträge:
  • EE-7E4-3744 (DB-Name)
    • customers
      • 1
        2334
        0
        0
        Benutzer Name
        Benutzer Name
        NULL
        Vorname
        Nachname
        Ort
        NULL
        2021-01-08
        2022-01-14
    • datanorm
      • 1
        0001
        4013456553781
        Benutzer Name
        Benutzer Name
        100000
        528777779
        Kaiser GmbH & Co. KG
        UP-Elektronikdose; D: 60mm; T: 67mm
        UP-Elektronikdose
        1068-02
        2352090
        0
        2610161
        0
        NULL
        NULL
        1
        50
        22
        100
        514.39
        642.99
        18/23
        0
        1
        0
        6
        12
        2020-09-04
        2022-11-01
        2022-10-20
    • manufacturers
      • 1
        528777779
        Benutzer Name
        Benutzer Name
        Kaiser GmbH & Co. KG
        100000
        100500
        23
        500
        2021-03-30
        2022-11-26
    • materials
      • 1
        5
        2334
        89585666
        Benutzer Name
        Benutzer Name
        100006
        528777779
        Kaiser GmbH & Co. KG
        Hohlwand Gerätedose - Mittel; D68mm; T: 49mm
        Hohlwand Gerätedose - Mittel
        9063-02
        5669900
        NULL
        NULL
        8
        NULL
        NULL
        NULL
        2021-03-30
        2022-11-26
        2021-01-30
    • projects
      • 1
        2334
        89585666
        Benutzer Name
        NULL
        Benutzer Name
        Kundenprojekt Name
        0
        1
        2021-01-08
        NULL
        2021-01-30
    • users
      • 1
        IOS ID
        Benutzer Name
        Mail
        Role
        Passwort
    • version
      • 1
        app
        1.1.9
        230508-195
        2022-12-23
        1
        0
Das ist nun im Endeffekt meine Ausgangssituation wie ich es mir damals erstellt habe und immer mal wieder etwas hinzufüge anpasse etc.
Ich hoffe man kann es verstehen wie ich es dargestellt habe wie es aussieht und aufgebaut ist. (ich weis die Namen sind nicht Ideal die werde ich auch anpassen wenn ich meine App weiter bearbeiten werde)

Und das ganze mit Pandas war nur eine Idee bzw. Frage ob man das so machen kann/darf genauso wie das man die Daten alle am Anfang einliest.

Bin gespannt auf eure Meinung dazu.

Gruß
Kalysto

P.s. Habe auch eine Test-Datei erstellt: wie kann ich diese hier Bereit stellen ?
habe sie mit MariaDB getestet
Zuletzt geändert von Kalysto am Dienstag 16. Mai 2023, 18:33, insgesamt 1-mal geändert.
Kalysto
User
Beiträge: 117
Registriert: Freitag 14. April 2017, 15:28

__blackjack__ hat geschrieben: Montag 15. Mai 2023, 20:36 @Kalysto: Wenn die Daten als *eine* Tabelle vorliegen, die in einen Pandas-DataFrame geladen werden, gibt es doch einen ganzen Haufen Speicherformate. CSV-Dateien, Excel, HDF5, Feather, Parquet, …
Nicht das wir uns Falsch verstehen, Die Daten habe ich alle Selbst erstellt in der SQL-Datenbank ich bekomme also von keinem irgend eine Liste etc. falls du das meintest.

Und noch ein springender Punkt, ich bin in meiner Auswahl auch irgend wo begrenz da ich eben auf der IOS Platform mit Pythonista agiere sprich es gehen nicht alle dinge wie auf einem PC / MAC
Benutzeravatar
grubenfox
User
Beiträge: 432
Registriert: Freitag 2. Dezember 2022, 15:49

sind das jetzt wirklich die Tabellen und in denen steht überall 'manufacturer (Herstellername)' doppelt und dreifach drinnen oder sind das Views die sich jeweils den 'manufacturer (Herstellername)' mit einem Join aus einer Hersteller-Tabelle mittels der 'manufacturer_ID (Hersteller Identifikationsnummer)' ziehen?
__deets__
User
Beiträge: 14543
Registriert: Mittwoch 14. Oktober 2015, 14:29

Das Argument mit Pythonista ist hier Quatsch. Du benutzt SQLite, und das kann natürlich mehrere Tabellen verarbeiten, wie man es bei relationalen Datenbanken eben so tut. Die Entscheidung, nur eine große Tabelle, mit vielen Daten unnötig gedoppelt, zu verwenden, ist schon deine.
Kalysto
User
Beiträge: 117
Registriert: Freitag 14. April 2017, 15:28

grubenfox hat geschrieben: Dienstag 16. Mai 2023, 18:42 sind das jetzt wirklich die Tabellen und in denen steht überall 'manufacturer (Herstellername)' doppelt und dreifach drinnen oder sind das Views die sich jeweils den 'manufacturer (Herstellername)' mit einem Join aus einer Hersteller-Tabelle mittels der 'manufacturer_ID (Hersteller Identifikationsnummer)' ziehen?
Ja, also der Herstellername steht jeweils in der Tabelle von: manufacturers, datanorm und materials.
nein, kein Join die Daten sind dort effektiv eingetragen als "Werte"

wäre es einmal möglich das du an dem Obigen bsp. mir ein bsp. zeigen würdest wie ich das verbessern könnte das es richtig wäre ?
Zuletzt geändert von Kalysto am Mittwoch 17. Mai 2023, 20:26, insgesamt 1-mal geändert.
Kalysto
User
Beiträge: 117
Registriert: Freitag 14. April 2017, 15:28

__deets__ hat geschrieben: Dienstag 16. Mai 2023, 23:11 Das Argument mit Pythonista ist hier Quatsch. Du benutzt SQLite, und das kann natürlich mehrere Tabellen verarbeiten, wie man es bei relationalen Datenbanken eben so tut.
Das war doch auch gar nicht darauf bezogen......
sondern darauf das man eben nicht alle Module verwenden kann wenn man nun andere in Betracht ziehen sollte.....
__deets__ hat geschrieben: Dienstag 16. Mai 2023, 23:11 Die Entscheidung, nur eine große Tabelle, mit vielen Daten unnötig gedoppelt, zu verwenden, ist schon deine.

Ja, weil ich es eben nicht besser und anders wusste deswegen bin ich ja hier um dinge verbessern zu können und anders aufzubauen.... :D
Benutzeravatar
grubenfox
User
Beiträge: 432
Registriert: Freitag 2. Dezember 2022, 15:49

Kalysto hat geschrieben: Mittwoch 17. Mai 2023, 20:22 wäre es einmal möglich das du an dem Obigen bsp. mir ein bsp. zeigen würdest wie ich das verbessern könnte das es richtig wäre ?
[Kurzfassung: ich kann nicht wirklich zeigen, jedenfalls nicht wirklich getestet... Wenn das
Ich verwende nun SQLAlchemy in Verbindung mit dem mysql.connector
noch stimmt: ich habe hier weder das eine, noch das andere in Gebrauch. Ich habe hier nur eine sqlite3-Datenbank für die ich gerade aktuell ein paar Abfragen schreiben möchte. Möglicherweise gibt es da Detailunterschiede im SQL-Dialekt zwischen den Systemen.]

Also das wichtige zuerst: ein einziges so ist es richtig gibt es nicht! Alles eine Frage der Anforderungen. Eine Suche nach normalize good bad liefert offenbar schon einige Webseiten mit Pro und Kontra. Ich habe mir jetzt keinen einzigen angeschaut, kann also nichts zu den Artikeln sagen.
Kalysto hat geschrieben: Mittwoch 17. Mai 2023, 20:22 Ja, also der Herstellername steht jeweils in der Tabelle von: manufacturers, datanorm und materials.
nein, kein Join die Daten sind dort effektiv eingetragen als "Werte"

wäre es einmal möglich das du an dem Obigen bsp. mir ein bsp. zeigen würdest wie ich das verbessern könnte das es richtig wäre ?
Zur Warnung: je nach genauer Struktur/Aufbau der Daten in der Datenbank kann kann es sein dass ich hier falsches zeige, weil meine Vermutungen zu den unbekannten Daten von der Realität abweicht.
Dann als Kurzfassung: bei den Tabellen datanorm und materials die Spalte mit Herstellername rauswerfen und nur die manufacturer_ID stehen lassen. Hier vermute ich dass zum einen jeder Hersteller nur eine manufacturer_ID hat [das steht wohl auch schon so in der Beschreibung der manufacturers-Tabelle: (Angabe einer „Herstellerkundennummer“ / einmalig je Hersteller)], aber zum anderen es jede vorhandene manufacturer_ID auch nur einmal vergeben ist. Es keine manufacturer_ID gibt, die bei mehreren Firmen eingetragen ist.

Ich lasse das jetzt (um diese Uhrzeit) mit dem SQL-Beispiel. Dafür habe ich ein Gegenfrage: Wie ist das mit dem

[ich breche hier ab, zu spät, kann nicht mehr klar denken. Vielleicht später, wenn ich wieder wach bin, mehr...]

gute Nacht!
Benutzeravatar
sparrow
User
Beiträge: 4195
Registriert: Freitag 17. April 2009, 10:28

@Kalysto: __blackjack__ hat den Wikipedia Artikel zu Normalisierung gezeigt. Hast du den gelesen? Detaillierter wird das hier niemand erklären können.
Kalysto
User
Beiträge: 117
Registriert: Freitag 14. April 2017, 15:28

sparrow hat geschrieben: Donnerstag 18. Mai 2023, 04:43 @Kalysto: __blackjack__ hat den Wikipedia Artikel zu Normalisierung gezeigt. Hast du den gelesen? Detaillierter wird das hier niemand erklären können.
Ja, den habe ich Gelsen ich weis aber nicht wie ich das auf meine Datenbanken anwenden sollte....
andernfalls lass ich das eben so wie es ist da ich meine Daten nur über die eigentliche ID oder über QR-Code, EAN-Codes aufrufe und diese gibt es eben nur einmalig...
Kalysto
User
Beiträge: 117
Registriert: Freitag 14. April 2017, 15:28

grubenfox hat geschrieben: Donnerstag 18. Mai 2023, 00:08 Zur Warnung: je nach genauer Struktur/Aufbau der Daten in der Datenbank kann kann es sein dass ich hier falsches zeige, weil meine Vermutungen zu den unbekannten Daten von der Realität abweicht.
Dann als Kurzfassung: bei den Tabellen datanorm und materials die Spalte mit Herstellername rauswerfen und nur die manufacturer_ID stehen lassen. Hier vermute ich dass zum einen jeder Hersteller nur eine manufacturer_ID hat [das steht wohl auch schon so in der Beschreibung der manufacturers-Tabelle: (Angabe einer „Herstellerkundennummer“ / einmalig je Hersteller)], aber zum anderen es jede vorhandene manufacturer_ID auch nur einmal vergeben ist. Es keine manufacturer_ID gibt, die bei mehreren Firmen eingetragen ist.
Selbst wenn ich Herstellername "raus" werfe habe ich immer noch gleiche Tabellen wie customer_ID etc... da auch diese bei jedem Material welcher einen gleichen Kunden haben mit angefügt wird...

manufacturer_ID wird auch immer doppelt in der DB stehen da jedes material dessen Hersteller gleich ist die selbe ID erhält...

von dem her weis ich nicht wie ich das in meinem Falle umsetzen sollte....
Benutzeravatar
sparrow
User
Beiträge: 4195
Registriert: Freitag 17. April 2009, 10:28

@Kalysto: Ja klar bleibt eine manufacturer_id in der Tabelle. Aber du hast andere Spalten, die sich ebenfalls auf den Hersteller beziehen. Die müssen aus der Tabelle raus. "Manufacturer" ist eine eigene Relation. Und darin enthalten ist u.a. der Name.

Wie gesagt, lies bitte den Wikipedia-Artikel. Der erklärt Noralisierung wirklich gut anhand von Musikalben.

Ich sehe das ebenso, wie andere Leute hier im Thread. Du verwechselst eine relationale Datenbank mit einer Tabellenkalkulation.
Und ich sehe auch nicht, warum man hier Pandas benutzen muss. Ich würde das mit einer vernünftigen und sauberen Datenbankstruktur aufsetzen und SQLAlchemy benutzen. Den Mehrwert von Pandas sehe ich hier nicht.
Antworten