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