Select * from

[Hansa]

Es geht mir hier um den Netzwerk-Traffic.

Code:

SELECT * FROM STATISTIK....

Nun, in der DB sind 5 Gruppen mit Monaten von 1..12 angelegt, z.B. Umsatz, Menge, Stückzahl usw. jeweils für jeden Monat eines Jahres. Auswertungen brauche ich aber nur jeweils z.B. für Umsatz.

Jetzt könnte ich ja schreiben

Code:

SELECT UMSATZ1,.......UMSATZ12 FROM...

das ist aber sehr umständlich. Da 60 aber trotzdem viel kleiner als 12 ist, frage ich nun, lohnt sich das oder ist es für die Katz

Gruß
Hansa

[X-Dragon]

Vielleicht sollte man die Datenbank auf 2 oder mehr Datenbanken aufteilen, denn 60 Spalten sind ja doch recht viel. Wäre dann aber natürlich wieder ein etwas größerer Aufwand .

Wie werden die Daten denn bisher zeitlich zugeordnet? Also wo speicherst du denn z.B. die Jahreszahl oder brauchst du diese nicht? Und wieviele Datensätze sind denn so ca. in der DB?

[Hansa]

Ich werde mich hüten, die DB aufzuteilen, was soll das denn nützen ? Die DB ist nicht riesig, nur so 20-30 MB. Die Frage ist nur die hier : Wie wirkt es sich letzenendes aus, wenn ich mit select * alle Felder übers Netz jage, oder nur die wirklich benötigten

Gruß
Hansa

[DataCool]

Hi,

ich glaube X-Dragon wollte die DB nicht aufteilen, sondern die Tabelle mit deinen 60 Feldern in mehere Tabellen.

Ob das Sinn macht kann man nur sagen, wenn Du Deine Tabellenstruktur preisgibst !

Data

[Hansa]

Hi,

Habe mir mal die DDL-Scripte angesehen. Bei dieser Table sind es 72 Felder, die 60 besagten, das Jahr und ein paar IDs. Ich habe aber noch eine andere, die hat 80 Spalten, wobei es in beiden Fällen noch mehr werden. Da fällt mir aber noch etwas wichtiges ein, was ist denn wenn etwas eingegeben wird. Muß Interbase dann nicht sogar überprüfen, im Falle von SELECT *, welche Felder sich geändert haben ? 8)

Wie gesagt, ich bin mir nicht ganz im Klaren, wie das ganze hinter den Kulissen aussieht. Aber ich habe schon des öfteren gelesen, man solle durch eine geschickte WHERE - Klausel den Datenverkehr gering halten. Dann habe ich mir halt gedacht daß dies auch Einfluß haben könnte, welche Felder ich mit SELECT auswähle. Wenn ich mich nicht irre wird mit WHERE nur die Menge der gelieferten Daten eingeschränkt. Was geliefert wird, das bestimmt ja SEELECT. Ansonsten verweise ich noch mal auf den allerersten Beitrag.

Gruß
Hansa

[Gollum]

Hallo hansa,

ich glaube Du machst, was SQL angehet, einen Denkfehler. In Deinem Beispiel, kann man den Umsatz für alle 12 Monate folgendermaßen erhalten:

Code:

  'SELECT Monate, Umsatz FROM Statistik '+
  'GROUP BY Monat, Umsatz '+
  'ORDER BY Monate';

Mit obigen Statement erhälst Du den Umsatz für alle 12 Monate. Die Query müsste Dir für jeden Monat einen Datensatz zurückliefern.

Generell ist es immer besser, in einem SQL-Statement nur die benötigten Felder anzugeben und nicht mit dem Jokerzeichen "*".

[Hansa]

Zitat von Gollum:

ich glaube Du machst, was SQL angeht, einen Denkfehler.

Das vermute ich auch, dafür frage ich ja.

Zitat von Gollum:

Generell ist es immer besser, in einem SQL-Statement nur die benötigten Felder anzugeben und nicht mit dem Jokerzeichen "*".

Na das ist doch mal eine Aussage Wenn Du mir vielleicht noch erzählst warum genau?

So ungefähr sieht die Struktur jedenfalls aus (am Anfang stehen noch die nötigen IDs, am Schluß gehts halt weiter so bis 12 :

[CODE]
...
MENGE1 INTEGER,
UMENGE1 INTEGER,
GES1 DECIMAL(15,2),
UMSATZ1 DECIMAL(15,2),
RG1 DECIMAL(15,2),

MENGE2 INTEGER,
UMENGE2 INTEGER,
GES2 DECIMAL(15,2),
UMSATZ2 DECIMAL(15,2),
RG2 DECIMAL(15,2),
...
[CODE]

Jetzt bräuchte ich z.B. für die Monate 1 bis 12 : UMSATZ1 bis UMSATZ12. Also nochmals : lohnt sich der nötige Aufwand gegenüber SELECT * oder sieht jemand, wie mans einfach und trotzdem effektiv besser machen kann ?

[Gollum]

Hallo,

Zitat von Hansa:

... vielleicht noch erzählst warum genau?

Performance ist besser, Datenmenge die übertragen wird, ist geringer.


zu Deiner Tabelle:
Wer hat so eine schwachsinnige Tabelle entworfen?
Die einfachste Möglichkeit besteht darin, für jeden Monat einen Datensatz, also in Deinem Fall wären das 12 Sätze. Dann kannst Du mein o.g. Statement anwenden.

[Hansa]

Zitat von Gollum:

Performance ist besser, Datenmenge die übertragen wird, ist geringer.

Also doch ungefähr so, wie ich mirs gedacht habe.

Zitat von Gollum:

zu Deiner Tabelle:
Wer hat so eine schwachsinnige Tabelle entworfen?

Das wird nicht verraten. Aber ich glaube ich weiß, warum ich das so gemacht habe:

Code:

   
    ID          INTEGER NOT NULL,
    ID_KUNR     INTEGER,
    ID_ARTNR    INTEGER,
    ID_WGNR     INTEGER,
    ID_KGNR     INTEGER,
    ID_PERSNR   INTEGER,
    ID_FAHRZNR  INTEGER,
    STATMODUS   CHAR(1),
    JAHR        CHAR(4),
    GRATIS      CHAR(1),
    RUECKNAHME  CHAR(1),

Das steht am Anfang. Erstens hab ich mirs vielleicht nicht richtig überlegt, aber daß ich die DB mehrmals umbauen muß war mir von Anfang an klar. Außerdem bin ich noch nicht lange an SQL dran und habe mir ALLES selber beigebracht, höchstens mit Hilfe von solch einem Forum. Vor allem wollte ich keine 12 Tables, da müßte ich obiges in allen 12 mitwschleppen. Lasse mich aber gerne eines besseren belehren, mir fehlen halt Erfahrungswerte. Deshalb war die erste Arbeit, Konvertierungsprogramme für die ganzen alten Daten zu schreiben und nur mit Originaldaten zu arbeiten. Uff, das war schon schwierig genug. Also, weer Verbesserungsvorschläge hat, nur her damit.

[Sharky]

Hai Hansa,

hihi.... so hat meine erste Datenbank bzw. Tabelle auch ausgesehen.
"Alles" in einer Tabelle. Aber mit der Zeit merkte ich das dies nicht so glücklich ist.

Ein SELECT * FROM tabelle ist natürlich Okay wenn ich:

a) ALLE Felder brauche
b) ich nur wenige und "kleine" Felder in der Tabelle habe

Ich habe z.B. In der Kunden-Tabelle ein Memofeld. Dies brauche ich aber nicht im Grid um den Kunden anzuzeigen. Dort brauche ich nur Name, PLZ und Ort.

Also habe ich ein Query für das Grid: SELECT k_id,k_name,k_plz,k_ort FROM kunden ORDER BY r_name Erst wenn der Anwender eine Adresse bearbeiten möchte hole ich mit einem zweiten Query die gesamten Daten:
SELECT * FROM kunden WHERE k_id = query1.k_id ACHTUNG. Die SQL-Stings werden natürlich im Programm zusammengesetzt

Das aufteilen auf mehrere Tabelle macht sehr viel Sinn.
Ich habe z.B. Auch die Umsätze der Kunden in einer extra Tabelle.
Wenn ich jetzt den Gesamtumsatz eines Kunden für ein Jahr möchte sage ich dem SQL-Server:

 SELECT SUM (umsatz] AS gesamtumsatz FROM kunden_umsatz WHERE (jahr = 2002) AND (k_id = 122) Jetzt liefert mir der SQL-Server exakt einen Wert zurück.
Und dadurch wird das Netzwerk natürlich entlastet.

So, das nur mal so als denkanstoss.