Teileversorgung

Ja, schon klar, und ich verstehe auch den Reiz einer kurzen Teilenummer.

Das Problem ist nur, das es auf Kosten der maximalen Anzahl möglicher Bauteile geht. Ich finde 10000 mögliche Bauteiltypen einfach deutlich zu wenig für eine zukunftsgerichtete Systematik, die nach möglichst vielen Seiten hin offen und UNIversell sein will. Warum sollte man ohne große Not so ein System schon von vorn herein quasi „kastrieren“ und dafür sorgen, dass es eher früher als später an seine Grenzen kommt ?

Natürlich gehe ich nicht davon aus, dass wir selbst 10000 verschiedene Bauteiltypen definieren werden und ich vermute auch, Du wähnst Dich in Anbetracht der ganzen Versionierungs-Varianten, mit denen man natürlich netto auf eine höhere Bauteilmenge kommt, auf der sicheren Seite.

Ich gebe aber zu bedenken, das es insgesamt nur ein gewisser Prozentsatz an Bauteilen ist, die durch Versionierung noch permutiert werden können und dem ein ungleich höherer Prozentsatz an (möglichen) Bauteilen gegenübersteht, die nur als Einzel-Version daherkommen.

Betrachten wir z.B. nur mal allein die Möglichkeiten die sich durch 3D-Printer gedruckte Bauteile ergeben.

Angenommen, auf Thingiverse sind insgesamt 1 Millionen Bauteile definiert und 99% davon sind der reine Schrott, gedruckte Plastik-Totenschädel und sowas, aber 1% sind wirklich coole und nützliche Bauteile. Und jemand möchte diese alle ins System einpflegen. Dann hast Du auf einen Schlag schon die ganzen 10000 möglichen Bauteile ausgereizt. Und 3D-Drucker sind gerade erst im kommen.

Aber ausser Plastik gibts noch andere Materialbereiche, wie etwa Holz, Metall, Verbundwerkstoffe und wasweissich, von denen jeder einzelne ebenfalls ähnlich viele oder sogar noch deutlich höhere Permutationsmöglichkeiten aufweist. Oder nimm nur mal die zig Millionen von Elektronik-Bauteilen, von denen zumindest ein gewisser Prozentsatz ebenfalls in einem Baukastensystem Sinn machen könnte. Plus weitere Möglichkeiten an die Du und ich noch nicht mal im Traume denken, von denen aber jeder gestandene Ingenieur sofort ein Lied zu singen wüsste.

Vielleicht klingt das jetzt alles etwas weit hergeholt, aber ich wünsche mir halt für unsere Systematik, das sie möglichst universell ist und weit reicht. D.h., mit 26 x 26 x 9999 möglichen Bauteiltypen könnte ich diesbezüglich ruhig schlafen … bei 9999 dagegen hätte ich das Gefühl: Echt jammerschade !




Bezüglich der Sache mit dem schneller finden, hierzu dürfte doch eine MySQL-DB schnell genug sein oder nicht?

Naja, ein JOIN arbeitet m.E. so, dass er erst aus der einen Tabelle ALLE Datensätze rausholt auf welche die diesbezügliche Bedingung passt und dann das Gleiche aus der anderen Tabelle und dann aus einer dritten Bedingung die Schnittmenge bildet und diese zurückliefert. Dem gegenüber steht, das unsere Anwendung, zumindest im Vergleich mit vielen „Business“-DB-Anwendungen eher klein ist und Speicherplatz echt kein Thema ist.

Aber, im Prinzip hast Du schon recht und die Performance ist hier nicht wirklich das Problem, was ich eher im Kopf habe ist, unter „Opferung“ von ein bischen Speicherplatz (der uns quasi nix kostet), etwas simplere Strukturen zu schaffen die den Programmieraufwand verringern und nebenbei vielleicht noch die Übersichtlichkeit steigern; ein vielzitierter Kritikpunkt am JOIN ist übrigens, dass dessen Syntax und Wirkungsweise für Nicht-Englisch-Muttersprachler nicht gerade besonders intuitiv verständlich (und damit fehleranfällig) ist.

Ich versteh auch nicht, warum es ein Problem sein sollte, im PART-Datensatz die eine oder andere Feldvariable mehr mitlaufen zu lassen, selbst wenns etwas Speicherplatz kostet, aber auf der anderen Seite dem Programmierer das Leben erleichtert.

Aber, da hängt mein Herz nicht dran (zumindest nicht so sehr wie an der Sache mit der Bauteile-Typen-Anzahl), machs halt so wie Du es für richtig empfindest.



Hilfreich ist es m.E., dabei immer zwei Szenarien im Hinterkopf zu behalten:

  • den Bauteile-Creator, der ein neues Bauteil einpflegen will

  • den End-User der ein Bauteil finden will (sofern es das gibt)

Gruss, Oliver

Nach einiger Überlegung komme ich zum gleichen Ergebnis bezüglich der Durchnummerierung.
Im Grunde wird meine Art der Durchnummerierung bei größeren Nummern nicht mehr so günstig anwendbar.

D.h. 12-M401 mag da günstig sein, jedoch 123912-M0401 dann nicht mehr.
So dass die Nummerierung nach Kategorien sinnvoller erscheint, d.h.

EB0012-M0401
AB0012-…
usw.

Selbst diese könnte man zu EB12-M401 abkürzen und würde es immer noch eindeutig finden.

Für die Nummerierung, würdest du jeweils nur nach Kategoriengruppen oder nach Kategoriengruppe + Kategorie eine Inkrementation vornehmen?

D.h. im Falle 1 würde es EB0012 und EA0012 nicht geben, weil E hochgezählt wird.
Im Falle 2 würde es EB0012 und EA0012 geben können, da EB sowie EA einen eigenen Zähler bekäme.

Für das Hochzählen würde ich vor Eintragen in die DB eine sortierte Abfrage durchführen und den größten Gruppenindex inkrementieren und in den neuen Datensatz einfügen.

TF

Uuups, jau stimmt, das hab ich bislang glatt übersehen. Wenn man nur in KATEGORIE einen Zähler einbaut kommt man nur auf 26 x 9999 Möglichkeiten. Es reicht aber nicht, jetzt einfach auch in KGRUPPE einen Zähler einzubauen, da man dann sozusagen zwei Zählerquellen hätte man braucht aber nur eine.

Um das Dilemma zu lösen erscheint mir folgendes als einfachster Weg: Wir machen uns eine Hilfstabelle, die für jede Kategoriengruppe-Kategorie-Kombination (also AA, AB, AC, …CA, CB, usw.) einen eigenen Zähler vorhält und die man mit der jeweiligen Kombination easy abfragen kann. Das wäre dann also eine Tabelle mit insgesamt 26 x 26 Einträgen.

Wobei mir grad folgender Gedanke kommt: Eigentlich ist so eine Tabelle an sich ja gar nicht so schlecht, d.h. es stellt sich die Frage, ob man nicht gleich diese „Kombi-Tabelle“ hernimmt und damit die Kategorie- und Kategoriengruppen-Tabellen ersetzt. Ich hab grad nicht auf dem Schirm ob das noch irgendwelche unerwünschten Seiteneffekte haben könnte, aber auf den ersten Blick fällt mir nichst ein was dagegen spräche. Was hälst Du davon ?

Falls aber doch irgendwas dagegen spricht machen wir einfach die Hilfstabelle für die Zähler.

Für das Hochzählen würde ich vor Eintragen in die DB eine sortierte Abfrage durchführen und den größten Gruppenindex inkrementieren und in den neuen Datensatz einfügen.

Klingt kompliziert und bin mir nicht sicher ob ich das richtig verstehe, aber ich glaube, damit hättest Du einfach nur quasi den Zähler von der Kategorie zur Gruppe verschoben und weiterhin nur 26 verschiedene Zähler (statt 26 x 26).



Nach einiger Überlegung komme ich zum gleichen Ergebnis bezüglich der Durchnummerierung.
Im Grunde wird meine Art der Durchnummerierung bei größeren Nummern nicht mehr so günstig anwendbar.

D.h. 12-M401 mag da günstig sein, jedoch 123912-M0401 dann nicht mehr.
So dass die Nummerierung nach Kategorien sinnvoller erscheint, d.h.

EB0012-M0401
AB0012-…
usw.

Selbst diese könnte man zu EB12-M401 abkürzen und würde es immer noch eindeutig finden.

Ich merke grad dass ich diesen Teil auch noch nicht ganz verstanden habe, ich hatte das wohl irgendwie so aufgefasst, dass Du damit nach Mitteln und Wegen suchst, wie man Teilenummern sozusagen optional abkürzen kann, also „optional“ etwa in dem Sinne, wie man das Materialkürzel am Schluss in Fällen wo das Material eh eindeutig (z.B. „Porzellantasse“ :wink:) oder aber belanglos ist, optional auch weglassen kann und diese Art von Optionalität auch auf „leading zeros“ also vorangehende Nullstellen in der Teilenummer anwendest. Was man ja m.E. auch durchaus so machen könnte, also „EB12“ leuchtet mir soweit ein.

Aber wie kommst Du beim Versionierungs-Teil auf „M0401“ ?? Ich versteh das als Versionierungsteil (FFVVMM), bei dem der Materialteil (MM) optional weggelassen wurde, aber dann dürften doch nur noch 4 Stellen (FFVV) verbleiben, was mich irritiert ist die 0 zwischen M und 4.

Gruss, Oliver

Aaaach, ich glaub, ich weiss jetzt, wo ein möglicher Haken bei der Kombi-Tabelle ist.

Die damit zu ersetzenden Tabellen sind ja für die Navigation gedacht, also etwa um für einen Selektor eine Komplettübersicht aller Gruppen bzw. aller Kategorien zu liefern und die ganzen Kürzel kommen dann natürlich mehrfach vor.

Sollte aber im Prinzip nicht völlig unmöglich sein, die durch eine entsprechende Abfrage zu reduzieren so das jedes Kürzel nur einmal vorkommt, auch wenn ich grad nicht auswendig weiss, wie.

hmm …

Zuerst das kleine Mistverständnis aufgeräumt, ich meine statt M04 = M4, dann sind es auch vier Stellen.
Ja ich denke, dass eine kurze Nummerierung durchaus sinnvoll sein kann, um u.a. die Suche etwas zu vereinfachen und ggf. auch Teileangaben komprimieren zu können.

Stelle dir einen Bauplan vor, welcher die Teile enthält. Dort könnte man Beispielsweise kurze Bezeichnungen verwenden um es dadurch übersichtlicher zu halten.

Am Ende des Bauplans wiederum könnte man die langen Nummern in einer Tabelle auflisten, ggf. die kurzen Nummern in Klammern dahinter schreiben.


Bezüglich der Zähler, hier dachte ich es mir schon, dass wir nach Gruppe + Kategorie hochzählen und jede Kombi einen eigenen Zähler erhält.

Wiederum würde ich den Zähler ungern in Hilfstabellen auslagern, sondern am Liebsten in der Tabelle Part in einem Feld mitführen und inkrementieren, weil du sonst mehrere Datenquellen hast und es zur Inkonsistenz kommen kann.

Beispiel:
Man fügt EB0001, EB0002, EB0003 ein.
Nun passiert es aus irgend einem Grund, dass der Zähler im letzten Fall nicht hochgezählt wird und noch bei 2 steht.
Würde nun ein weiteres Teil eingefügt, so würde erneut eine EB0003 existieren, was natürlich bedingt der Eigenschaft Unique zu einem Fehler führt, welchen ich wiederum abfangen müsste, usw. usw. usw.
Zudem könnte es passieren, dass Teile mittendrin gelöscht werden, z.B. die EB0002 gelöscht wird, weil sie vielleicht schon an anderer Stelle existiert oder falsch eingetragen wurde.
Diese Lücke könnte man über den Zähler nicht mehr füllen.

Deshalb würde ich eine Abfrage erstellen und dies vor einer Eintragung überprüfen und den Index in die Tabelle Part jeweils mit einfügen.
Dadurch entstehen keine Lücken und können Doppelungen ausgeschlossen werden.

TF

Ah, sehr gut, ich dachte schon ich seh den Wald vor lauter Bäumen nicht mehr :wink:

Ja ich denke, dass eine kurze Nummerierung durchaus sinnvoll sein kann, um u.a. die Suche etwas zu vereinfachen und ggf. auch Teileangaben komprimieren zu können.

Ja. Wir legen einfach als Konvention fest, das sobald eine Numbering oder Size aus weniger als vier Stellen besteht, dieses gleichbedeutend ist mit aufgefüllten Nullen. Und es ist ja ohnehin nur eine Frage der jeweiligen Anzeige bzw. Ausgabe innerhalb der DB liegt das ja söwiso als Integer vor.

Stelle dir einen Bauplan vor, welcher die Teile enthält. Dort könnte man Beispielsweise kurze Bezeichnungen verwenden um es dadurch übersichtlicher zu halten.

Normalerweise wäre ich eher ein Freund von einer einheitlichen Schreibweise, nämlich mit dem Argument das da niemals mehr als nur 10% aller Nummern von betroffen sein können, aber das gilt nur für die Theorie, i.d. Praxis muss man breücksichtigen, dass die DB ja noch nicht komplett gefüllt ist bzw. sich eher nach und nach füllt. D.h., gerade am Anfang sind sämtliche Nummern davon betroffen und somit ist es wirklich ein deutlich erkennbarer Unterschied bzw. Gewinn, wenn man die Nummern auch abgekürzt darstellen kann.




Wiederum würde ich den Zähler ungern in Hilfstabellen auslagern, sondern am Liebsten in der Tabelle Part in einem Feld mitführen und inkrementieren, weil du sonst mehrere Datenquellen hast und es zur Inkonsistenz kommen kann.

Diesen Satz versteh ich nicht so ganz, meinst Du, Du willst in PART in einem Feld zB. namens „zähler“ 26 x 26 = 667 Zähler anlegen und dann aus den Kürzeln von Gruppe und Kategorie die Adressierung darauf herleiten ? Also Etwa bei EB0012, das E entspricht im 26er-Alphabet einer 5 und das B einer 2, daraus ergibt sich 2 x 5 = 10, also die 10 wäre die Adresse wo Du beim Datensatz mit PART.id = 10 im Feld „zähler“ den Zählerstand für EB hinterlegt hättest.

Meinst Du sowas in der Art ? :wink: Das wär für mich ok, aber etwas weiter unten schlägst Du, wenn ich das richtig verstehe noch eine andere Methode vor :

Deshalb würde ich eine Abfrage erstellen und dies vor einer Eintragung überprüfen und den Index in die Tabelle Part jeweils mit einfügen.

Also quasi sowas wie SELECT MAX(numbering) FROM PART WHERE categoriegroup == „E“ and category == „B“, damit hättest Du das bislang höchste Numbering in der Kategorie EB, würdest dann diesen Wert einen hochzählen und das wäre dann das numbering für den neuen Datensatz.

Soweit auch für mich ok.

Dadurch entstehen keine Lücken und können Doppelungen ausgeschlossen werden.

Ja, letzteres ist definitiv oberstes Gebot, jede Bauteilnummer muss unique sein. Lücken sind aber m.E. nicht weiter schlimm, also wenn mal eine Nummer unbelegt wäre und einfach nicht benutzt würde. Aus meiner Sicht besteht also keine Notwendigkeit, wenn ein Datensatz gelöscht würde, die Nummer wieder mit in den Pool einzubringen.

Unter PostgreSQL kannst Du bei solchen Zählern einstellen ob sie solche Löcher auffüllen, d.h., sobald die nächste Nummer angefordert wird, dann zunächst die freigewordene Nummer wieder vergeben, oder halt ob die Löcher einfach ignoriert werden und eine neue höchste Nummer ausgespuckt wird. Denke, bei uns würde letzteres auch genügen.

Beispiel:
Man fügt EB0001, EB0002, EB0003 ein.
Nun passiert es aus irgend einem Grund, dass der Zähler im letzten Fall nicht hochgezählt wird und noch bei 2 steht.
Würde nun ein weiteres Teil eingefügt, so würde erneut eine EB0003 existieren, was natürlich bedingt der Eigenschaft Unique zu einem Fehler führt, welchen ich wiederum abfangen müsste, usw. usw. usw.
Zudem könnte es passieren, dass Teile mittendrin gelöscht werden, z.B. die EB0002 gelöscht wird, weil sie vielleicht schon an anderer Stelle existiert oder falsch eingetragen wurde.
Diese Lücke könnte man über den Zähler nicht mehr füllen.

Lücke wäre wie gesagt nicht so schlimm. Aber Du hast schon recht, man muss natürlich die Datenintegrität gewährleisten, weil ja auch mal ein Rechner während einer Dateneingabe abschmieren oder eine Netzverbindung unterbrochen werden kann. Das ist aber ein Standard-Problem bei allen Netzorientierten-MultiUser-DB-Anwendungen und da gibts entsprechende Methoden (Lock, Rollback und wasweissich) , in unserem Fall ists aber ganz easy: Du musst lediglich die korrekte Reihenfolge einhalten, d.h. ERST den Zähler hochzählen und DANN den neuen Datensatz reinschreiben. Sollte zwischendurch der Rechner abschmieren, dann würde solch eine Lücke oder Loch entstehen, aber das ist wie gesagt nicht weiter schlimm, bzw, hätte funktionell weiter keine negativen Folgen.

Was das abfangen des unique-Fehlers betrifft, so ist das gar keine schlechte Idee :wink: ich meine, Du brauchst eh eine „Rückmeldungsleitung“ zum User, der darüber auch bei einer erfolgreichen Eintragung eine Bestätigung erhalten würde, da kannst Du dann natürlich auch alle Fehlermeldungen durchschicken und insbesondere Meldungen über unique-Verletzungen. Das wäre glaub ich für uns als Programmer ganz interessant, denn ich denke die Unizität der Bauteilnr. ist das zentralste Ding überhaupt, was wir im Rahmen der Datenintegrität gewährleisten müssen und solange bei regulären Eingaben keine entsprechende Meldung kommt, wissen wir das alles Ordnung ist. Umgekehrt falls sowas käme, dann heisst das, das im irgendwo im Programm (oder in unserem Design) etwas Gravierendes faul ist.

Das wäre m.E. grad in der Entwicklungsphase sicher ein guter Testcase.

Aber nochmal zurück zum eigentlichen Ding: abgesehen von den jetzt gerade erörterten Möglichkeiten, was hälst Du von der Sache mit der Kombitabelle, also die Navigationstabellen von Gruppe und Kategorie in einer Tabelle zusammenzufassen ? Egal ob und aus welchen Gründen man das nun machen würde oder auch nicht, aber da könnte man den Zähler jedenfalls auch noch schön passend mit unterbringen.

Gruss, Oliver

Nabend Oliver

werde mich spätestens Montag mal ran setzen und die Dokumentation aktualisieren. Ich denke die Punkte sind weitestgehend geklärt.

Mit dem Zähler würde ich dies mittels
SELECT MAX(numbering) FROM PART WHERE categoriegroup == „E“ and category == „B“

handhaben.

TF

OK. Ich wünsch Dir ein schönes Wochenende !

Gruss, Oliver

So nun hab ich die Doku bzw. Modellierung mal aktualisiert.
http://catdev.btclink.org/wiki/index.php?title=Documentation#Tables

u.a. hab ich das Feld PartID entfernt, da es sich ja aus den Feldern CategoryGroup, Category, numbering (mit ZEROFILL) zusammensetzt.
numbering ist jeweils der Index zur jeweiligen Kombination CategoryGroup, Category.

Falls du jedoch auf das Feld PartID bestehst, so würde ich dieses Feld ggf. aus den genannten Parametern zusammensetzen nach dem Format EB0012.
Ist halt die Frage, ob wir das Feld zwingend mitschleppen müssen oder ob wir Beispielsweise die Sucheingabe des Nutzers analysieren und entsprechend die Abfrage der einzelnen Felder vornehmen.

geb mir mal Feedback, was du von meiner Dokumentation hältst.
Wenn dir das so gefällt, so würde ich anfangen die Felder einzurichten und einfache Eingabemasken zu erstellen.

TF

Hi Sebastian,

hab grad mal drübergeschaut, dabei fiel mir noch folgendes auf:

\

  • in Category fehlt noch die ParentId als Pointer auf die CategoryGroup

  • in beiden ist das label nur einstellig, also Char[1]

  • in allen Tabellen sollte ausser der Description noch ein Name-Feld sein, wobei ich letzteres auf varchar(120) setzen würde und Description auf varchar(240). Gerade bei exotischeren Bauteilen könnte man sonst Probleme bekommen wenn das Namensfeld zu kurz ist ( z.B. „Finnische Ziselierpunze mit gekröpftem Griff“) und bei Beschreibung/Description ists auch nicht verkehrt etwas mehr Platz zu haben und auch nicht weiter schlimm, da die eh nicht überall mit angezeigt wird.

Soweit es nur die schnelle Suchabfrage betrifft könnte man es zusammensetzen, so wie Du sagst. Aber Du brauchst dieses Feld unbedingt als uniques Element um die Unizität eines Part-Datensatzes zu gewährleisten. Du hast hier stattdessen unique key(CategoryGroup, Category, numbering) gesetzt, aber das ist falsch, denn alle diese Elemente kommen durchaus mehrfach in Part vor.

geb mir mal Feedback, was du von meiner Dokumentation hältst.
Wenn dir das so gefällt, so würde ich anfangen die Felder einzurichten und einfache Eingabemasken zu erstellen.

Ja, sieht gut aus soweit.

Bei Size könnte man das label übrigens auch als integer deklarieren (ähnlich wie das numbering in Part) und bei Size, Property und Material sollte man vielleicht noch einen Index auf die jeweiligen Labels legen. Das ist nicht zwingend aber würde noch ein bischen Performance bringen und kostet uns nix.

OK, damit hätte man dann schon mal die Kernstruktur und alles für die Navigation beschrieben.

Was jetzt noch fehlt das sind die eigentlichen bauteilbezogenen Komfort- bzw. Sachinformationen, aber die kann man auch noch später ergänzen und langfristig beliebig ausbauen, oder soll ich dazu jetzt schon was sagen ?

Hmm, vielleicht kurz zwei Sachen, die man jetzt schon berücksichtigen kann:

  1. In Part wäre ein integer-feld für „status“ sinnvoll, was verschiedene Zustände wie „Bauteil komplett beschrieben, incl. Fertigungszeichnungen“, etc. beschreibt. Welche Zustände das im einzelnen annehmen kann können wir uns noch später überlegen, aber dann wär zumindest das Feld schon mal da.

  2. Bezugsquellen: Das müsste eine eigene Tabelle sein die etwa folgende Felder enthalten könnte:

  • Anbieter
  • Anbieterwebsite-URL
  • ev. einen Link direkt auf das Bauteil im Shop des Anbieters
  • Preis des Bauteils zu einem bestimmten Datum
  • Datum, an welchem das Bauteil zu diesem preis angeboten wurde
  • Verknüpfung mit Part-Tabelle

Letzteres ist wieder etwas knifflig und wieder so ein Fall, wo ich mir den neulich schon erwähnten Datentyp „Array mit variabler Länge“ wünschen würde. Gibt es denn wirklich keine Entsprechung dafür in MySQL ?

Das Problem liegt jedenfalls darin, das sowohl ein Bauteil von mehreren Anbietern angeboten werden kann, als auch umgekehrt ein Anbieter ausser diesem einen noch weitere Bauteile anbietet.

Mit einem Array von variabler Größe könnte man das wunderbar erschlagen, da würdest Du dann in Part einfach in diesem Array so nach und nach die Indexnummern auf die jeweiligen Anbieter einfügen und umgekehrt beim Anbieter die jeweiligen PartIds auf die Teile, die er liefern kann. Das Schöne daran ist, das man die Größe des Arrays nicht vorher wissen muss und das im Laufe der Zeit beliebig wachsen kann.

Naja, erstmal bis dahin.

Gruss, Oliver

UNIQUE KEY bezieht sich auf die 3er-Kombination und diese sollte nicht mehrfach vorkommen.

Die Länge des Beschreibungsfeldes sollte soweit ok sein, da ich sowieso eine Anbindung einer Sprachdatenbank geplant habe.
Da schreibst du dann sowas wie {L_FINNISCHE_Z} rein und schreibst dies dann in der passenden Sprache ins Sprachpaket hinein.

TF

Ah, okay.

Die Länge des Beschreibungsfeldes sollte soweit ok sein, da ich sowieso eine Anbindung einer Sprachdatenbank geplant habe.
Da schreibst du dann sowas wie {L_FINNISCHE_Z} rein und schreibst dies dann in der passenden Sprache ins Sprachpaket hinein.

Ah, auch okay, aber das klingt nach viel Arbeit. Falls Du Dir das Leben erleichtern möchtest können wir uns auch gern darauf verständigen dass die Datenbank ausschliesslich in englisch gepflegt wird und gut is.

Sonst wirds diesen Sommer nix mehr mit dem https://discourse.test.opensourceecology.de/t/open-source-auto/547/1 :laughing:

Doku nun aktualisiert.


Als Statie halte ich spontan lediglich
„aktiv“
„inaktiv“
für interessant.

Um inaktiv weiter zu spezifizieren könnte ich mir

„inaktiv_update“, falls Informationen zu einem Teil überarbeitet werden und die Informationen nicht aktuell sind. U.a. könnte dieser Status mit Erstellen eines neuen Teils automatisch eingestellt sein, quasi Status 0. Erst wenn der Ersteller das Teil mit einem Button „Freigeben“ freigibt, wird der Status auf 1 = „aktiv“ geschaltet.

dann noch

„inaktiv_obsolete“, falls ein Teil bedingt neuer Entwicklungen überholt ist. Z.B. eine veraltete Lichttechnik, z.B. statt eines LCD Displays durch ein sparsameres besseres OLED-Display abgelöst wird.


Bezüglich deiner Array-Felder. Es gibt hierfür sicherlich auch in MySQL Möglichkeiten, dies zu gewährleisten.
In dem von dir aufgezählten Falle eines Anbieters, dem verschiedene Teile zugeordnet werden oder umgedreht, verwendet man in der Welt der Datenbanken üblicherweise Assoziationstabellen.
Dies hat u.a. den großen Vorteil, dass du mittels jenen Assoziationstabellen über JOIN die entsprechenden Daten sehr leicht selektieren kannst.
Natürlich sammeln sich in einer solchen Tabelle sehr viele Datensätze an, doch für MySQL stellt dies kein Problem dar.

TF

Bezüglich der Anbieterliste, dies würde ich definitiv in einem zweiten Schritt vornehmen, sonst werde wir wahrlich nicht mehr vor Ende des Sommers fertsch :wink:

TF

CategoryGroup und Category hab ich schon mal erstellt.

Alle weiteren Tabellen werde ich Donnerstag und Freitag erstellen, sowie erste Entwürfe von Eingabemasken (Creator) machen.

Ich möchte nämlich das schöne Wetter nutzen und andere Dinge tun, denn schnell ists wieder Herbst :wink:

TF

Hi,

Sieht soweit gut aus.

Als Statie halte ich spontan lediglich „aktiv“ „inaktiv“ für interessant.

Mir gehts dabei um den inhaltlichen Zustand dieses Bauteils. Die höchste Stufe wäre, das das Bauteil auch „voll qualifiziert“ im Sinne von „voll ausdefiniert“ im Sinne von voll dokumentiert ist, mit allen Bauplänen und Fertigungszeichnungen. Die niedrigste Stufe wäre „Bauteil neu angelegt“, d.h., mit Name, Description und gültiger BauteilNr. - aber es existiert noch keine Doku dazu.


„inaktiv_update“, falls Informationen zu einem Teil überarbeitet werden und die Informationen nicht aktuell sind. U.a. könnte dieser Status mit Erstellen eines neuen Teils automatisch eingestellt sein, quasi Status 0. Erst wenn der Ersteller das Teil mit einem Button „Freigeben“ freigibt, wird der Status auf 1 = „aktiv“ geschaltet.

Ja, das ist ja im Grunde dasselbe, nur würd ichs andersrum machen und den Ersteller direkt den Status setzen lassen - die jeweilige Stufe ergibt sich daraus dann ja automatisch.

„inaktiv_obsolete“, falls ein Teil bedingt neuer Entwicklungen überholt ist. Z.B. eine veraltete Lichttechnik, z.B. statt eines LCD Displays durch ein sparsameres besseres OLED-Display abgelöst wird.

Du kannst das Flag gerne einführen (für technische Zwecke, wie etwa ein Testobjekt), aber das von Dir genannte Beispiel wär für mich eher kein Grund ein Bauteil zu inaktivieren. Wer will denn entscheiden ob es noch gebraucht wird ? Und regelmässig die DB danach durchscannen ? Vielleicht sind ältere Teile preisgünstiger oder passen besser zu meinem Projekt, oder Du möchtest etwas älteres reparieren und brauchst Ersatzteil oder Doku, sowas kann nur der Anwender selbst entscheiden.

Wenn ein neues Bauteil oder eine neuere Version auf der Bildfläche erscheint, dann muss die alte Version aber auch sowiso noch im Pool/Katalog bleiben, weil vielleicht ja auch irgendwelche BOMs oder SETs darauf verweisen.
Auf deren Ebene ist allerdings eine Aktualisierung sehr gut möglich und dort wesentlich besser aufgehoben. In dem Fall wäre es Sache des Projektbetreibers in seiner BOM das Bauteil gegen ein neueres zu ersetzen.


Bezüglich deiner Array-Felder. Es gibt hierfür sicherlich auch in MySQL Möglichkeiten, dies zu gewährleisten.
In dem von dir aufgezählten Falle eines Anbieters, dem verschiedene Teile zugeordnet werden oder umgedreht, verwendet man in der Welt der Datenbanken üblicherweise Assoziationstabellen.
Dies hat u.a. den großen Vorteil, dass du mittels jenen Assoziationstabellen über JOIN die entsprechenden Daten sehr leicht selektieren kannst.
Natürlich sammeln sich in einer solchen Tabelle sehr viele Datensätze an, doch für MySQL stellt dies kein Problem dar.

Na, denn man zu :wink: Mir schiens halt einfacher das durch eine schlichte Variable zu regeln, wenns die denn so geben würde. …

… So, hab grad nochmal in die MySQL-Doku geschaut. Der passende Datentyp heisst BLOB. Den kann man als Integer-Array von beliebiger Länge verwenden, d.h., man kann damit innerhalb eines Bauteils eine beliebige Menge von Indizees auf Bezugsquellen vorhalten. Problem solved :wink:

Gruss, Oliver

Da ist was dran :wink:

Tabellen sind alle erstellt.

Als Nächstes gehts nun mit dem Eingabeformularen (Creator) weiter.

TF

die letzten Tage bin ich leider nicht dazu gekommen an dieser Sache weiter zu arbeiten, da ist mir ein anderes Projekt dazwischen gekommen.
Nächste Woche sollte ich aber Zeit finden.

TF

Langsam wird es wie es werden soll. Alle Klassen habe ich erstellt, bin nun dabei die Administration der Daten über Eingabeformulare zu erstellen.

TF