[Gispelmob]

Kurze Frage

Eine Datenbank enthält eine Tabelle articles:

id
name
description
....

Wenn ich jetzt mehrere gleiche Artikel besitze ist dass kein Problem solang alle den gleichen Artikelzustand haben. Wenn aber nun zB. ein Artikel neu ist und ein zweiter gebraucht, der dritte ist auch neu aber die Verpackung ist beschädigt, wie bau ich denn da eine weitere Tabelle (oder mehrere auf)? Wie geschrieben, es handelt sich um gleiche Artikel in unterschiedlichen Zuständen.

Eine Tabelle article_condition

id
condition

funktioniert nicht, da sie dann die article_id beinhalten würde, die sich auf alle Artikel eines Types bezieht, nicht jedoch auf einen bestimmten davon.

Obwohl mir sonst immer etwas einfällt, hab ich grad keine richtige Idee wie ich das Problem löse. Das einzige was ich momentan sehe, wäre jedem Artikel eine eigene id zu geben und die Artikel in Gruppen zu ordnen oder mit mehreren id zu arbeiten.

Dieser Beitrag wurde von Gispelmob bearbeitet: 30. November 2016 - 05:18

[RalphS]

Eine Datenbank reflektiert niemals den IST-Zustand.

Daher brauchst Du immer eine Tabelle, die Artikel nach dem referenziert, was sie auch wirklich SIND. Also sprich, Du hast eine Wurst in der linken Hand und Du hast eine Wurst in der rechten Hand und das eine ist Artikel(nr) 1 und das andere eben Artikel 2.

Heißt, Du brauchst Tabellen in etwa in der Form:

> Artikel (ID=PK; Product_ID=FK(Product); Zustand_ID=FK(Zustand); Description; <weitere Eigenschaften>)
> Product (ID=PK; <Produktspezifika> )
> Zustand (ID=PK; Zustand_Name; <weitere Zustandseigenschaften, soweit erforderlich>)

Description ist immer so ein bissel ein Joker im Design. Was willst Du beschreiben? Wenn die Beschreibung spezifisch zum Produkt ist, kommt sie da mit rein. Wenn die Beschreibung aber spezifisch auf den konkreten ARTIKEL ist, also zB bezug nimmt auf den Zustand oder dergleichen, dann kommt die Beschreibung in diejenige Tabelle, wo die bewußte Eigenschaft referenziert wird. In diesem Fall also die Artikeltabelle, weil da der Zustand mit referenziert wird.

Je nachdem, was halt zusammengehört.

[Ludacris]

ich würde das ganze etwas anders aufbauen, braucht dann zwar mehr datenbankabfragen ist aber mmn. übersichtlicher: (nicht wundern: updated und created at hab ich bei laravel kennengelernt, ist aber sehr praktisch.

Artikel
id	int 11
artikelnr	varchar|int
produktbezeichnung	varchar 510
updated_at	datetime
created_at	datetime

Artikel has Zustand
id	int 11
artikel_id	int 11
zustand_id	int 11

Zustand
id	int 11
Zustand	varchar 255
Beschreibung	varchar 1020
updated_at	datetime
created_at	datetime

In diesem Beispiel hast du eine Zustandstabelle, eine Artikeltabelle und eine referenztabelle. Wenn sich jetzt am Zustand was ändert musst du nur die referenz ändern und nicht das Produkt selbst.

[Gispelmob]

 Zitat (Ludacris: 30. November 2016 - 09:49)

ich würde das ganze etwas anders aufbauen, braucht dann zwar mehr datenbankabfragen ist aber mmn.
übersichtlicher:

ein oder mehrere (INNER) JOIN tun es auch^^

 Zitat (Ludacris: 30. November 2016 - 09:49)

In diesem Beispiel hast du eine Zustandstabelle, eine Artikeltabelle und eine referenztabelle. Wenn sich jetzt am Zustand was ändert musst du nur die referenz ändern und nicht das Produkt selbst.

Ja, das ist eine Möglichkeit

[Ludacris]

 Zitat (Gispelmob: 30. November 2016 - 12:02)

ein oder mehrere (INNER) JOIN tun es auch^^

Klar, nur willst du einem DB Anfänger wirklich JOINS antun?

[RalphS]

JOINs muß ein Anfänger begreifen unmittelbar nachdem er Tabellen begriffen hat. Ohne JOINs kannst das gleich wieder vergessen, sonst funktioniert das nicht.

Und für den simplen Abfrager, der keine Ahnung hat und auch keine wirkliche Ahnung haben muß, für den definiert man VIEWs.

[Gispelmob]

 Zitat (Ludacris: 30. November 2016 - 14:56)

Klar, nur willst du einem DB Anfänger wirklich JOINS antun?

JOINS sind ein wunderbares Mittel viele Abfragen die man sonst einzeln machen müsste in einem Query zu bündeln und daraus auch gleiche die richtige Struktur zu erzeugen. Die Arbeit wird also von der Datenbank erledigt und man muss das nicht im Script/Code programmieren.

"kleines" Beispiel:

SELECT
manufacturer.name AS manufacturer,
articles.name AS article,
colors.name AS color,
article_stock.stock AS stock,
article_prices.sell_price AS price,
article_prices.sell_shipping AS shipping,
currencies.short AS currency,
article_measurements.length AS length,
article_measurements.width AS width,
article_measurements.height AS height,
article_measurements.weight_unpacked AS weight_unpacked,
article_measurements.weight_packed AS weight_packed
FROM articles
INNER JOIN manufacturer ON articles.manufacturer_id = manufacturer.id
INNER JOIN colors ON articles.color = colors.id
INNER JOIN article_stock ON articles.id = article_stock.id
INNER JOIN article_prices ON articles.id = article_prices.id
INNER JOIN currencies ON article_prices.sell_currency = currencies.id
INNER JOIN article_measurements ON articles.id = article_measurements.id
ORDER BY manufacturer.name, articles.name ASC

Erzeugt wird aus ingesamt 7 Tabellen eine Struktur mit 12 verschiedenen Feldern. Man muss nur aufpassen das alle Tabellen auch Einträge zu jedem Artikel haben, den Datensätze zu denen keine Einträge in den anderen Tabellen stehen werden einfach nicht mit angezeigt. Normalerweise sollten aber beim anlegen eines Artikel auch die Einträge in den Tabellen gemacht werden.

Allerdings ist dieser Query veraltet. Denn mir fehlt hier nur noch der Eintrag für den Artikelzustand aus der Tabelle article.conditions den ich noch einbauen müsste.

Ich hab heute die DB etwas geändert damit die Verwendung vom Artikelzustand besser klappt. Ich werde alle Artikel quasi als Vorlage in einer Tabelle article_list fest definieren (eventuell tausch ich den Namen auch mit articles) und dann in der Tabelle articles jeweils den Lagerbestand und den Zustand der vorhandenen Artikel eintragen. Dann kann es vorkommen dass ein Artikel mehrfach in dieser Tabelle steht, allerdings mit verschiedenen Artikelzuständen und Anzahl. Die ursprüngliche Artikelliste in Tabelle article_list bleibt somit unberührt.

Genau das was ich wollte. Ich hatte nur heut morgen keine richtige Idee wie ich es genau mache.^^

Dieser Beitrag wurde von Gispelmob bearbeitet: 30. November 2016 - 21:38

[Holger_N]

 Zitat (Ludacris: 30. November 2016 - 14:56)

Klar, nur willst du einem DB Anfänger wirklich JOINS antun?

Er ist doch selber der Frager.

[RalphS]

Und noch mal, in einer Datenbank haben Redundanzen nix verloren.

Wenn ich mir die DB so anschau... eh. Hast Du schon mal einen Blick in den Entwurf der Northwind geworfen? Das scheint mir in etwa das abzubilden, was Du brauchst, verfolgt aber einen gänzlich anderen Ansatz.

In jedem Fall wirst Du - mE -- um eine Tabelle "Produkte" nicht rumkommen, wo die ganzen Produktarten aufgelistet sind, und dann noch eine "Instanz"tabelle, wo jeder real vorhandene Gegenstand aufgelistet ist, mit jeweils einer Referenz zur Produkttabelle ("X ist ein Y"). Notfalls mit weiteren Fremdschlüsseln (X ist ein Y und zwar mit Farbe C und Größe G oä.)

Solche Abfragen wie die oben kommen auch nicht ins PHP-Script. Sie kommen in die View-Definition, wo sie jeder-der-können-soll sehen kann und darauf auch zugreifen kann. Und wenn Du ein ordentliches DBMS hast, dann kannst Du dem View sogar eigene Rechte verpassen, sodaß User U den View anschauen kann, aber NICHT die darunterliegenden Tabellen.

[Gispelmob]

 Zitat (RalphS: 30. November 2016 - 22:09)

Und noch mal, in einer Datenbank haben Redundanzen nix verloren.

Niemand hat was von Redundanzen erzählt.

 Zitat (RalphS: 30. November 2016 - 22:09)

In jedem Fall wirst Du - mE -- um eine Tabelle "Produkte" nicht rumkommen, wo die ganzen Produktarten aufgelistet sind,

das ist die Tabelle article_list

 Zitat (RalphS: 30. November 2016 - 22:09)

und dann noch eine "Instanz"tabelle, wo jeder real vorhandene Gegenstand aufgelistet ist, mit jeweils einer Referenz zur Produkttabelle ("X ist ein Y"). Notfalls mit weiteren Fremdschlüsseln (X ist ein Y und zwar mit Farbe C und Größe G oä.)

das ist die Tabelle articles

 Zitat (RalphS: 30. November 2016 - 22:09)

Solche Abfragen wie die oben kommen auch nicht ins PHP-Script. Sie kommen in die View-Definition, wo sie jeder-der-können-soll sehen kann und darauf auch zugreifen kann.

Das mach ich ab dem Zeitpunkt ab dem VIEWS in mysql persistent/materialized sind.^^ Ja ich weiß, sie stehen in der INFORMATION_SCHEMATA, aber es ist nicht zielführend da jedem Nutzer/Script Rechte drauf zu geben.

 Zitat (RalphS: 30. November 2016 - 22:09)

Und wenn Du ein ordentliches DBMS hast, dann kannst Du dem View sogar eigene Rechte verpassen, sodaß User U den View anschauen kann, aber NICHT die darunterliegenden Tabellen.

Man kann vieles, hat aber wenig Sinn wenn man alleiniger Benutzer ist.

Dieser Beitrag wurde von Gispelmob bearbeitet: 01. Dezember 2016 - 08:11

[Holger_N]

 Zitat (Gispelmob: 01. Dezember 2016 - 07:53)

…
Man kann vieles, hat aber wenig Sinn wenn man alleiniger Benutzer ist.

Richtig, wenn man alleine auf einem Privatgrundstück Auto fährt, muß man sich nicht anschnallen. Weil die Polizei einen dort nicht kontrollieren kann, macht das ja schließlich keinen Sinn und wenn man dort dann gegen einen Baum fährt, passiert einem deswegen auch nichts.

[Ludacris]

 Zitat (Holger_N: 30. November 2016 - 21:40)

Er ist doch selber der Frager.

Hopla

[RalphS]

Dann hab ich Dich wohl hier

 Zitat (Gispelmob: 30. November 2016 - 21:29)

Dann kann es vorkommen dass ein Artikel mehrfach in dieser Tabelle steht, allerdings mit verschiedenen Artikelzuständen und Anzahl.

falsch verstanden, weil das ist in meinen Augen eben Redundanz.

Nicht daß das weiter wichtig wär. Du kannst mit Deinem DBMS schließlich machen, was Du willst.

[Gispelmob]

 Zitat (Holger_N: 01. Dezember 2016 - 09:27)

macht das ja schließlich keinen Sinn und wenn man dort dann gegen einen Baum fährt, passiert einem deswegen auch nichts.

Leider falsche Schlussfolgerung. Man wird nur nicht bestraft. Den Schaden hat man in jedem Fall. 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.^^

 Zitat (RalphS: 01. Dezember 2016 - 18:02)

falsch verstanden, weil das ist in meinen Augen eben Redundanz.

Für jeden vorhanden Artikel mit einem bestimmten Artikelzustand ist ein Eintrag. Damit verkörpert jeder Eintrag einen eigenen Datensatz und es liegt keine Redundanz vor.

Name; Zustand; Anzahl

Artikel1; Neu; 3
Artikel1; Gebraucht; 1
Artikel2; Kaputt; 2
Artikel3; Neu; 1

Wenn Anzahl 0 dann gibts auch keinen Eintrag. Wenn du einen besseren Weg kennst, dann ist es dir nicht verboten dein Wissen zu teilen^^.

Dieser Beitrag wurde von Gispelmob bearbeitet: 01. Dezember 2016 - 22:13

[RalphS]

Mh... ich dachte erst, ich folge Dir, aber dann ergänzt Du das und ich bin mir nicht mehr so sicher.

- Nicht "Name" und dann "Artikel 1", "Artikel 2" und "Artikel 3"; sondern "ArtikelID" und dann A1, A2 und A3 (zum Beispiel). Dies nicht als Primär-, sondern als Fremdschlüssel für diejenige Tabelle, wo Artikel 1, Artikel 2 und Artikel 3 mit ihrer ArtikelID eineindeutig zugeordnet sind.

- Aber vielleicht meintest Du das so. Mit gutem Willen ist schließlich "Artikel1" & Co auch als Schlüssel tauglich, nur zu lang, weil ja dann jedes Mal die Zeichenfolge "Artikel" mit drin steht.