ubuntuusers.de

Lysander schrieb:

Hört sich erst einmal ganz sinnvoll an, wobei klar ist, dass man bei "n"-Formaten "n"-Konverter benötigt.

Nobuddy schrieb:

Dieses Datenformat sieht folgendermaßen aus:

Du musst Dich bei Python von den rein Datei zentrierten "Datentypen" trennen. Letztlich sind das (Text-)Formate für Persistenzen; da würde ich sowieso auf ein etabliertes Format a la JSON, XML, CSV usw. setzen. Hängt ein wenig vom Anwendungsfall ab. Du brauchst vor allem eine interne Repräsentation mit Hilfe der Datentypen von Python. Das kann im einfachsten Falle eine Liste von Dictionaries sein, oder gar NamedTuples oder sogar Klassen.

Das dies alles letzendlich Text-formate sind, ist mir schon klar, muß mich daran noch gewöhnen und hineinarbeiten.

Momentan nutze ich ja noch txt-Dateien. Macht es einen Vorteil, gleich auf das csv-Format umzusteigen?

Ich weiß, dass Du hier grad über eine "zentrale" Registerdatei sprichst, die Du bereits hast... aber bei Deiner Vorgehensweise solltest Du Dir schon überlegen, dass Du da das Parsen und den inhatlichen Abgleich nicht vermischst.

Ja, ich weiß und das geht auch nur Schritt für Schritt, ist ja alles noch in der 'Entwicklungsphase' und das wird auch eine ganze Weile noch so bleiben, bis ich mir 100-prozentig sicher bin.

Grundsätzlich ist mir der komplette Anwendungsfall noch im Dunkeln. Wenn ich etwas von EAN höre, dann denke ich erst einmal an eine ID, die Hersteller unabhängig ist. Wenn dem so ist, so sollte diese auch nicht mit einem Hersteller fix verbunden sein. Zudem wäre das ein Produkt / Artikel, welcher bestimmte Kriterien eben Hersteller / Lieferanten unabhängig besitzt.

Ja der EAN-Code ist ja auch eine ID im eigenlichen Sinne. Bei der 13-stelligen EAN, sind die ersten drei Ziffern der Ländercode, die nächsten 5 Ziffern beziehen sich auf den Hersteller und dann noch die Produktnummer.

Dazu kommen dann noch Attribute, die vom Lieferanten abhängig sind, etwa der Preis. In Deinen Datensätzen - wo auch immer die herkommen - ist das ziemlich vermischt. Nun ist die Frage, ob ich hier richtig liege, dass Du das alles konsolidieren willst. Wenn ja, ist die inhaltliche und interne Darstellung der Daten der erste Schritt. Danach kann ich mir Gedanken machen, wie ich die Daten aus den Dateien extrahiere.

Du liegst da völlig richtig, als Erstes und Wichtigstes < inhaltliche und interne Darstellung der Daten >

Nobuddy schrieb:

Momentan nutze ich ja noch txt-Dateien. Macht es einen Vorteil, gleich auf das csv-Format umzusteigen?

CSV ist auch ein Textformat 😉 Nur eben ein "spezielles". Pauschal kann man da nicht viel sagen; CSV steht ja für Comma Separated Values - also durch Komma getrennte Daten. (Wobei der Trenner eben nicht zwangsweise ein Komma sein muss).

Wichtig war mir in diesem Absatz eher aufzuzeigen, dass Du erst einmal eine interne Datenstruktur brauchst! Wo dann die Daten herkommen, ist letztlich egal. Und da solltest Du Dir als erstes jetzt mal Gedanken machen.

Mach Dir eines klar: Du willst ja mit den Daten später irgend etwas machen. Also schwebt Dir ja schon vor, welche Daten Du haben willst. Diese musst Du irgend wie sinnvoll abbilden und zwar in Python und nicht in einer Datei. Natürlich müssen diese Daten irgend wann einmal aus einer Datenquelle kommen und vermutlich sollen sie auch wieder irgend wo persistent abgelegt werden, aber das hat nichts mit der internen Repräsentation zu tun. Es müssen ja nicht mal Datei zentrierte Formate sein; man denke nur an eine Datenbank - iirc wolltest Du da ja sogar mal hin.

Also, wie stellst Du Dir ein Datenformat vor? Entwirf doch mal eines und stell das hier vor. Versuche Dir dabei zu überlegen, welche Operationen Du auf diesen Daten durchführen willst, z.B. bestimmte Felder in den Daten durchsuchen, usw.

Meinst das etwa so:

1	Lieferantkurznummer
2	Artikelnummer			# Bestellnummer des Lieferanten
3	Benennung			# Produktkurzbeschreibung
4	Produktbeschreibung		# Ausführliche Produktkurzbeschreibung
5	Hersteller			# Basiswert
6	Herstellernummer		# Basiswert
7	Packungseinheit			# Stück, Blatt, Kilogramm, Liter usw.
8	Inhalt				# Basiswert
9	MwSt-Gruppe			# 2 = voller MwSt-Satz; 1 = ermäßigter MwSt-Satz
10	Menge				# Mindestmenge
11	Ek				# Einkaufswert pro 1
12	Vk				# Empfohlener Verkaufspreis, Lieferant
13	Menge2				# Mengenstaffel 2
14	Ek2				# Einkaufswert pro 1, ab Menge2
15	Vk2				# Empfohlener Verkaufspreis 2, Lieferant
16	Menge3				# Mengenstaffel 3
17	Ek3				# Einkaufswert pro 1, ab Menge3
18	Vk3				# Empfohlener Verkaufspreis 3, Lieferant
19	Gewicht				# Produktgewicht, Berechnung Transport
20	EAN				# Hersteller-Produkt-ID
21	Hauptgruppe			# Produktspezifisch
22	Untergruppe			# Produktspezifisch
23	Katalogseite mit Seitenzusatz	# Kataloginfo
24	Lagerstatus			# Lieferung von Lieferant oder ab Hersteller

Wenn nein, vielleicht ein kleines Beispiel?

Ich meine so etwas:

1
2
3
4
5

artikel = {
    "artikel_id": 123456,
    "benennung": "Tolle Taschenlampe",
    "vk": "1234"
}

Einfach eine Python-Datenstruktur. Diese (Listen, Dictionaries, Tuples, Sets, ... usw.) werden im offiziellen Python-Tutorial zu Beginn behandelt. Das sind die absoluten Grundlagen!

Hier musst Du Dich fragen wie Du diese ganzen Infos intern speichern willst. Welches sind die richtigen Datentypen usw. Vermutlich musst Du das ein oder andere auch schachteln, oder in Beziehung zueinander setzen.

Dann würde ich das mal so darstellen:

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179

artikel = {
	"hersteller": "Blender",
	"herstellernummer": "047811",
	"inhalt": "1",
	"artikel_id": "123456",
	"lieferant_id": "001",
	"mindestmenge": "1",
	"ek": "1000,00",
	"menge2": "3",
	"ek2": "995,00",
	"menge3": "10",
	"ek3": "990,00",
	"eancode": "4001234500121",
	"hauptgruppe": "127",
	"untergruppe": "235",
}

basisdaten = {
	"hersteller": "Blender",
	"herstellernummer": "047811",
	"inhalt": "1",
	"benennung": "Tolle Taschenlampe",
	"produktbeschreibung": "Tolle Taschenlampe ... blabla",
	"mwstgruppe": "2",
	"mindestmenge": "1",
	"vk": "1234,00",
	"menge2": "3",
	"vk2": "1200,00",
	"menge3": "10",
	"vk3": "1195,00",
	"hauptgruppe": "01",
	"untergruppe": "78",
}

mwst = {
	"2": "0,19",
	"1": "0,07",
}

produktgruppen = {
	"hersteller": "Blender",
	"herstellernummer": "047811",
	"inhalt": "1",
	"hauptgruppe": "01",
	"untergruppe": "78",
	"lief_001_hg": "127",
	"lief_001_hg": "235",
	"lief_002_hg": "xyz",
	"lief_002_hg": "lol",
	...,
	..,

lieferant = {
	"lieferant_id": "001",
	"name": "Beispielname",
	...,
	..,
	"skonto": "0",
	"skontozeit": "0",
	"nettozeit": "10",
}

kunde = {
	"kunden_id": "001",
	"name": "Beispielname",
	...,
	..,
	"skonto": "0,02",
	"skontozeit": "10",
	"nettozeit": "30",
}

lieferantenbestellung = {
	"auftragdatum": "03.01.2012",
	"auftrag_id": "000234",
	"bestellmenge": "2",
	"liefermenge": "2",
	"restmenge": "0",
	"artikel_id": "123456",
	"ek": "1000,00",
	"mwst": "0,19",
	"hersteller": "Blender",
	"herstellernummer": "047811",
	"inhalt": "1",
	"lieferant_id": "001",
	"lieferdatum": "05.01.2012",
	"lieferschein": "4711",
	"rechnungdatum": "06.01.2012",
	"rechnung": "124711",
	"infofeld": "",
	"kundenbezug": "kunden_id",
}

kundenbestellung = {
	"auftragdatum": "03.01.2012",
	"kunden_id": "001",
	"bestellmenge": "1",
	"liefermenge": "1",
	"restmenge": "0",
	"artikel_id": "123456",
	"hersteller": "Blender",
	"herstellernummer": "047811",
	"inhalt": "1",
	"vk": "1234,00",
	"mwst": "0,19",
	"lieferdatum": "05.01.2012",
	"lieferschein": "123456",
	"rechnungdatum": "06.01.2012",
	"rechnung": "2012123456",
	"kundenbestellzusatz": "Vertrieb",
	"infofeld": "",
}

lieferantenrechnung = {
	"lieferdatum": "05.01.2012",
	"lieferschein": "4711",
	"rechnungdatum": "06.01.2012",
	"rechnung": "124711",
	"lieferant_id": "001",
	"positionen": "1",
	"nettowert": "2000,00",
	"mwst": "0,19",
	"mwstwert": "380,00",
	"bruttowert": "2380,00",
	"gezahlt": "2380",
	"zahldatum": "15.01.2012",
	"kontoausgang": "voba",
}

kundenbestellung = {
	"lieferdatum": "05.01.2012",
	"lieferschein": "123456",
	"rechnungdatum": "06.01.2012",
	"rechnung": "2012123456",
	"positionen": "1",
	"nettowert": "1234,00",
	"mwst": "0,19",
	"mwstwert": "234,46",
	"bruttowert": "1468,46",
	"gezahlt": "1468,46",
	"zahldatum": "20.01.2012",
	"kontoeingang": "voba",
}

rechnung_einausgang = {
	"klient_id": "K001",
	"rechnungdatum": "06.01.2012",
	"rechnung": "2012123456",
	"positionen": "1",
	"nettowert": "1234,00",
	"mwst": "0,19",
	"mwstwert": "234,46",
	"bruttowert": "1468,46",
	"gezahlt": "1468,46",
	"zahldatum": "20.01.2012",
	"konto": "voba",

	"klient_id": "L001",
	"rechnungdatum": "06.01.2012",
	"rechnung": "124711",
	"positionen": "1",
	"nettowert": "-2000,00",
	"mwst": "0,19",
	"mwstwert": "-380,00",
	"bruttowert": "-2380,00",
	"gezahlt": "-2380,00",
	"zahldatum": "20.01.2012",
	"konto": "voba",
}

lager = {
	"hersteller": "Blender",
	"herstellernummer": "047811",
	"inhalt": "1",
	"benennung": "Tolle Taschenlampe",
	"mwstgruppe": "2",
	"ekwert": "1000,00",
	"lagermenge": "1",
}

Dies habe ich mal auf die Schnelle gemacht, Änderungen vorbehalten. 😉

PS: Habe gerade nochmals das Ganze aktualisiert und erweitert.

Denke aber, das im Großen und Ganzen, dies so Sinn macht.

Abgesehen davon, dass es absoluter Overkill ist, gleich so viele Attribute zu behandeln, ist diese Struktur nicht wirklich sinnvoll. Du willst ja gerade beliebig viele Produkte, Hersteller, usw. gleichzeitig behandeln - das klappt aber nicht, wenn Du nur "flache" Dictionaries verwendest. Du brauchst vermutlich Dicts von Dicts oder Listen.

Generell schreit der Ansatz einfach nach einer relationalen DB; am besten in Kombi mit einem ORM. Zudem ist bei derartiger Komplexität fast schon zu einem Klassen basierten Ansatz zu raten.

Allerdings ist das für Dich in dieser Größenordnung alles noch viel zu komplex! Lass es einfacher angehen und konzentriere Dich darauf, die Prinzipien der grundlegenden Datenstrukturen zu verstehen.

Lysander schrieb:

Abgesehen davon, dass es absoluter Overkill ist, gleich so viele Attribute zu behandeln, ist diese Struktur nicht wirklich sinnvoll. Du willst ja gerade beliebig viele Produkte, Hersteller, usw. gleichzeitig behandeln - das klappt aber nicht, wenn Du nur "flache" Dictionaries verwendest. Du brauchst vermutlich Dicts von Dicts oder Listen.

Ich habe die Basisstruktur von den Grundtabellen dargestellt, so wie ich es mir vorstelle und aus meiner bisherigen Erfahrung heraus. Wie das dann letzendlich zu verschachteln ist, kann ich durch mangelnendes Wissen noch nicht umsetzen. Dafür brauche ich noch Hilfe.

Generell schreit der Ansatz einfach nach einer relationalen DB; am besten in Kombi mit einem ORM. Zudem ist bei derartiger Komplexität fast schon zu einem Klassen basierten Ansatz zu raten.

Ja, meine Vorstellung ist sehr komplex. Ich arbeite im Moment noch mit einer MS Access Datenbank, die ich selbst erstellt habe und sehr komplex und umfangreich ist. Da ich kein SQL kann, habe ich zur Zeit der Erstellung, "visuell" Tabellen, Abfragen, Formulare, Berichte und Makros erstellt und durch Formeln Funktionen erstellt. Die Entwicklungszeit ging über einige Jahre. Anfangsfehler konnte ich nur teilweise korrigieren, aber das Wissen und die Vorstellung, wie zukünftig eine neue Datenbank auszusehen hat, sind die Summe meiner Erfahrungen daraus.

Allerdings ist das für Dich in dieser Größenordnung alles noch viel zu komplex! Lass es einfacher angehen und konzentriere Dich darauf, die Prinzipien der grundlegenden Datenstrukturen zu verstehen.

Das weiß ich und möchte deswegen den gleichen Fehler, wie damals nicht noch einmal machen. Deswegen ist es für mich wichtig, durch Leute wie Dich zu lernen und zu verstehen, um nicht beim Dachdecken anzufangen, bevor das Fundament und die anderen grundlegenden Dinge nicht erfüllt sind.

Nobuddy schrieb:

Ich habe die Basisstruktur von den Grundtabellen dargestellt, so wie ich es mir vorstelle und aus meiner bisherigen Erfahrung heraus. Wie das dann letzendlich zu verschachteln ist, kann ich durch mangelnendes Wissen noch nicht umsetzen. Dafür brauche ich noch Hilfe.

Und genau deswegen musst Du Dich versuchen, mit den grundlegenden Datenstrukturen vertraut zu machen. Arbeite doch mal wirklich enrsthaft das offizielle Tutorial durch. Da wird ja ein prima Überblick über die grundlegenden Strukturen gegeben und beschrieben, welche Arten von Daten man damit jeweils gut verwalten kann. Zudem bekommst Du Überblick über die Operationen und Methoden, mit denen man mit den Daten in diesen Strukturen arbeitet. Letztlich kann Dir niemand abnehmen, ein passendes Datenmodell selber zu modellieren. Die Fähigkeit, bekannte Konzepte auf ein gegebenes Problem anzuwenden und dieses mit den Mitteln einer Sprache zu modellieren, ist essenziell für das Programmieren und im Grund genommen der Kern.

Natürlich lernt man das auch durch "doing", aber Theorie gehört auch dazu.

Du musst Dir glaube ich als erstes mal klar machen, wie die einzelnen Daten zusammengehören! Das würde ich mir mal auf einem Blatt Papier aufmalen; das muss kein UML oder ERD sein, sondern irgend eine grafische Repräsentation, die Dir hilft, das ganze Problem zu überblicken. Welche Entitäten will man überhaupt unterscheiden? Wie ist ein Produkt mit einem Hersteller verbunden? Wie identifiziere ich ein Produkt? Was sind die Kardinalitäten der beteiligten Objekte? usw.

Anschließend kannst Du dann gucken, wie Du das in Python-Datenstrukturen umsetzt. Mein Tipp: Lasse dabei "unwichtige" Attribute erst einmal weg. Simple Attribute, die für keinerlei Relation zwischen verschiedenen Strukturen wichtig sind und keinen essentiellen descriptiven Charakter haben, kannst Du am Ende leicht ergänzen! Somit hast Du erst einmal nur wenige wichtige und überschaubare Attribute. Das hilft, nicht den Überblick zu verlieren.

Ich gebe mal ein Beispiel.

Du hast folgendes in Deiner Struktur:

1
2
3
4
5

artikel = {
    "hersteller": "Blender",
    "herstellernummer": "047811",
    ...
}

Wieso vermerkst Du Dir den Klartextnamen des Herstellers in dem Dictionary, welches einen Artikel enthält? (Das taucht auch in einigen anderen Dictionaries auf!) Sinnvoller wäre es nach meiner Auffassung, ein separates Mapping anzulegen, welches von einer Herstellernummer auf den Namen und ggf. weitere Infos eines Herstellers abbildet:

1
2
3
4
5

hersteller = {
    "047811": "Blender",
    "12345": "Noch ne Firma",
    ...
}

Damit kannst Du einfach den Namen zu einer solchen hersteller_id ermitteln:

1
2
3
4

# einen Artikel holen (rein fiktiv)
a = get_artikel("123456", articles)
# Herstellernamen ausgeben:
print "Hersteller: {}".format(hersteller[a["hersteller_id"]])

Generell hast Du Dir nur Gedanken gemacht, wie man jeweils eine "Instanz" einer bestimmten Entität abbilden kann. Aber Du hast ja viele Artikel! Also reicht es nicht, ein Dictionary zu definieren, welches die einzelnen Schlüssel-Wert-Paare eines Artikels aufnimmt, sondern man braucht ja "außen" drum herum noch etwas. Am besten auch ein Dictionary, welches die Artikel_id auf ein Artikel-Dictionary abbildet:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

articles = {
    "123456" = {
	"herstellernummer": "047811",
	"inhalt": "1",
	"artikel_id": "123456",
	"lieferant_id": "001",
	"mindestmenge": "1",
        ...
    },
    "987654" = {
	"herstellernummer": "12345",
	"inhalt": "5",
	"artikel_id": "987654",
	"lieferant_id": "001",
	"mindestmenge": "1",
        ...
    },
}

Wenn Du jetzt die Artikel_id kennst, kannst Du leicht auf die dazugehörigen Daten schließen.

Das sind so Beispiele, wie man es angehen könnte.

Mir ist anhand der Bezeichner nicht klar, wie "artikel", "basisdaten" und "produktgruppen" zueinander in Beziehung stehen. Zudem sehe ich rein äußerlich keinerlei Unterscheidung zwischen "lieferant" und "kunde" und den zugehörigen Strukturen. Gibt es da wirklich eine relevante? Auch da fehlt letztlich das Dictionary außen drum herum.

Also, sieh es als Denkanstoß und versuche mal eine "reduzierte" Struktur aufzubauen. Lass alles wirklich unwesentliche Zeugs erst einmal weg.

Hallo Lysander,

Danke für diesen großen Denkanstoß! 👍

Ich werde mich an Deinen guten Rat halten und versuchen die Vorgehensweise umzusetzen.

Das mit der DB wird jedenfalls noch auf sich warten lassen, bis ich mehr Hintergrundwissen mir darüber angeeignet habe.

Was ich jetzt noch vertigstellen möchte, ist die Basisdatei für die Lieferanten-Produktdaten.

Dazu habe ich noch einen weiteren Thread offen, bei dem Du Dich auch schon gemeldet hast.

Grüße Nobuddy