Tabellen für Werkstoffe

[jojo6]

Hallo,

ich bin gerade dabei die bestehende Datenbank zu erweitern und Werkstoffe einzupflegen.
Könnt ihr mir da vielleicht helfen, was für Tabellen ich benötige bzw. welche Daten in eine Tabelle sollen und welche besser in eine weitere Tabelle.

Hier mal wie ich es gedacht habe:

tblartikel (gibt es bereits)
*zeichnungsnummer
(-werkstoffdetails_id)

tblwerkstoff (neu)
*id
-werkstoff

tblwerkstoffdetail (neu)
*id
-herstellungsart
-oberflaeche
-dicke
-farbe
-werkstoff_id

Hier geht es (momentan) vor allem um Kunststoffe und Silikone.

Würde mich über eure Tipps freuen! DANKE!

 

[ukulele]

In deinem jetzigen Beispiel gibt es keinen Grund werkstoff und werkstoffdetails zu trennen, es läßt sich genauso in einer Tabelle zusammen fassen. Bei Werkstoffen mit stark unterschiedlichen Eigenschaften bietet sich auch hier das EAV Prinzip an welches auch grade in einem anderen Thread wieder kurz thematisiert wurde. Hier erklärt anhand von Autos: https://www.datenbankforum.com/thre...abhaengigkeiten-untereinander.1606/#post-8222

Wenn du den Fremdschlüssel werkstoffdetails in die artikel Tabelle mit aufnimmst kann ein Artikel / Zeichnung immer maximal einem Werkstoff zugeordnet werden. Ich glaube nicht das das Sinn macht. Bei Mehrfachzuordnungen müsstest du eine n:m Beziehung über eine Zwischentabelle abbilden.
http://de.wikipedia.org/wiki/Relationale_Datenbank#Beziehungen_zwischen_Tabellen

 

[jojo6]

Ok, ich hoffe, ich habe es verstanden?!?! Wäre somit folgender Ansatz richtig:

tblartikel (ArtikelId, Name)
1234, PMMA XT Platte 5mm

tblartikelwerkstoff (Id, ArtikelId, Eigenschaft, Wert)
1, 1234, Material, PMMA
2, 1234, Herstellungsverfahren, XT
3, 1234, Zustand, Platte
4, 1234, Dicke, 5mm

tblwerkstoffdetails (Id, Eigenschaft, Wert)
1, Material, PMMA
2, Material, POM-C
3, Material, PTFE
4, Herstellungsverfahren, XT
5, Herstellungsverfahren, GS
6, Zustand, Platte
7, Zustand, Rohr
8, Zustand, Stab
9, Dicke, 2mm
10, Dicke, 3mm

 

[ukulele]

Alles was in tblwerkstoffdetails steht könnte aber auch in tblartikelwerkstoff stehen. Die Differenzierung macht so noch keinen Sinn bzw. so ist es redundant.

 

[jojo6]

Nochmal eine Verständnisfrage:
Wenn später weitere Werkstoffe bzw. Eigenschaften angelegt werden sollen, dann kann ja quasi jeder Werte rein schreiben wie er gerade Lust hat, da es in dem Sinn ja keine konkreten Vorgaben gibt?!

Und falls es doch über einzelne Tabellen umgesetzt werden würde, dann müsste ich für jede Eigenschaft eine separate Tabelle anlegen?!

Irgendwie sehe ich grad den Wald vor lauter Bäumen nicht mehr ... :-(

 

[ukulele]

Theoretisch können nach EAV beliebige Eigenschaften in beliebiger Menge abgebildet werden. Ein Objekt kann 10 Werkstoffe haben und ein anderes 1000, der Datenbank ist das egal. Die Nachteile sind hier aber auch nicht klein:
1) Du musst sehr viel Aufwand betreiben um deine Eigenschaften in der Anwendung vernünftig darzustellen. Du kannst nicht mal eben alle Eigenschaften in einer Tabelle ausgeben, das ist sehr sehr aufwendig.
2) Du kannst nur schwer mit Datentypen arbeiten, deine Wert-Spalte hat ja immer das selbe Format. Natürlich kann man hier für Zahlen- Datums- und Textformate unterschiedliche Tabellen oder Spalten anlegen, das wird dadurch aber nicht einfacher und für jeden Datentyp will man das sicher auch nicht haben.

Ich kann nicht abschätzen wie groß dein Projekt wird und wie unterscheidlich die Werkstoffe sind. Die einfachere und leichetere Variante ist vermutlich eine Tabelle pro Werkstoff oder für eine Werkstoffgruppe (mit möglichst identischen Eigenschaften).

Das hängt auch von deinen Fähigkeiten und vor allem vom Front-End für die Daten ab. Irgendwer muss das ja auch benutzbar machen.

 

[akretschmer]

In deinem jetzigen Beispiel gibt es keinen Grund werkstoff und werkstoffdetails zu trennen, es läßt sich genauso in einer Tabelle zusammen fassen. Bei Werkstoffen mit stark unterschiedlichen Eigenschaften bietet sich auch hier das EAV Prinzip an welches auch grade in einem anderen Thread wieder kurz thematisiert wurde.

Andere Lösung: Dokumentenbasierte Systeme wie MongoDB, die das als JSON speichern. Wenn Du die Vorteile einer relationalen DB, also SQL mit allem drum und dran, aber nicht völlig aufgeben willst: PostgreSQL 9.4 unterstützt JSON und ist sogar schneller als MongoDB dabei.

Fragen? Fragen!