[Gispelmob]

Ja das meine ich so, wobei die Artikel ID bei mir kein (TINY/SMALL/MEDIUM/BIG) INT ist sondern eine CHAR ID mit 36 Zeichen im Format 08s-%04s-%04x-%04x-%012s. Sieht aus wie dfc09517-74fa-4028-ac95-1211ad1e9571.

Pro Artikel wird eine neue eindeutige ID erzeugt und nach Erzeugung geschaut ob diese nicht vielleicht doch schon in der Liste existiert und ggf. eine neue erzeugt. Diese generierte ID nutzt ich bei Einträgen die immer wieder neu und immer wieder in unbekannter Anzahl auftreten können.

Für feste Werte wie z.B. für sowas wie Farben die bei den Artikeln nicht in unendlich großer Anzahl auftreten sondern nur B, C, M, K sind reicht dann aber wieder eine kleine Tabelle mit TINYINT/BIT und 1, 2, 3, 4 als ID.

So, nun wieder zum Thema.

Nach Umbauarbeiten sieht die Tabelle articles so aus

id
manufacturer_id
name
color

Das ist die Basistabelle in der jeder Artikeltyp einmal drin steht.

Jetzt fehlt noch die Tabelle mit Anzahl und Artikelzustand, wobei ein Artikel mehrere Artikelzustände haben kann. Momentan ist das so:

article_stock

article_id
stock

article_conditions

article_id
welded
damaged
sealed
pasted
dirty
open
packaging

Bei welded, open, sealed gibt es nur 2 Zustände. Bei den restlichen gibt es 4 Zustände. Ich löse das so, in dem ich 0 als default Wert für Zustand 1 setze und dann jeweils 1-3 für die anderen 3 Zustände. Ein Artikel bei dem alles in Ordnung ist bei dem steht dann überall 0 drin.

So nun aber das Problem, dass dies nicht mit der Anzahl verknüpfbar ist.

Wenn ich nun 2x Artikel A haben bei dem alles in Ordnung ist und einen Artikel A bei dem Beschädigungen festgestellt werden, ist das so momentanen in der Struktur nicht abbildbar. Ich kann sie aber auch nicht einfach zusammenfassen.

Deswegen such ich ja Ideen und da hilft mir keine Diskussion über IDs.^^ Es ist auch relativ egal wie lang ein ID ist. Sie muss eindeutig sein.

Dieser Beitrag wurde von Gispelmob bearbeitet: 02. Dezember 2016 - 07:30

[Holger_N]

Zitat (Gispelmob: 01. Dezember 2016 - 22:01)

…Du kannst aber auch deine Haustür abschließen und dir deinen Schlüssel wegnehmen damit du nicht ungefragt in dein Haus gehst ohne ein Passwort zu nennen.^^

Ahja, das Argument der UAC-Abschalter.

[Gispelmob]

Zitat (Holger_N: 02. Dezember 2016 - 09:42)

Ahja, das Argument der UAC-Abschalter.

Bei mir ist ersten die UAC an und zweitens hat das nichts mit dem Thema zu tun.

[Holger_N]

Zitat (Gispelmob: 02. Dezember 2016 - 10:24)

Bei mir ist ersten die UAC an und zweitens hat das nichts mit dem Thema zu tun.

Es geht um das Weglassen irgendwelcher sicherheitsrelevanten Einstellungen oder Mechanismen, begründet mit dem Argument »Ich bin ja der einzige User« und das zieht sich mehr oder weniger abstrakt durch das Thema und alle meine Beispiele. Nun ist mir inzwischen natürlich klar, dass wenn man das nicht erkennt, es auch nicht versteht.

[Gispelmob]

Solang an einer Datenbank entwickelt wird und man der einzige Entwickler ist, werden sicherheitsrelevante Mechanismen immer weggelassen. Die werden erst integriert wenn die DB fertig ist und man dann die Anwendungsebene entwickelt die nicht mit vollen Rechten zugreifen soll.

Verkomplizier doch deine Projekte so wie du willst. Ich arbeite jedoch der Reihe nach die Entwicklungsschritte ab und dazu gehört nicht schon vor der Fertigstellung der DB irgendwelche Passwortabfragen einzubauen oder eingeschränkte Rechte zu verteilen weil das nämlich die Entwicklung nur aufhält. Und damit nicht später nochmal an den Sicherheitsaspekten gearbeitet werden muss weil sich in der Zwischenzeit die DB geändert hat, wird das erst in den nächsten Schritten umgesetzt. Das ist genau das was du nicht verstehst.

So und jetzt nochmal. Was hat deine Diskussion mit der Umsetzung des Artikelzustandes zu tun und den es hier geht?

Dieser Beitrag wurde von Gispelmob bearbeitet: 02. Dezember 2016 - 11:14

[RalphS]

Ja, Dir fehlt die StockId als PK. Sonst kannst Du ja nicht sagen, WAS da eindeutig sein soll. StockId bezeichnet dann konkrete Artikel. Da reicht 1:n, eine stock- artikel- Assoziationstabelle solltest Du nicht brauchen.

[Holger_N]

Zitat (Gispelmob: 02. Dezember 2016 - 11:08)

So und jetzt nochmal. Was hat deine Diskussion mit der Umsetzung des Artikelzustandes zu tun und den es hier geht?

Warum willst Du das ausdiskutieren, wenn es Deiner Meinung nach gar nicht zum Thema gehört? Du denkst viel zu unlogisch.

[Gispelmob]

Ich versteh immernoch nicht genau wie ich es machen könnte. Ich vereinfach mal:

id; neu; gebraucht; beschädigt

id_1; 2; 0; 0
id_1; 1; 0; 1
id_1; 0; 2; 0
id_1; 0; 2; 2

Das wären 4 Einträge für einen Artikel der ingesamt 7 mal vorhanden ist, 3x neu (einmal davon beschädigt) und 4x gebraucht (zwei davon beschädigt). Man könnte es zu einer Zeile zusammenfassen

id_1; 3; 4; 3

Leider ist so aber nicht mehr auflösbar wieviele neue und wieviele gebrauchte beschädigt sind sondern nur noch die Gesamtzahl der beschädigten. Insgesamt gibt es übrigends 6 Merkmale die den Artikelzustand beschreiben und die in jeder möglichen Kombination zusammen auftreten können.

Momentan hab ich nur die obere Lösung und die Anzahl pro Artikel wird mit GROUP BY und COUNT ermittelt.

Eindeutig ist nur die ID und die kann durch die verschiedenen möglichen Artikelzustände mehrfach in der Tabelle stehen was mir nicht gefällt. Ich komm da mit den Normalformen nicht weiter.

[RalphS]

So Minitabellen mit drei oder was eindeutigen Werten kann man durchaus in Enumtypen stopfen oder mit Checks absichern.

Und irgendwie reden wir aneinander vorbei oder haben Probleme mit der Nomenklatur oder beides. Keine Ahnung.

Ich versuchs noch mal und bitte darum, mir ggf Namenskonflikte nicht vorzuwerfen.

Ad 1. Wir haben eine Tabelle wo reale Gegenstände reinkommen.

ID=PK; ZustandID=FK(Zustand), ProduktID=FK(Produkt).

Damit haben wir beispielsweise einen Artikel mit der ID 23, der hat Zustand 2 und ist vom (Produkt-)Typ 8.

Dazu bauen wir eine Tabelle Zustand, ODER wir definieren uns einen Enum-Typen für den Zustand, je nachdem wie umfangreich das sein muß mit dem Zustand. (Alles was über ein Wort rausgeht wäre in einer Tabelle besser aufgehoben und wenn mehrere Attribute erforderlich werden versagt enum sowieso.)

Also haben wir entweder enum(Gut,Angeschlagen,Schlecht) oder Zustand: ID=PK; Name und Beschreibung. Evtl noch weiteren Attributen, sagen wir Klasse und dann haben wir eben eine Familie von Zuständen mit "Klasse A" und eine andere mit "Klasse B". Da reicht dann ein enum oder ein simpler Char(1)Datentyp.

Hier drin haben wir nun einen Eintrag (2, 'Wie neu', 'Rückläufer oder refurbished' und wissen jetzt außerdem, daß unser Gegenstand mit der ID 23 (und nur der) den Zustand "wie neu" hat.

Jetzt brauchen wir natürlich noch ne Vorstellung was das für ein Produkt sein soll, weil bisher wissen wir ja nur, daß Gegenstand #23 "wie neu" ist, aber noch nicht was genau (okay, es ist ne 8).

Ergo die Produkttabelle. Hier steht jetzt drin sowas wie ID=PK; Produkttype=FK(Subtypen);Name, Beschreibung, Einkaufspreis, was weiß ich. In Subtypen würde in diesem Fall sowas stehen wie "Lebensmittel" oder "Sportwaren" oder so, damit das nicht redundant wird; wenn man das weglassen kann, spart man sich natürlich diese Tabelle.

Und wenn wir hier unter ID=8 jetzt eintragen, daß das ein Brot ist (mit Subtype gleich 1 wie "Lebensmittel" in dieser Tabelle), dann wissen wir schlußendlich auch, daß unser Gegenstand 23 eindeutig a) ein Brot ist, b) "Wie neu" (refurbished)" ist - also schon mal gegessen, aber neu verpackt.


Redundanzen gibt es jetzt keine mehr, und Mehrdeutigkeiten auch nicht. Die Gegenstandstabelle sagt mir, was es im Lager gibt, zB mit der ausgewiesenen Inventarnummer; die Zustandstabelle ordnet jedem Gegenstand einen Zustand zu (genauer: das tut die Gegenstandstabelle selber); und die Produkttabelle verhält sich ganz analog => beide werden einfach von der Gegenstandstabelle referenziert.

Wenn die Datenbank den Rest ermitteln kann, dann hast Du schon alles richtig gemacht: Select Z.ID, Z.Name, count(*) from Gegenstände AS G JOIN Zustand AS Z ON(g.zustandid=Z.id) GROUP BY ZustandID würde Dir dann aufschlüsseln, wieviele Produkte mit dem jeweiligen Zustand in der Datenbank vorhanden sind.

Dieser Beitrag wurde von RalphS bearbeitet: 03. Dezember 2016 - 00:13

[Gispelmob]

Zitat (RalphS: 02. Dezember 2016 - 20:54)

Ad 1. Wir haben eine Tabelle wo reale Gegenstände reinkommen.

ID=PK; ZustandID=FK(Zustand), ProduktID=FK(Produkt).

Damit haben wir beispielsweise einen Artikel mit der ID 23, der hat Zustand 2 und ist vom (Produkt-)Typ 8.

Also jedem real vorhanden Artikel, egal ob er schonmal vorliegt oder nicht eine neue ID in dieser Tabelle geben. Die Referenzierung um welchen Artikel es sich handelt, wird dann über die ProduktID gemacht. Ich vermute so meinst du das.

Produkttyp brauch ich derzeit nicht. Es handelt sich auschließlich um den selben Produkttyp, jedoch werde ich vorsichtshalber auch eine Produktgruppe mit integrieren für eine eventuelle spätere Erweiterung.

Zitat (RalphS: 02. Dezember 2016 - 20:54)

Dazu bauen wir eine Tabelle Zustand, ODER wir definieren uns einen Enum-Typen für den Zustand, je nachdem wie umfangreich das sein muß mit dem Zustand. (Alles was über ein Wort rausgeht wäre in einer Tabelle besser aufgehoben und wenn mehrere Attribute erforderlich werden versagt enum sowieso.)

Ich habe, da es 6 verschiedene Attribute gibt mit jeweils 2-4 unterschiedlichen Werten zur Beschreibung des Zustandes, derzeit 6 Tabellen für die Zustände. Ich könnte also, da in der Artikeltabelle bereits die ProduktID drin steht, dort auch noch 6 Felder anlegen die dann den FK der jeweiligen Zustandsbeschreibung jedes einzelnen Artikels enthalten.

ID=PK; ProduktID=FK(Produkt); Anzahl; Zustand_A_ID=FK(Zustand_A); Zustand_B_ID=FK(Zustand_B); Zustand_C_ID=FK(Zustand_C) ...

Zitat (RalphS: 02. Dezember 2016 - 20:54)

Ergo die Produkttabelle. Hier steht jetzt drin sowas wie ID=PK; Produkttype=FK(Subtypen);Name, Beschreibung, Einkaufspreis, was weiß ich. In Subtypen würde in diesem Fall sowas stehen wie "Lebensmittel" oder "Sportwaren" oder so, damit das nicht redundant wird; wenn man das weglassen kann, spart man sich natürlich diese Tabelle.

Die ist bereits vorhanden und da steht drin derzeit id=PK, manufacturer=FK, name, color=FK group_id=FK

Dieser Beitrag wurde von Gispelmob bearbeitet: 03. Dezember 2016 - 08:12

[RalphS]

Richtig, und das ist auch genau der Punkt: ein Artikel *kann nicht* schon mal vorliegen. Ich mein ich weiß wie Du das meinst, aber IRL™ ist es halt so, daß man nicht zweimal denselben Artikel haben kann. Die können bis aufs letzte Hemd gleich aussehen und auch zu 100% dieselben Eigenschaften haben, aber es sind zwei Artikel, wo man den einen dem einen geben kann und den anderen dem anderen, aber wenn noch wer drittes kommt und ebenfalls so einen Artikel mit diesen Eigenschaften haben will dann hat der Pech weil die ZWEI Artikel vergeben sind.

Mit den Zuständen, mh, so wie Du es hast funktioniert es natürlich, allerdings wäre es vielleicht eine Überlegung wert, die Zustände so umzudefinieren, daß sie doch wieder in eine Tabelle passen. Hierfür gibt es ja die Enum-Typen.

Das kommt aber hier ganz stark darauf an, ob Du einen festen Zustandssatz hast oder ob dieser auch veränderlich ist oder sein soll; daß also auch mal neue abprüfbare Zustände dazukommen können oder nicht.

Ist der Zustandssatz definiert, kannst Du problemlos Spalten "Alter" oder "Farbe" oder "Qualität" zuordnen und denen Integerwerte geben, die den Zustand in dieser Spalte beschreiben (say, 1 wie perfekt bis 10 wie ohgottgehtgarnicht). Hierfür die erwähnten Enums/CHECKs, damit läßt sich das gut einschränken.

Ist der Zustandssatz aber undefiniert und veränderlich, wirst Du über eine Zuordnungstabelle nicht drumrumkommen.

Das wird dann aber etwas umständlicher, weil Zustandssätze dann Produktgruppen zugeordnet werden müßten: Flüssigkeiten können einen Füllstand haben, für andere Gruppen wäre dieses Attribut albern. Lebensmittel können ein Verfallsdatum haben, andere Produktgruppen "vielleicht" auch, aber definitiv nicht zwangsläufig.
Also müßte man schauen, daß man (Produktgruppe, Zustandssatz) in einer Tabelle zugeordnet kriegt und müßte außerdem noch eine Tabelle haben, die Zustände und deren Wert eben jene Zustandssatz-ID zuweist. (Mehr bräuchte man dafür ja nicht, hier ist nur ein Schlüssel für eine Partitionierung erforderlich.) Das macht dann schon die Produktgruppentabelle wo die namentlich drin stehen, die Zustandstyp-Tabelle, wo die Zustände benannt werden (Alter, Schönheit,...) und noch die Tabelle mit den Werten drin (jung, naja-nicht-so).

Dafür kann das dann aber alles da rein und du brauchst nicht neue Tabellen für jeden neuen Zustand.

[Gispelmob]

Zitat (RalphS: 03. Dezember 2016 - 09:00)

Mit den Zuständen, mh, so wie Du es hast funktioniert es natürlich, allerdings wäre es vielleicht eine Überlegung wert, die Zustände so umzudefinieren, daß sie doch wieder in eine Tabelle passen. Hierfür gibt es ja die Enum-Typen.

die Tabellen für die Zustände sind dafür gedacht um dort den Beschreibungstext des Zustandes mit einzutragen.

id=PK, name=char, desc=text

Das klappt mit Enum nicht, da könnte ich maximal den Namen des Zustandes unterbringen. In der Produkttabelle setze ich einfach die IDs der Zustände ein und kann per JOIN die Namen und Beschreibungen mit abfragen.

In eine Tabelle eintragen könnte ich die Zustände schon. Ich müsse dann nur die IDs immer verdoppeln. Also nicht 1,2,3,4,5,6 ... sondern 1,2,4,8,16,32... Auf diese Weise kann man durch einfache Addition einem Artikel mehrere Zustände gleichzeitig zuordnen und später per Subtraktion wieder in die Einzelheiten zerlegen und spart so Platz da man nur lediglich ein Feld pro Produkt benötigt und alle Zustände inklusive Beschreibung in einer Tabelle stehen können.

Dieser Beitrag wurde von Gispelmob bearbeitet: 03. Dezember 2016 - 09:37