große datenbank, oder viele abfragen?

[Roger]

hallo!

ich bin gerade mal wieder am schrauben...
dabei muss ich ne datenbank machen, die dann nur noch abgefragt werden soll. es kommen keine datensätze mehr hinzu.

jetzt bin ich dabei mir ein kopf zu machen, wie die db aussehen soll. jetzt steh ich vor zwei möglichkeiten (klingt vielleicht blöd, aber): entweder die einzelnen tabellen werden groß und ich habe wenig anfragen, weil alles in eine anfrage gepackt werden kann (leider ergeben sich so doppelte einträge), oder ich mach viele kleine tabellen (ohne doppelte einträge), muss dann aber mehrere anfragen an die db stellen.

was is nun besser/schlechter?

gruß.
roger.

[Cheatah]

Hi,

was is nun besser/schlechter?

beides ist schlecht, denn offenbar hast Du Dir noch nicht bewusst, was das "relational" im relationalen Datenbankmodell bedeutet. Gestalte Deine Tabellen so, dass Redundanz durch Verknüpfungen ersetzt wird. Für gewöhnlich sollte es möglich sein, jede (sinnvolle) Informationsmenge mittels eines einzigen SQL-Statements zu erhalten.

Cheatah

[Lude]

Hi,

Für gewöhnlich sollte es möglich sein, jede (sinnvolle) Informationsmenge mittels eines einzigen SQL-Statements zu erhalten.

Fuer Skalare, Datensaetze und Datensatzmengen gilt das. Was aber mit "Dokumenten", also, wenn die zweite Dimension nicht mehr ausreicht?

Gruss,
Lude

[Cheatah]

Hi,

Für gewöhnlich sollte es möglich sein, jede (sinnvolle) Informationsmenge mittels eines einzigen SQL-Statements zu erhalten.
Fuer Skalare, Datensaetze und Datensatzmengen gilt das. Was aber mit "Dokumenten", also, wenn die zweite Dimension nicht mehr ausreicht?

dann nutzt man SQL-Funktionen, die entsprechende Abfragen erlauben. Bei Oracle beispielsweise das Intermedia Text Package.

Cheatah

[Lude]

Hi,

Für gewöhnlich sollte es möglich sein, jede (sinnvolle) Informationsmenge mittels eines einzigen SQL-Statements zu erhalten.
Fuer Skalare, Datensaetze und Datensatzmengen gilt das. Was aber mit "Dokumenten", also, wenn die zweite Dimension nicht mehr ausreicht?

dann nutzt man SQL-Funktionen, die entsprechende Abfragen erlauben. Bei Oracle beispielsweise das Intermedia Text Package.

heisst das, dass man bei Oracle mithilfe des 'Intermedia Text Package' und mithilfe eines einzigen SQL-Statements Daten komplexerer Struktur als Datensatzmengen erzeugen kann?

Ganz konkretes Beispiel: ein HTML-Dokument, dass der Erfassung eines Fahrtwunsches mit der 'DB' dient. Dieses bezieht seine Daten m.E. zwangslaeufig aus verschiedenen Datenbank-Abfragen (Stichwort "Nachschlagetabellen").

Gruss,
Lude

[Christoph Zurnieden]

Hi,

ich bin gerade mal wieder am schrauben...

An einem Montag? ;-)

dabei muss ich ne datenbank machen, die dann nur noch abgefragt werden soll. es kommen keine datensätze mehr hinzu.

Statisch, also, das erleichtert vieles.

jetzt bin ich dabei mir ein kopf zu machen, wie die db aussehen soll.

Sehr löblich. Meistens wird da nämlich einfach etwas zusammengehauen.

jetzt steh ich vor zwei möglichkeiten (klingt vielleicht blöd, aber): entweder die einzelnen tabellen werden groß und ich habe wenig anfragen, weil alles in eine anfrage gepackt werden kann (leider ergeben sich so doppelte einträge), oder ich mach viele kleine tabellen (ohne doppelte einträge), muss dann aber mehrere anfragen an die db stellen.

was is nun besser/schlechter?

Wie Cheetah schon anmerkte: beides ist schlecht.
Weil ich gerade Zeit habe und sich sowas im Archiv auch gut macht (steht zwar drin, ist aber sehr verteilt) nehme ich Dich mal an die Hand beim Entwurf einer relationalen Datenbank (Schade, das einige Leute hier Michael Schröpl vergrault haben, der wäre für die Aufgabe wahrscheinlich besser geeignet):

Was genau soll gespeichert werden:
Ist es eine Textzeile (maximale Länge), eine Nummer (aus |N oder |R? Wie groß?), Bilder oder ähnliche Binärdaten?

Wo hängen die Daten zusammen:
Hint: Das sind Deine doppelten Einträge.

Wonach wird hauptsächlich gesucht.

so short

Christoph Zurnieden

[Lude]

Hi,

jetzt steh ich vor zwei möglichkeiten (klingt vielleicht blöd, aber): entweder die einzelnen tabellen werden groß und ich habe wenig anfragen, weil alles in eine anfrage gepackt werden kann (leider ergeben sich so doppelte einträge), oder ich mach viele kleine tabellen (ohne doppelte einträge), muss dann aber mehrere anfragen an die db stellen.

was is nun besser/schlechter?

Wie Cheetah schon anmerkte: beides ist schlecht.

Die nichtnormalisierten Daten auf mehrere Tabellen zu verteilen ist schlechter. 2 Fragen: Sind die Daten nun normalisiert? Warum kommt es zu doppelten Eintraegen?

(Schade, das einige Leute hier Michael Schröpl vergrault haben, der wäre für die Aufgabe wahrscheinlich besser geeignet):

Was ist denn mit 'Michael Schröpl' passiert?

Was genau soll gespeichert werden:

Das ist die Kernfrage. Von Interesse auch der Sachverhalt der abgebildet werden soll. Da kann man bei der Erlaeuterung fast kein Wort zu viel verlieren.   ;-)

Gruss,
Lude

[Roger]

Hi,
An einem Montag? ;-)

na immer doch :D

nehme ich Dich mal an die Hand beim Entwurf einer relationalen Datenbank

danke sehr. na dann wollen wir mal losgehen...
nach ner weile nachdenken (is ja schon ne weile verstrichen), scheint es dann doch wieder nicht allzu kompliziert und umfangreich zu werden.

ich versuch mal alle frage zu beantworten (ohne sie jetz nochmals zu zitieren):

ich habe regale. :D
diese sind aufgeteilt in ständer, arme, diagonalen, distanzen, etc. pp.
die regale können einseitig oder doppelseitig sein.
bei den ständern gibts dann auch wieder unterschiedliche arten, weil, je nach größe diese zerlegt werden müssen...

um's zu vereinfachen:
ich muss anhand der belastung zunächst mal den richtigen ständer finden. es gibt aber zig möglichkeiten.
konstanten eines ständers wären:

• höhe
• fußtiefe
• ipe (profil)
• bauart (einseitig, doppelseitig)
• oberfläche (lackiert, verzinkt)
• befestigung (geschraubt, gehangen)

anhand dieser merkmale möchte ich folgende werte ermitteln:

• gewicht
• preis

is ja alles prima, wenn ich es in ne db schreibe und dann einfach abfrage. aber dann habe ich ja diese große tabelle, von der ich anfangs sprach.
die redundanz tritt bei den beiden gesuchten werten auf. preis und gewicht kommen bei den verschiedenen ständern min 4fach wenn nicht sogar 8fach vor, da sich die bauart ähnelt.
um es noch deutlicher zu machen:
würde ich eine tabelle nur mit (gleich mal mit bsp-werten):

• höhe (1500-6000) -> smallint
• fußtiefe (800-3400) -> smallint
• ipe (80-400) -> smallint
• bauart (1/2) -> tinyint
• oberfläche (1/2) -> tinyint
• befestigung (1/2) -> tinyint

und eine tabelle mit:

• gewicht (0.00 - ...) -> decimal(10,2)
• preis (0.00 - ...) -> decimal(10,2)

würde ich garantiert weniger platz verbrauchen, als wenn ich die zweite tabelle in der ersten zusammenfasse (was ich wegen meiner faulheit auch vorhaben werde - doch ich lass mich gern eines besseren belehren).

nun mach ich mir deswegen sorgen, weil's nicht einfach so ne pille palle tabelle wird, sondern da kommen mal schnell 500.000 einträge  für die ständertabelle zu stande (jede menge ständer ;) ) und das wäre dann erst die erste tabelle...

ums vorweg zu nehmen: die werte bauart, oberflaeche, befestigung würde ich schon so bauen, das nur "1" oder "2" drin steht, diese kann ich dann später per array wieder "nachtragen". da es sich nur um 2-3 werte handelt, will ich nicht unbedingt die db damit strapazieren.

achja: das ganze will/muss ich mit ner mysql db und php realisieren.

gruß.
roger.

[Frank]

Hi roger,

dein gesamter gedanklicher Ansatz ist falsch. Um den Sinn von relationalen Datenbanken (RDBMS) zu begreifen, solltest du vielleicht eine Spur kleiner anfangen. Dann wirst du sicher schneller auf "das Prinzip dahinter" stoßen und es anwenden lernen, als wenn du auf Krampf versuchst Gewicht und Preis in eine zusammenhangslose Tabelle zu werfen.

Tschau, Frank

[Roger]

na dann gib mir doch einfach mal einen richtigen ansatz dazu...

gruß.
roger.

[Christoph Zurnieden]

Hi,

Hat ein wenig länger gedauert, aber wenn ich schonmal meine etwas Zeit zu haben ... ;-)

ich muss anhand der belastung zunächst mal den richtigen ständer finden. es gibt aber zig möglichkeiten.
konstanten eines ständers wären:

• höhe
• fußtiefe
• ipe (profil)
• bauart (einseitig, doppelseitig)
• oberfläche (lackiert, verzinkt)
• befestigung (geschraubt, gehangen)

Wenn die Ständer zusammengebaut werden, sind das keine Konstanten, sondern Variablen. Nur und wirklich _nur_ die kleinsten Teile sind Konstanten, alles andere baust Du ja zusammen.
(Etwas vergröbert, da Du wahrscheinlich Schrauben und Muttern nicht unbedingt mit reinhauen mußt, kannst Du ja danach besser berechnen, statt den Wert vorzuhalten.)

anhand dieser merkmale möchte ich folgende werte ermitteln:

• gewicht
• preis

Das rechnest Du aus, das kommt nicht in die Tabelle, ist das so korrekt?

würde ich eine tabelle nur mit (gleich mal mit bsp-werten):

• höhe (1500-6000) -> smallint
• fußtiefe (800-3400) -> smallint

[...]

und eine tabelle mit:

• gewicht (0.00 - ...) -> decimal(10,2)
• preis (0.00 - ...) -> decimal(10,2)

würde ich garantiert weniger platz verbrauchen, als wenn ich die zweite tabelle in der ersten zusammenfasse (was ich wegen meiner faulheit auch vorhaben werde - doch ich lass mich gern eines besseren belehren).

Also zusammenfassend:

Du baust Regalständer aus Modulen zusammen. Diese Module gibt es in den verschiedensten Ausführungen. Wenn Du alle Module für einen bestimmten Regalständer zusammenrechnest bekommst Du Gewicht und Preis. Ist das so korrekt?
Gut.
Jetzt möchtest Du aus welchen Gründen auch immer alle Kombinationen vorhalten. (Naja, Festplattenspeicher ist billig, warum auch nicht)

nun mach ich mir deswegen sorgen, weil's nicht einfach so ne pille palle tabelle wird, sondern da kommen mal schnell 500.000 einträge  für die ständertabelle zu stande (jede menge ständer ;) ) und das wäre dann erst die erste tabelle...

Das spielt doch im Grunde genommen keine Rolle, die Suchzeiten sind bei einer Datenbank gleich, ob Du nun 500 oder 500.000 Einträge hast.
(Ja, ich weiß, aber der Unterschied ist wirklich minimal, wenn die Datenbank vernünftig gebastelt wurde).
Nur, wenn Du in der Datenbank selber suchen mußt, wird's kompliziert. Also sorgfältig planen, wo der Index sitzen soll (MySQL unterstützt AFAIK nur einmal Index, lasse mich aber gerne eines Besseren belehren, bin nicht ganz auf dem Laufenden)

ums vorweg zu nehmen: die werte bauart, oberflaeche, befestigung würde ich schon so bauen, das nur "1" oder "2" drin steht, diese kann ich dann später per array wieder "nachtragen". da es sich nur um 2-3 werte handelt, will ich nicht unbedingt die db damit strapazieren.

Warum redest Du da von strapazieren? Genau für sowas ist ein DB da: viele Daten schnell greifbar zu halten.

Es ist ja meistens so, das Du Dir dafür einen kleinen Server anmietest, der hat jede Menge Festplattenplatz, aber nur eine begrenzte Menge Rechenkraft. Ich würde also soviel wie möglich in die DB auslagern.

Alles ein wenig durcheinander, deshalb hier noch eine Zusammenfassung (Die allerdings zu einem anderem Schluß kommt ;-):

Du baust Regalständer aus Modulen zusammen.
Die Module haben als Eigenschaften Preis, Gewicht, Größe (nehme mal an, das es ein paar verschiedene sind) und "Aussehen" (Material, Struktur, Farbe etc). Ich nehme an, das die Statik der Module jeweils gleich ist, wenn nicht gehören diese Werte auch noch mit rein.

Damit hättest Du eine Handvoll Module, die genau beschrieben sind.
Aus einer diskreten Anzahl Module (teilen kann man die nicht, oder? Es werden immer nur ganze Module benutzt?) baust Du dann Regalständer zusammen.

Dieser Zusammenbau geschieht nach Regeln.

Du suchst: Preis und Gewicht. Beide Werte ergeben sich aus Anzahl und Art der Module. Auch eine Regel.

Du hast also auf einer Seite die Daten (Welches Modul) und auf der anderen Seite die Regeln (Ständer besteht aus x Modulen der Art Y wenn das Dingen soundso groß sein soll, sowie: Preis und Gewicht, die ergeben sich aus der Anzahl der Module der Art Y)

Die Daten gehören in die DB (Heißt ja auch: _Daten_bank ;-), die Regeln führst Du dann mit PHP aus.

Ein Beispiel:
Der Kunde bestellt ein Regal der Größe 3x5x1m, 3 Bretter, Fachlast max 100kg/m^2, Stützlast Boden punktuell max 250kg/cm^2.
Die Aufgabe von PHP, nein, die vom Programmierer natürlich ;-), ist es, anhand dieser Daten die erforderliche Art und Anzahl an Modulen zu errechnen. Der Kunde möchte nun seine Ständer gerne in RAL 3000 (Feuerwehrrot) haben und zwar Pulverbeschichtet. Jetzt kannst Du mit PHP an die Datenbank gehen, das Modul Y in der passenden Farbe und Größe raussuchen und Preise und Gewichte addieren. Anhand einer kleinen Tabelle, zu beziehen von Deinem $SPEDITEUR, kannst Du dann auch gleich das Porto errechnen.
Wenn Du auch Aufbau mit anbietest wahrscheinlich auch gleich die Montagekosten. (Hängt aber von mehr Faktoren ab, deshalb die Einschränkung)

Und schon wird aus einer Riesentabelle, die übrigens nur sehr aufwendig zu erstellen gewesen wäre, eine recht kleine und noch ein wenig Hirnakrobatik um die Algorithmen in PHP umzusetzen.

Noch Fragen?
Wahrscheinlich nehme ich mal an ;-)
Gerne hier.

so short

Christph Zurnieden

[Roger]

Hi,

ja. im grunde genommen kann ich dir erst mal grob recht geben. nur weiss ich eben nicht, was dein genanntes beispiel von meinem ersten unterscheidet? die handhabung und funktionsweise einer db ist mir geläufig. einfach schnell ne datenbank basteln hatte ich aber nicht vor. ich wollte mir eben ratschläge einholen, wie ich sie performanter/besser machen kann. schliesslich will ich ja dazulernen ;)

sicherlich wird das regal aus sogn. modulen zusammen gebaut. dabei haben die besondere eigenschaften (wie du richtig erkannt hast ;)). diese module haben nun auch die eigenschaften gewicht und preis. diese eigenschaften kommen öfters mehrfach vor. da ich redundanz eigentlich vermeiden wollte, wollte ich wissen ob es sinnvoll ist, die letztgenannten eigenschaften in eine extra tabelle auszugliedern. allerdings gestaltet sich doch dann auch eine pflege recht unübersichtlich... oder?

gruß.
roger.

[Christoph Zurnieden]

Hi,

ja. im grunde genommen kann ich dir erst mal grob recht geben. nur weiss ich eben nicht, was dein genanntes beispiel von meinem ersten unterscheidet? die handhabung und funktionsweise einer db ist mir geläufig. einfach schnell ne datenbank basteln hatte ich aber nicht vor. ich wollte mir eben ratschläge einholen, wie ich sie performanter/besser machen kann. schliesslich will ich ja dazulernen ;)

Eben deshalb kommt als erstes die Analyse des Problems. Wenn Du ncht weißt, was _genau_ Du benötigst, fängt das T&E an und Du fummelst Dich tot. Ich kenn' das aus eigener Erfahrung ;-)

sicherlich wird das regal aus sogn. modulen zusammen gebaut. dabei haben die besondere eigenschaften (wie du richtig erkannt hast ;)). diese module haben nun auch die eigenschaften gewicht und preis. diese eigenschaften kommen öfters mehrfach vor. da ich redundanz eigentlich vermeiden wollte, wollte ich wissen ob es sinnvoll ist, die letztgenannten eigenschaften in eine extra tabelle auszugliedern. allerdings gestaltet sich doch dann auch eine pflege recht unübersichtlich... oder?

Das die ganzen Regale aus Modulen bestehen - zumindest Ständer und Bretter - hatte ich schon vermutet ;-)
Du hast aber von Ständern gesprochen. Macht keinen Unterschied? Muß ich Dir Recht geben ;-)

Einige Dinger könntest Du rausnehmen bzw verallgemeinern, wenn diese Dinger tatsächlich redundant sind. ("redundant" ist nicht unbedingt gleichbedeutend mit "mehrfach"). So könntest Du z.B. die Unterscheidung in Farben rausnehen, wenn die unterschiedlichen Farben in den jeweiligen Färbungsarten (Pulverbeschichtet, Einbrennlackiert, Schleiflack etc) gleich sind. Wie heißt das immer so schön:"In allen RAL Farben erhältlich" ;-)
Jetzt hast Du aber z.B. die Stelle, wo es möglich ist die Module einmal nur verzinkt, verzinkt und lackiert und nur lackiert anbieten zu müssen. (Blödes Beispiel, aber Du weißt, was ich meine, oder? ;-)
Wenn das oft genug vorkommt, kannst Du das entfernen und ausrechnen (Verzinkt wird z.B. nach Gewicht, das hast Du ja).
Also eine kleine Tabelle mit Aufpreisen erstellen (kann direkt in PHP sein, würde ich der flexibilität wegen aber auch in die DB basteln. Getrennte Tabelle ist hier evt günstiger, je nachdem, wie sich die Preise so ändern):
Modul X = 12,50 EUR, 2,5 kg
verzinkt += 1,50 EUR/kg (evt noch + 0,1 kg Gewicht?)
lackiert += 1,90 EUR/kg
pulverbe += 2,00 EUR/kg

Wenn Du diese Aufteilung nicht hast (wird alles so fetig geliefert mit Festpreisen) sind diese Details nicht mehr redundant, sondern gehören zum Artikel. Auch wenn es die gleichen sind.

Ohne _genaue_ Kenntnis der Daten (genaue Preise wären Dein Geschäftsgeheimnis, aber auch irrelelvant) kann ich wirklich nur so allgemein bleiben.
Wenn ich es wüßte, könnte ich Dir auch sagen, ob es sich lohnt, das führende Adkjektiv des Ausdrucks "relationale Datenbank" beim Wort zu nehmen und die Daten in mehr oder weniger viele kleine, untereinander verbundene Tabellen aufzuteilen.

Ein simples "Redundanzen auslagern" ist nicht sonderlich wirkungsvoll, eher kontraproduktiv. Wenn Du in eine große Tabelle alle Spielarten reinpackst und lagerst dann alle gleichen Preise und Gewichte aus, spart nicht viel, erhöht wahrscheinlich nur unnötig die Komplexität.

Es sei denn:
Das Du nur _sehr_ wenige Gewichts- und Preisklassen hast. Dann kannst Du in einen Integer (also eine Spalte statt zwei) beide Klassen reinpacken und eine zweite Tabelle abfragen. Wenn Du dann auch noch alle weiteren Redundanzen rausschmeißt, wäre es evt möglich, die ganze DB im RAM zu halten, was einen erheblichen Geschwindigkeitsvorteil ergibt. (Das mußt Du bei modernen DBs übrigens nicht mehr extra angeben, das optimieren die von sich aus. Nur müssen die Tabellen halt klein genug sein in den RAM zu passen)

Es kann also nicht allgemein beantwortet werden, ob die Daten von den Regeln streng getrennt werden, oder ob es sich evt lohnt, einige oder gar alle der Regeln vorzufertigen. Bei einer geringen Anzahl an Permutatinen könnte sich das lohnen, aber die Frage ist: was genau ist "gering"?

Aber Du könntest natürlich auch mal schauen, was die Konkurenz so treibt. Ich tue das mal für Dich und nehme mir den Ikea Katalog zur Hand, da sind ja auch Regalsysteme drin ;-)
Da stehen gelistet: Größe, Oberfläche, Preis. Unten drunter und nicht in der Liste: Aufschlag für $WWI. ($WWI = 'Was Weiß Ich' ;-)

Regalsystem Hältvil:
2mx0,8mx0,5m (HxBxT) Kiefer,furniert 26,95
 -"-  rot,blau 25,95
 -"-  weiß  24,95
2mx1,6mx0,5m (HxBxT) Kiefer,furniert 49,95
 -"-  rot,blau 48,95
 -"-  weiß  47,95
Aufschlag für lesbare Aufbauanleitung: plus 10,00

Jetzt hättest Du folgende Möglichkeiten, das in eine DB zu packen (Für die drei Dinger natürlich nicht, ist nur zwecks Simplifizierung):

Einmal komplett aufgerollt:

Hältvil 2mx0,8mx0,5m (HxBxT) Kiefer,furniert 26,95 10,00
Hältvil 2mx0,8mx0,5m (HxBxT) rot  25,95 10,00
Hältvil 2mx0,8mx0,5m (HxBxT) blau  25,95 10,00
Hältvil 2mx0,8mx0,5m (HxBxT) weiß  25,95 10,00
Hältvil 2mx1,6mx0,5m (HxBxT) Kiefer,furniert 26,95 10,00
Hältvil 2mx1,6mx0,5m (HxBxT) rot  25,95 10,00
Hältvil 2mx1,6mx0,5m (HxBxT) blau  25,95 10,00
Hältvil 2mx1,6mx0,5m (HxBxT) weiß  25,95 10,00

Vorteile: Nur Abfrage der DB nötig, keine große Rechenleistung.
Nachteile: braucht viel Platz und komplexe Abfragetechnik, letzteres kann die eingesparte Rechenleistung wieder auffressen.

Das ist jetzt Dein Grundgerüst, das würde funktionieren, _erst_ jetzt kannst Du optimieren. Zunächst einmal nachschauen, wo denn die Redundanzen liegen. Ein, wenn auch nicht immer zutreffendes Merkmal einer Redundanz ist das mehrfache Vorkommen von Werten. Hier sind es: der Name, die Größe und der Aufpreis. Außerdem ist da zweimal der gleiche Preis, das merken wir uns schon mal vor.

Der Aufpreis kann als das behandelt werden, was er ist: ein Aufpreis.
Korrekterweise ist so eine Anleitung nur einmal nötig, aber das ignorieren wir mal und schieben das auf das beschissene Beispiel ;-)
So ein Aufpreis ist eine einfache Addition, das kostet nicht viel rechnleistung also nehmen wir das mal ganz aus der DB raus und lassen das die Maschine machen. Schon ist eine Spalte ganz verschwunden.

Was können wir noch vereinfachen? Lesen wir doch drei Reihen einmal laut vor:

Das Regal "Hältvil" in der Größe 2mx0,8mx0,5m kostet in der Ausführung rot 25,95.
Das Regal "Hältvil" in der Größe 2mx0,8mx0,5m kostet in der Ausführung weiß 24,95.
Das Regal "Hältvil" in der Größe 2mx1,6mx0,5m kostet in der Ausführung rot 48,95.

Als fester Wert ist hier der Name des Regals vorhanden, als variable Werte einmal die Größe und einmal der Preis, alles andere bleibt in der Beziehung gleich. Also können wir da mehrere Tabellen rausmachen, wie das in der "aufgerollten" Variante bereits intuitiv ersichtlich war. (Ist aber natürlich nicht unbedingt _jedesmal_ so intuitiv ersichtlich ;-)
Einmal:
Hältvil 2mx0,8mx0,5m ID(Hältvil,Größe-1)
Hältvil 2mx1,6mx0,5m ID(Hältvil,Größe-2)
(ID() ist eine Identifikationsnummer)

Und zum zweiten:
ID(Hältvil,Größe-1) Kiefer,furniert 26,95
ID(Hältvil,Größe-1) rot  25,95
[...]
ID(Hältvil,Größe-2) Kiefer,furniert 49,95
ID(Hältvil,Größe-2) rot  48,95
[...]

Nach dem altem Motto "rinse, repeat", nochmal das Selbe und wir sehen, das die zweite Tabelle ebenfalls gesplittet werden könnte. Ob sich das lohnt ist eine andere Frage. Bei sehr vielen Größen _und_ sehr vielen Oberflächen: vielleicht.

Nun gibt es da aber ncht nur ein Regal, sondern - Geschmäcker sind bekanntlich verschieden - viele verschiedene Designs:
Hältvil, Hältnits, Knürscht, Anita, Ekbert ...

Die kannst Du nun einfach in die erste Tabelle mit reinpacken, oder noch eine Tabelle darüber packen, die nichts als die Namen enthält und einen "Link" zu der Größentabelle.

Du siehst: was redundant ist, entscheidet weniger die Mehrheit als die Zusammengehörigkeit und das erlaubte Maß an Komplexität. (Je simpler, desto besser. Erst wenn dieses Konzept nicht mehr den Anforderungen entspricht (Meistens Geschwindikeitsprobleme) optimieren.) Einfach alle mehrfach vorkommenden Preise und in Deinem Fall auch Gewichte auslagern bringt es nicht.
Hier kommen auch wieder die blauen und roten Regale zum Zuge: kosten beide das Gleiche, habe ich aber nicht mehr ausgelagert. Warum nicht? Sind nur zwei Stück, das lohnt nicht.

Habe ich Dich jetzt ausreichend verwirrt? Ja? Wolltest doch nur wissen, ob es sich lohnt, Preis und Gewicht auszulagern und bekommst zweimal(!) so einen Sermon serviert? Tja, Datenbanken sind ein sehr komplexes Thema, meistens erfordert auch eine scheinbar simple Frage eine langwierige Antwort, die Dir am Ende doch nicht _direkt_ helfen kann.

Es gibt einige allgemeine Bücher zum Thema relationale Datenbanken. Schau einfach mal bei O'Reileigh (Da weiß ich nie, wie man die schreibt und von hier aus seh' ich das Regal nicht, bin zu kurzsichtig ;-) oder Amazon und nimm Dir ein Wochenende Zeit.

so short

Christoph Zurnieden

[Roger]

ui.
ne ganze menge text ;)
danke, dass du dir dafür zeit genommen hast.

nee nee, hat mir geholfen :D ich wollte ja nicht wissen wie ich nun die struktur aufbaue, sondern ich wollte es erstmal verstehen. jetzt isses bestimmt einfacher.

hab in der zeit des threads schonmal einen teil der daten zusammengetragen (aus ner blöden, vom "fachmann" zusammengestellten ecxel tablle mit 50 arbeitsblättern, tolle arbeit), sortiert und in textdateien geschrieben. so kann ich die dann später, wenn ich die db fertig strukturiert habe besser einlesen. 10mb wirres zeux. naja....

gruß.
roger.

ps: mein regal steht auch weit weg. aber aufgrund meiner "ordnung" liegt immer genügend zeug in der nähe (auf/unter dem schreibtisch): O'Reilly

[Christoph Zurnieden]

Hi,

ui
ne ganze menge text ;)
danke, dass du dir dafür zeit genommen hast.

Naja, sonst nix zu tun, der nächste Auftrag steht erst für Dienstag an ;-)

nee nee, hat mir geholfen :D ich wollte ja nicht wissen wie ich nun die struktur aufbaue, sondern ich wollte es erstmal verstehen.

Genau dafür ist dieses Forum da. Denn mit Verständniss ...

[...] isses bestimmt einfacher.

... als wenn ich Dir ein fertiges "CREATE TABLE ..." hingehauen hätte ;-)

Jaja, wofür so ein Ikearegal alles gut ist ... ;-)

hab in der zeit des threads schonmal einen teil der daten zusammengetragen (aus ner blöden, vom "fachmann" zusammengestellten ecxel tablle mit 50 arbeitsblättern, tolle arbeit),

Nunja, war bestimmt mühsam das alles mit Excel zusammenzubauen >;->

sortiert und in textdateien geschrieben. so kann ich die dann später, wenn ich die db fertig strukturiert habe besser einlesen. 10mb wirres zeux. naja....

Jetzt kannst Du die Dinger aber wenigstens schonmal mit Perl, oder - da es sich um Tabellen, CSV oder TSV,  handelt - (g)awk bequem sortieren und gleich als "CREATE TABLE" ausspucken lassen.
Zumindest für Perl gibt es in diesem Forum einige Spezialisten, die sicherlich gerne bei Problemen behilflich sind.

ps: mein regal steht auch weit weg. aber aufgrund meiner "ordnung" liegt immer genügend zeug in der nähe (auf/unter dem schreibtisch): O'Reilly

Ah, danke. Das ist aber auch ein Name, dessen Orthographie ich mir um's Verrecken nicht merken kann ;-)

so short

Christoph Zurnieden

[Roger]

Hi,
Jaja, wofür so ein Ikearegal alles gut ist ... ;-)

wird regalmissbrauch strafrechtlich verfolgt? lol

Nunja, war bestimmt mühsam das alles mit Excel zusammenzubauen >;->

nich mein problem ;)

Jetzt kannst Du die Dinger aber wenigstens schonmal mit Perl, oder - da es sich um Tabellen, CSV oder TSV,  handelt - (g)awk bequem sortieren und gleich als "CREATE TABLE" ausspucken lassen.

das war mein anliegen, warum ich sie eben in die textdatei geschrieben hab ;)

Ah, danke. Das ist aber auch ein Name, dessen Orthographie ich mir um's Verrecken nicht merken kann ;-)

gut, dann schreibe mir ne mail bis heute abend mit 100mal O'Reilly. :D

gruß.
roger.