Teileversorgung

Ein Baukasten-System mit genormten (Metall-)Bauteilen für Entwicklung und Prototyping von kleineren Maschinen. / A Metal Construction Set for prototyping and fast devolpment of small devices.
Benutzeravatar
case
Beiträge: 733
Registriert: Mi 13. Jun 2012, 01:12

Re: Teileversorgung

Beitrag von case » Do 31. Jul 2014, 23:54

Hi Sebastian,
Tony Ford hat geschrieben:hast du eine eMail bekommen?
Nee, bislang noch nix angekommen.

Hab nun eine Plattform eingerichtet bzw. von meinem gezeigten Projekt kopiert.
Auf der Seite "Documentation" habe ich schon mal angefangen und würde morgen und übermorgen fortfahren.

http://catdev.btclink.org
Ja, sehr schön, da werden ja die DB-Strukturen beschrieben. Ich werd mir auch schon mal ein paar Gedanken dazu machen, aber ansonsten warte ich erstmal ab, was Du dort einträgst.

Das wird auf jedenfall eine gute Sache.

Gruss, Oliver
--- Man wächst nur, indem man etwas zuende bringt und etwas anderes beginnt ---

Mein Blog: http://makeable.de
OpenEcoLab-Charta: http://openecolab.de

Tony Ford
Beiträge: 455
Registriert: Di 5. Feb 2013, 21:20
Wohnort: bei Dresden
Kontaktdaten:

Re: Teileversorgung

Beitrag von Tony Ford » Sa 2. Aug 2014, 18:09

Montag melde ich mich nochmal, bis dahin hab ich dann alles fertig und sende dir dann das Passwort nochmal zu.
Hab u.a. nächste Woche auch etwas freie Zeit, d.h. ich kann dann auch fix versuchen was in die Realität umzusetzen.

TF

Tony Ford
Beiträge: 455
Registriert: Di 5. Feb 2013, 21:20
Wohnort: bei Dresden
Kontaktdaten:

Re: Teileversorgung

Beitrag von Tony Ford » So 3. Aug 2014, 21:02

so nun hab ich die Datenbank fürs Erste modelliert.

http://catdev.btclink.org/wiki/index.ph ... umentation

TF

Benutzeravatar
case
Beiträge: 733
Registriert: Mi 13. Jun 2012, 01:12

Re: Teileversorgung

Beitrag von case » Di 5. Aug 2014, 01:00

Hi,

also, demnach sähe eine vollständig qualifizierte Bauteil-Nr. für eine M5er Gewindestange aus Stahl mit 10cm Länge aus wie folgt:

"EB0012-SSM501"

wobei

E - Kategoriengruppe [G]
B - Kategorie [K]
0012 - Bauteil
SS - Material [M]
M5 - Besondere Eigenschaft [F]
01 - variabler Längenparameter [V]

und hätte also das 12-stellige Format [GKBBBB-MMFFVV],

richtig ?



Soweit ok, aber aus meiner Sicht sollte das Material am Schluss stehen. In jeder realen Suche wird man immer zuerst nach den qualifizierenden Parametern wie der passenden Länge schauen und nur wenn da überhaupt was passendes vorhanden ist entscheiden, welches Material man nimmt. Umgekehrt wird aber nie oder zumindest höchst selten eine Suche nach "zeige mir alles was aus Stahl ist" stattfinden.

Noch ein Tip:

Kategoriengruppe und Kategorie müssen auf jedenfall ein fester Bestandteil der Bauteil-Nr. sein also von PART.Id .

Daher würde ich die aus dem Tag-System komplett rauslassen und selbiges auch tatsächlich nur für normale bzw. beliebige Tags aller Art verwenden. Du baust da mit den Parent-IDs zwar eine sehr flexible Baumstruktur auf, aber für die BauteilNr. brauchen wir eher was möglichst einfaches/Eindeutiges und bei dem Tags-System hast Du noch obendrein zusätzlichen Parser-Aufwand und ev. weitere Tabellenzugriffe um das Tag zu identifizieren

Daher würde ich sogar soweit gehen und für G,K,B,M,F und V jeweils ein eigenes Feld in der PART-Tabelle definieren und jedes einzelne davon indizieren. Und sei es allein aus Performancegründen, denn dann kannst Du mit einem einfachen Select beliebige Suchanfragen in einem Rutsch durchführen, also etwa
SELECT * from PART where (G="E" AND K="B" AND M="SS"); um alle Wellen, Gewinde und sonstige Stangen aus Stahl anzuzeigen. Wenn Du vorher jedes einzelne dieser Felder mit einem Index belegt hast geht das rasend schnell.

Naja, und zusätzlich würde ich die voll qualifizierte Bauteile-Nr. der Bequemlichkeit halber und für Suchen die direkt auf die komplette BauteileNummer abzielen, nochmal als ganzer String zusammengefasst vorrätig halten. Und zwar in der Feldvariablen "Id" der Tabelle PART. Darüberhinaus gäbe es natürlich noch eine fortlaufende Index-Nr. für jeden einzelnen Datensatz der PART-Tabelle die unique wäre, wie übrigens die Feldvariable Id ebenfalls uniqe sein muss (es darf keine zwei Bauteile mit identischer Teile-Nr. geben). Jedenfalls wäre diese fortlaufende Indexnummer, nennen wir sie mal "pidx", fortan eine zentrale Zugriffsmöglichkeit auf die einzelnen Datensätze, besonders, falls irgendwann mal die PART-Tabelle zuviele Felder hat oder man aus organisatorischen Gründen ein paar Felder in separate Tabellen auslagern und diese relational mit der Haupttabelle verknüpfen möchte, ein gutes Beispiel wären da die Tabellen in denen Du die Tags verwaltest. Wobei ich "Tags" hier im herkömmlichen Sinne meine, also weitere beschreibende Eingenschaften des Bauteil-Datensatzes, die auch für eine Suche oder Navigation hilfreich sind, aber nicht ein Bestandteil der Bauteil-Nr. sind.


Ja, soweit erstmal was mir spontan dazu einfiel.

Gruss, Oliver
--- Man wächst nur, indem man etwas zuende bringt und etwas anderes beginnt ---

Mein Blog: http://makeable.de
OpenEcoLab-Charta: http://openecolab.de

Tony Ford
Beiträge: 455
Registriert: Di 5. Feb 2013, 21:20
Wohnort: bei Dresden
Kontaktdaten:

Re: Teileversorgung

Beitrag von Tony Ford » Di 5. Aug 2014, 14:18

Ja hast recht...

1. Material ans Ende macht auf jeden Fall Sinn.

2. Mit der Kategorie und Kategoriegruppe machten wir es wie du geschrieben hast, denn deine Argumente sind mir einleuchtend.

Ich würde bis morgen Abend meinen bisherigen Entwurf entsprechend anpassen und dir dann wieder bescheid geben. Brauchst dich also nicht dort ran setzen und deine eh schon knappen Ressourcen opfern. Lass mich da lieber den Entwurf nochmals überarbeiten.

TF

Tony Ford
Beiträge: 455
Registriert: Di 5. Feb 2013, 21:20
Wohnort: bei Dresden
Kontaktdaten:

Re: Teileversorgung

Beitrag von Tony Ford » Mi 6. Aug 2014, 13:38

ok, hab es überarbeitet. Kannst jetzt nochmal vorbeischauen.

Benutzeravatar
case
Beiträge: 733
Registriert: Mi 13. Jun 2012, 01:12

Re: Teileversorgung

Beitrag von case » Do 7. Aug 2014, 21:18

Hi.

Ja, sieht supi aus.

Wobei ich das so verstehe, dass "id" der PrimaryKey, also der Hauptindex, ist und "PartId" die vollqualifizierte, komplette Bauteilnummer als String enthält. Dieses Feld wird dann auch indiziert, damit schnelle Suchen nach der gesamten BauteilNr. möglich sind.

Was wir auch noch bräuchten, das wäre eine Stringvariable bzw. ein Feld "PartName" und "PartDescription", wobei letzteres nicht zwingend ist, aber vielleicht ganz komfortabel, wenn man ausser dem Bauteilnamen noch eine kurze Beschreibung hat, um was es sich dabei eigentlich handelt.

Die Feldvariable Numbering sollte (in der technischen Umsetzung) mit einem Autoincrement belegt sein, damit erhält man beim einfügen eines neuen Bauteildatensatzes automatisch die nächste freie Nummer.

Für die Navigation brauchen wir noch ein paar Tabellen, man könnte da vielleicht auch was zusammenfassen, aber ich rate davon ab, weil mit separaten Tabellen das Handling einfacher im Sinne von klarer überschaubar bleibt - und auf der anderen Seite auch nix in punkto Performance oder Ressourcenschonung gewonnen würde.

Wir brauchen also m.E. schonmal mindestens folgende Tabellen:

KGRUPPE // für die Auflistung der Kategoriegruppen
gid // Index, PrimaryKey
categorygroup // vom Typ Char[1], enthält das Kürzel, identisch mit dem gleichnamigen Feld in der PART-Tabelle
gname // Bezeichnung der Kategoriegruppe
gdesc // Kurze Beschreibung, was in dieser Kategoriegruppe eigentlich enthalten ist (s.o., ist komfortabel)

KATEGORIE // für die Auflistung der Kategorien
cid // Index, PrimaryKey
category // vom Typ Char[1], enthält das Kürzel, identisch mit dem gleichnamigen Feld in der PART-Tabelle
cname // Bezeichnung der Kategorie
cdesc // Kurze Beschreibung, was in dieser Kategorie eigentlich enthalten ist (s.o., ist komfortabel)
gid // Zeiger auf die Kategoriengruppe (die ParentID)

MATERIAL // Auflistung der Materialien
mid // Index, PrimaryKey
material // vom Typ Char[2], enthält das Kürzel, identisch mit dem gleichnamigen Feld in der PART-Tabelle
mname // Bezeichnung des Materials
mdesc // Kurze Beschreibung, was dieses Material eigentlich ist (z.B. Zusammensetzung bei Metall-Legierung od. besondere Herstellungswesie)


Diese Tabellen sind wichtig für die systematische Navigation innerhalb des Katalogs und natürlich bei Neueingabe eines Bauteils. Dabei würden die Tabellen, die ja nicht groß sind und (nach Ausschöpfung des Namespaces) auch nicht mehr weiter wachsen in einer Query komplett ausgelesen, genauer gesagt das Bezeichnungs-Feld von denen (gname, cname), und die Namen in einem Selektor dem Anwender zur Auswahl bereitgestellt.

Oder besser gesagt, trifft das so auf die Kategoriengruppe zu. Hat der User nun eine Gruppe ausgewählt kann man nun anhand der Gruppen-Id (gid) in der KATEGORIE-Tabelle alle Kategorien abholen, dh., auch hier wieder nur die Namen (cname) plus deren Id (cid) und die Namen werden in einem weiteren Selektor bereitgestellt.

Gleiches Spiel mit den eigentlichen Bauteilen bzw. deren Numberings. Hier kann der User nun entscheiden ob für ein bereits bestehendes Bauteil eine Variante anlegen möchte (andere F, V, M) wobei dann nach dem gleichen Schema weiter abwärts navigiert wird, oder ob er ein komplett neues Bauteil anlegen möchte und in eine entsprechende Eingabemaske geleitet wird.

Wir haben aber jetzt folgendes Problem: F und V sind qualitativ insofern etwas anders als die übrigen Navigationstabellen, weil hier der Inhalt nicht von uns vorgegeben bzw. fest vordefiniert werden kann. Sondern sie stehen immer in Abhängigkeit zu einem individuellen Bauteil.

Anders gesagt, zu jedem Bauteil gibts ein oder mehrere F's und V's, die wir irgendwie noch in der PART-Tabelle verankern müssen und die erstmalig erst beim Neuanlegen eines bestimmten Bauteils mitangelegt werden.

Eine weitere Eigenschaft ist, das sie (bzw deren Anzahl) im Prinzip unendlich (oder sagen wir mal "beliebig") wachsen können, d.h., ich kann immer wieder neue, weitere Bauteilvarianten mit anderer Länge hinzufügen.

Ich weiss noch nicht genau, wie man dies am besten technisch handlen sollte, weil ich noch nie eine größere DB-Anwendung in MySQL programmiert habe, sondern immer nur in PostgreSQL. Dort gibt es einen Datentyp - ich hab den genauen Namen vergessen, aber sinngemäss etwa "Array mit variabler Größe", d.h., ich muss zum Deklarationszeitpunkt noch nicht wissen, wie groß das Array werden wird und kann auch später noch beliebig viele Einträge ergänzen.

Ich weiss nicht genau ob es in MySQL eine Entsprechung dazu gibt, falls ja, dann wäre die Sache einfach: Man würde dort immer nur die Indizees auf die jeweilige V- oder F-Tabelle ergänzen, wenn ein Bauteil um neue Varianten ergänzt wird.

Falls nicht muss man irgendwie einen Workaround mit ähnlichem Effekt stricken. Das betrifft aber m.E. nur die PART-Tabelle. Die jeweiligen V- und F-Tabellen selbst würden wieder nach dem gleichen oder zumindest einem ähnlichen Prinzip wie KGRUPPE und KATEGORIE aufgebaut sein, d.h., aus ihrer Sicht ist es egal, auf welche Weise ein Bauteil "weiss", welche F's und V's zu ihm gehören.

Achja, und bei den V's muss auch noch irgendwie mit einem Autoincrement dafür gesorgt werden, das das Zwei-Ziffern-Kürzel irgendwie hochgezählt wird, wobei es sich hierbei innerhalb der Tabelle lediglich um einen Bezeichner handelt (der genausogut auch nicht-numerisch sein könnte), der darf also nicht gleichgesetzt werden, mit dem PrimaryKey/Index dieser Tabelle.

Glaub ich zumindest, bei grobem überfliegen der Sache ;) Über die Details muss man nochmal nachdenken, aber so oder so ähnlich sollte es m.E. grob aussehen.

Gruss, Oliver
--- Man wächst nur, indem man etwas zuende bringt und etwas anderes beginnt ---

Mein Blog: http://makeable.de
OpenEcoLab-Charta: http://openecolab.de

Tony Ford
Beiträge: 455
Registriert: Di 5. Feb 2013, 21:20
Wohnort: bei Dresden
Kontaktdaten:

Re: Teileversorgung

Beitrag von Tony Ford » Fr 8. Aug 2014, 10:30

Die Kategorien, Materialien hab ich erstmal noch außen vor gelassen, die füge ich natürlich noch hinzu.

Bezüglich der F's und V's hab ich eine Idee.


Und zwar die Tabelle PART enthält lediglich die Felder

E - Kategoriengruppe [G]
B - Kategorie [K]
0012 - Bauteil

sowie die id (primary key) eine fortlaufende Nummer.

Dabei entspricht mit Erstellen der id die Bauteilnummer B = der id mit vorangestellten Nullen.


in weiteren Tabellen PROPERTY, SIZE, MATERIAL werden dann über die id von Part eine entsprechende Versionierung vorgenommen.

PROPERTY:

PART_id
Label
Description

SIZE:

PART_id
Label
Description


MATERIAL:

PART_id
Label
Description

Angenommen du hast du M4 und M5 bei PROPERTY eingetragen und dem Teil x zugeordnet, zudem noch die Längen 01,02,03 und bei MATERIAL das Material SS und ST, so erhältst du über eine JOIN - Selektion eine folgende Ausgabe:

EB0012-M401SS
EB0012-M401ST
EB0012-M402SS
EB0012-M402ST
EB0012-M403SS
EB0012-M403ST
EB0012-M501SS
EB0012-M501ST
EB0012-M502SS
EB0012-M502ST
EB0012-M503SS
EB0012-M503ST

Die Beschreibung wird natürlich ebenfalls mitgeliefert.

D.h. du hast für die gezeigte Ausgabe lediglich einen Eintrag in PART, zwei Einträge in PROPERTY, drei Einträge in SIZE und zwei Einträge in MATERIAL und erhältst somit 1 * 2 * 3 * 2 = 12 Ausgaben.

Würdest du nun noch eine Länge verändern oder hinzufügen wollen, so würde sich dies auf alle Konstellationen auswirken.

Einzig was man noch lösen müsste, wäre der Fall, wenn bestimmte Konstellationen ausgeschlossen werden sollen, z.B. wenn es für sehr große oder kleine M-Größen einige Längen nicht gibt oder keinen Sinn macht.
Wobei man an dieser Stellene solche Sonderfälle durch eine neue Teilenummer heraushalten und seperat konfigurieren könnte.
Eine weitere Möglichkeit wäre eine weitere Tabelle, in denen man jene Konstellationen auflistet und dann in die Abfrage wie eine "Maskierung" wirken lässt.

TF

Benutzeravatar
case
Beiträge: 733
Registriert: Mi 13. Jun 2012, 01:12

Re: Teileversorgung

Beitrag von case » Fr 8. Aug 2014, 15:38

Tony Ford hat geschrieben:Dabei entspricht mit Erstellen der id die Bauteilnummer B = der id mit vorangestellten Nullen.
Ich seh grad dass ich da einen Denkfehler gemacht habe.

Um den Namespace optimal auszunutzen sollte es möglich sein, das zwei Nummern wie AB0012- und EB0012 nebeneinander koexistieren können, was bislang nicht möglich war, da numbering auch hochgezählt wird, wenn es sich um zwei verschiedene Kategorien handelt.

Womit man lediglich 9999 verschiedene Bauteile (eines Typs) kodieren kann. Bei voller Ausnutzung sollten aber 26 x 26 x 9999 verschiedene Bauteile möglich sein.

Demzufolge darf an dieser Stelle kein Autoincrement auf numbering erfolgen. Stattdessen muss man noch in KATEGORIE ein Feld "lastnumber" ergänzen, welches per Update-Befehl hochgezählt wird. Und PART muss weiterhin einen separaten id-Index behalten.


in weiteren Tabellen PROPERTY, SIZE, MATERIAL werden dann über die id von Part eine entsprechende Versionierung vorgenommen.
Ja, ich glaub das ist der richtige Ansatz. Entgegen meiner früheren Annahme braucht ein ganz bestimmter Bauteil-Datensatz gar nicht zu wissen, welche Versionen es sonst noch so gibt, solange die Versionen wissen, zu welchem Bauteil sie gehören.

Die Versionierungsfelder in PART sollten aber m.E. dennoch für schnelle Suchabfragen erhalten bleiben. Beim JOIN kannst Du zwar den Zugriff auf zwei Tabellen von der Schreibweise her in einem Select zusammenfassen, aber intern werden da trotzdem noch zwei Tabellenabfragen draus generiert.
Würdest du nun noch eine Länge verändern oder hinzufügen wollen, so würde sich dies auf alle Konstellationen auswirken.
Bin mir nicht sicher ob man solche Änderungen überhaupt haben will und zulassen sollte, wegen erhöhtem Überprüfungsaufwand und Fehleranfälligkeit.
Hinzufügen einer neuen Länge ist natürlich ok.
Einzig was man noch lösen müsste, wäre der Fall, wenn bestimmte Konstellationen ausgeschlossen werden sollen, z.B. wenn es für sehr große oder kleine M-Größen einige Längen nicht gibt oder keinen Sinn macht.
Ist m.E. nicht unsere Aufgabe, für solche inhaltlichen Dinge sollte der jeweils Eintragende zuständig sein. Wir als Programmierer können auch nicht wissen oder vorwegantizipieren, ob irgendein Ingenieur nicht doch irgendwann mal ne große M-Schraube benötigt, selbst wenn es die heutzutage noch gar nicht gäbe.


Gruss, Oliver
--- Man wächst nur, indem man etwas zuende bringt und etwas anderes beginnt ---

Mein Blog: http://makeable.de
OpenEcoLab-Charta: http://openecolab.de

Tony Ford
Beiträge: 455
Registriert: Di 5. Feb 2013, 21:20
Wohnort: bei Dresden
Kontaktdaten:

Re: Teileversorgung

Beitrag von Tony Ford » Fr 8. Aug 2014, 17:39

Bezüglich der Inkrementierung wie ich sie gezeigt habe, hätte wiederum den Vorteil, dass du über die Eingabe der vierstelligen Zahl zum passenden Teil gelangst, ohne hierfür die Kategorien angeben zu müssen.

D.h. theoretisch liese sich das EB auch weglassen. So könnten Teilelisten theoretisch auch ohne EB geführt werden und wäre eine eindeutige Identifikation möglich.
Ich stelle mir hierzu ein Konstrukt wie Regal, 3D-Drucker, usw. vor, welches eine Bauanleitung sowie Auflistung aller Materialien bereit hält.

Wenn ich nun 30 verschiedene Teile aufliste, so könnte ich statt der langen Nummern auch kurze Nummern wie

2x 12-M401
4x 12-M501

angeben und würde dennoch eine passende Ausgabe erhalten. Für jede Abfrage würde ich jeweils zwei Ausgaben erhalten

EB0012-M0401SS
EB0012-M0401ST

Wenn ich jedoch ein Konstukt wie ein Regal habe, so interessiert die Verwendung des Materials eher wenig, es sei denn ich verwende es in feuchten Räumen. Hierzu könnte man dann noch ein Sternchen anhängen und in einer Legende unten den Hinweis anhängengeben, dass SS im Falle von Nässe zu verwenden wäre.

Bezüglich der Sache mit dem schneller finden, hierzu dürfte doch eine MySQL-DB schnell genug sein oder nicht?
Theoretisch könnte man auch aus den Daten eine extra Tabelle automatisch generieren und in dieser dann suchen.

TF

Antworten