fastix®: MySQL

Beitrag lesen

Moin!

Also... ich würde so aufbauen:

table artikel:

| art_id | art_name | type_id | value_1 | value_2 | value_3 | .... | Freitext |

table_types:

| type_id | type_name | value_1_name | value_1_einheit | value_2_name | value_2_einheit  | ... |

Du musst beim Abfragen jetzt einen Join machen, der die Spaltennamen und Einheiten der reinen Maßzahlen aus table_types feststellt. Vorteil davon ist, daß Du jetzt alle Formulare und Ausgaben auch dynamisch erzeugen kannst: Bei Schrauben wird eben nur nach dem Gewinde,Länge und Festigkeit gefragt/angezeigt, bei Milch nach Packungsgröße, Fettgehalt etc.

Ebenso ist es recht einfach einen neuen Artikeltyp mit seinen Eigenschaften anzulegen.

Eine Kleinigkeit: Du musst die Spalten so anlegen, daß diese auch durchsuchbar sind und das man MySQL mit ihnen rechnen kann. Also dezimal mit der maximal benötigten Anzahl an Kommastellen.

Dafür ist dann aber auch möglich effektive Indizees zu erstellen. Das ist für die Durchsuchbarkeit unter Umständen wichtig. Wenn Du dann noch ein Regelwerk hast, welches sicherstellt, daß bei Muttern und Schrauben das Material und das Gewinde an der selben Stelle (value_X) stehen, dann kannst Du sogar effektiv danach suchen.

Variante 2:

Du kannst natürlich auch _ein_ Feld für Daten bestimmen, in dem dann sowas auftaucht:

DIN=125677;Laenge=25;Gewinde=6;Gewindetyp=metric;Farbe=schwarz

Das müsstest Du dann in einem Programm außerhalb von MySQL "fetchen"

Vorteil: scheinbar einfacher.

Nachteil: keine dynamischen Formulare möglich (bei Neueinträgen in die DB) verbraucht unnötig Speicher....

Ach ja... womöglich gibt's noch mehr Ideen, die auch alle richtig sein können. Das hängt immer von Zweck und Ziel ab.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix®

--
Als Freiberufler bin ich immer auf der Suche nach Aufträgen: Schulungen, Development. Auch  für seriöse Agenturen.