![]() |
Select * from
Es geht mir hier um den Netzwerk-Traffic.
Code:
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.
SELECT * FROM STATISTIK....
Jetzt könnte ich ja schreiben
Code:
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 :?:
SELECT UMSATZ1,.......UMSATZ12 FROM...
Gruß Hansa |
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? |
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 |
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 |
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 |
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:
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.
'SELECT Monate, Umsatz FROM Statistik '+
'GROUP BY Monat, Umsatz '+ 'ORDER BY Monate'; Generell ist es immer besser, in einem SQL-Statement nur die benötigten Felder anzugeben und nicht mit dem Jokerzeichen "*". |
Zitat:
Zitat:
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 ? |
Hallo,
Zitat:
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. |
Zitat:
Zitat:
Code:
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.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), |
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
SQL-Code:
ist natürlich Okay wenn ich:
SELECT * FROM tabelle
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:
SQL-Code:
Erst wenn der Anwender eine Adresse bearbeiten möchte hole ich mit einem zweiten Query die gesamten Daten:
SELECT k_id,k_name,k_plz,k_ort FROM kunden ORDER BY r_name
SQL-Code:
ACHTUNG. Die SQL-Stings werden natürlich im Programm zusammengesetzt
SELECT * FROM kunden WHERE k_id = query1.k_id
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:
SQL-Code:
Jetzt liefert mir der SQL-Server exakt einen Wert zurück.
SELECT SUM (umsatz] AS gesamtumsatz FROM kunden_umsatz WHERE (jahr = 2002) AND (k_id = 122)
Und dadurch wird das Netzwerk natürlich entlastet. So, das nur mal so als denkanstoss. :lol: |
Alle Zeitangaben in WEZ +1. Es ist jetzt 18:40 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz