Hi,

bin hier immer noch dran, meine DB zu bestücken. Jetzt ist eine table dran, da sind Arrays drin, also Array [1..8] of record .... Soll ich die jetzt zerstückeln oder gibt es auch so was wie Arrays ? Habe mal ein paar Bücher gewälzt, darüber aber nichts gefunden.

Gruß
Hansa

Hallo Hansa,

für jeden Eintrag im Array solltest du einen Eintrag in einer Tabelle machen. Ist dieser Array selbst Teil einer Tabelle, solltest du den Array in eine zweite Tabelle schreiben und im der "array" Tabelle eine ID benutzen, mit der er an die Haupttabelle geknüpft werden kann.

Hi Hansa
aus der Sicht des DB-Designs ist die Lösung von MrSpock die beste. Wenn es sich dabei allerdings nur um 8 Felder handelt und sichergestellt ist, dass es definitiv nicht mehr werden, kannst du sie auch als Einzelfelder in deinem Satz anlegen und über Tabelle.Fields[index] darauf zugreifen.
Von der Verwendung von Arrays im Satz würde ich in Verbindung mit Delphi absehen.

Gruss Lothar

>und sichergestellt ist, dass es definitiv nicht mehr werden, ...
*bg
Das kannst du nicht sicherstellen. Imho sollte die Struktur immer flexibel bleiben. Das bringt einen Mehraufwand von 10% bei der ersten Erstellung aber spart die Mörderzeit bei Änderungen.

Klar kann man so was sicherstellen.

Wenn ich eine Tabelle baue, die nur Control-Werte enthält, z.B. Umsatzprovisionen auf Reisen und das Konzept vorsieht, dass es max. 8 Provisionsstaffeln gibt, werde ich einen Teufel tun und die 8 Sätze in eine eigene Tabelle auslagern. Das an sich ist ja auch eine Performance-Angelegenheit. Geht man davon aus, dass man an irgendeiner Stelle die Notwendigkeit hat, ein kartesisches Produkt abzuzbilden, steigt das Datenaufkommen mit der, nach der Datenbank-Normalform vorgeschriebenen Konstruktion, ziemlich schnell unnötig an, denn da kann schon der Faktor 8 einige zig-Milliarden zusätzliche Datensätze generieren.

Gruß,

Matthias

(Ach ja: Ich hoffe, es sagt jetzt keiner, dass man generell kein kartesisches Produkt braucht, weil es ja JOINs gibt

Hi,

neojones hat folgendes geschrieben:

und das Konzept vorsieht, dass es max. 8 Provisionsstaffeln gibt, werde ich einen Teufel tun und die 8 Sätze in eine eigene Tabelle auslagern

Genau das werde ich auch tun.

Bei mir geht es um Preisgruppen, ob 8 oder mehr ? Dann mach ich eben vorsichtshalber 10. Wer damit nicht auskommt muß mit Sonderpreisen hantieren. Es ging mir hauptsächlich darum, denArray-Index benutzen zu können. Z.B.:



Ob ich jetzt PG [2] oder PG2 schreibe ist ja wohl egal. Bei solchen Fällen handelt es sich um eine 1-dimensionale Matrix und nicht um ein kartesisches Produkt. Weiß sowieso nicht mehr, was das ist.

Gruß
Hansa

>Klar kann man so was sicherstellen.
Unsinn, das ist Hellseherei.

>Wenn ich eine Tabelle baue, die nur Control-Werte enthält, z.B.
>Umsatzprovisionen auf Reisen und das Konzept vorsieht, dass es max. 8
>Provisionsstaffeln gibt, werde ich einen Teufel tun und die 8 Sätze in
>eine eigene Tabelle auslagern.
Fehlt die Begründung.

>Das an sich ist ja auch eine Performance-Angelegenheit.
Eingeschränktes ja

>Geht man davon aus, dass man an irgendeiner Stelle die Notwendigkeit
>hat, ein kartesisches Produkt abzuzbilden, steigt das Datenaufkommen
>mit der, nach der Datenbank-Normalform vorgeschriebenen
>Konstruktion, ziemlich schnell unnötig an, denn da kann schon der
>Faktor 8 einige zig-Milliarden zusätzliche Datensätze generieren.
Unsinn. Es gibt wenige Datenbanken, die mit "zig-Milliarden" Datensätze umgehen können. Und bei denen hast du kein Performance Problem.

>Bei mir geht es um Preisgruppen, ob 8 oder mehr ? Dann mach ich eben
>vorsichtshalber 10.
Super ... genau das ist "Waste of Time"

Hallo neojones,

sicher ist das möglich. Wenn aber nur bei 1000 Datensätze einmal ein Rabatt eingeräumt wird und du in jedem Satz 8 Felder vorsiehst, wäre das ja die Verschwendung von Resourcen . Also gilt wie immer: "Kommt drauf an..."

@Hansa: Ich weiss nicht, ob du das richtig verstanden hast. Was LCS vorgeschlagen hat, ist der Zugriff aufFelder einer Tabelle über ihre Position im Fields-Array. In diesem Fall müsste deine Schleife dann eher so aussehen:



oder so. Du hast dann nicht mehr den Luxus über den Namen zuzugreifen. Ich habe so etwas bisher vermieden. Du kannst z.B. bei Paradox später einmal ein Feld an einer beliebigen Stelle einfügen und schon ist die K.... am dampfen . Es sieht zwar nicht so schön aus, aber du könntest auch schreiben:



Dann ist die Reihenfolge egal.

Hi,


@Steffer:

Zitat:

Super ... genau das ist "Waste of Time"

Zeitverschwendung ist es nicht, wenn man 4 Preisgruppen immer braucht, 8 hat und vorsichtshalber 10 daraus macht. Wenn doch bitte ich um Nachricht.

@MrSpock:

Zitat:

Was LCS vorgeschlagen hat, ist der Zugriff aufFelder einer Tabelle über ihre Position im Fields-Array.

Das da trifft ungefähr des Pudels Kern. Was, bzw. wozu ist denn ein Fields-Array da ? Das ist mir noch gar nicht über den Weg gelaufen.

Aber nochmals, es geht um Stanndard-Preisgruppen, also Listen, die für Standardfälle vorgesehen sind. Was da nicht rein passt erhält Sonderpreis (extra Table). Es ist also ein statisches Problem für jeden Artikel, um z.B. eine komplette Preisliste zu drucken und jemand mitzugeben. Eine Extra-Table macht dann eben keinen Sinn mehr.

Gruß
Hansa

>Zeitverschwendung ist es nicht, wenn man 4 Preisgruppen immer
>braucht, 8 hat und vorsichtshalber 10 daraus macht. Wenn doch bitte ich
>um Nachricht.
Wie nennst du das denn?
In deinem Beispiel hast du 6 "unnötige Gruppen" * 10 Zeichen = 60 * x Datensätze ...

Hi Leuts

MrSpock hat folgendes geschrieben:

Du hast dann nicht mehr den Luxus über den Namen zuzugreifen. Ich habe so etwas bisher vermieden.

Genau das (den Zugriff über Namen) habe ich bisher vermieden. Erstens bin ich schreibfaul (beim Programmieren) und zweitens hab ichs schon öfter erlebt, dass nach einer DB-Umstellung die Feldnamen nicht mehr verwendbar sind. Aber das ist schliesslich Geschmacksache.

MrSpock hat folgendes geschrieben:

Du kannst z.B. bei Paradox später einmal ein Feld an einer beliebigen Stelle einfügen und schon ist die K.... am dampfen .

Bei der Grossrechner-Programmiererei früher war das absolut tödlich. Die Angewohnheit neue Felder hinten dranzuhängen hab ich seitdem beibehalten und bin immer gut damit gefahren.

Steffer hat folgendes geschrieben:

Imho sollte die Struktur immer flexibel bleiben. Das bringt einen Mehraufwand von 10% bei der ersten Erstellung aber spart die Mörderzeit bei Änderungen.

Stimme ich zu. Natürlich ist es toll eine perfekt normalisierte Datenbank zu haben aber es gibt einfach ab und zu Situationen wo man dagegen verstossen muss um den Aufwand bei der Programmierung in den Griff zu kriegen. Und das ist halt genau das Problem bei diesen ganzen DB Aktionen.

Ich kenn das Gesamtprojekt ja nicht, aber aus dem was Hansa gesagt hat (Möglichkeit der Sonderpreisbildung) würde ich das genauso machen.

Gruss Lothar

Hi,

Zitat:

In deinem Beispiel hast du 6 "unnötige Gruppen" * 10 Zeichen = 60 * x Datensätze

Die 60 Bytes sind mir sch...egal. Es geht um die ganze DB, ist die falsch angelegt, ist das alles Mist. Irgendeiner will dann doch 10, und ich bin der Dumme.

Gruß
Hansa