SELECT ... INTO [Table] mit Primärschlüssel

[süden]

Hallo,
mein Programm muß SQL-Server und Access unterstützen.
Deshalb alle SQL's im Programm (später vielleicht mal differenzierter).

Ich möchte eine temporäre Tabelle erstellen, damit das SQL Statement nicht zu kompliziert wird.

Code:

sqlText := 'SELECT x,y INTO [tempTabelle]

Die Anzahl der Datensätze von 100 - 500.000
Die Performance der tempTable ist grausam, ich denke weil sie keinen Index hat.

Fragen:
Gibt es eine Möglichkeit direkt einen Index zu erstellen? Oder muß ich den hinterher in die tempTable einbauen?

Oder ist ein Create Table mit Autowertspalte und Index + anschließender Einfüge- SQL besser?

(Habe ich mich verständlich ausgedrückt? Ich bin etwas im Stress)

[Bernhard Geyer]

Ich habe das Problem von zu komplexen SQL-Statements immer mit Views gelöst.

[jobo]

Die Syntax Deines Statements ist etwas merkwürdig. Woher sollen den die Werte kommen?
Select mit Insert into sollte ungefähr so aussehen:

Code:

INSERT INTO <tempTABLE>
  (UsedCol1, UsedCol2)
SELECT NeededCol1, NeededCol2
  FROM liveTABLE
 [WHERE condition]

Du hast keine Where Bedingung, die die Daten aus der Quelltabelle einschränken würde. Also macht ein Index überhaupt keinen Sinn (auf der Quelltabelle). Bei einem Masseninsert (sowas ist es ja) ist jeglicher Index auf der Zieltabelle eine Bremse, auch der Primärschlüssel bzw dessen Index. (die man meist in Kauf nimmt).

Also ist das Insert-Statement wirklich richtig hier her kopiert oder hast Du das anonymisiert?

P.S.: hab nicht richtig aufgepasst, eine Temp Table wird natürlich on the fly erzeugt und die Syntax kann vereinfacht werden. Ein "From" sollte im Select trotzdem drin stehen.

P.S.2: Ich geh mal davon aus, Du meinst die Performanceprobleme beim Erstellen der Temp Table.

[süden]

Ich hatte die SQL etwas abgekürzt - das war natürlich mißverständlich.

Code:

SELECT x,y FROM TableQ into TableZ

Das Abrufen von 50.000 Datenzeilen (zur Kontrolle) aus TableZ ist langwierig.

[Furtbichler]

Die Syntax ist 'select * into TempTable from OtherTableOrView'.

Temporäre Tabellen in MSSQL sind -glaube ich- etwas anderes als in Access. Bei MSSQL beginnt eine temporäre Tabelle mit einem '#' und existiert nur innerhalb der Session. Soweit ich das sehe, existiert das in Access so nicht. Also würdest Du eine permanente Hilfstabelle erstellen, um zu beiden Welten kompatibel zu sein.

Ich habe mehrere Fragen:
1. Warum muss es Access sein? Ginge auch SQL-Compact oder eine lokale SQL-Express Installation?
2. Wie sehen die Queries aus? Weshalb sind sie so komplex?

Ich persönlich würde nicht versuchen, über ein SQL-Statement beide Welten zu bedienen. Versuche lieber, die Stärken beider Welten individuell auszunutzen sowie die Schwächen zu kaschieren. Während Du mit SQL-Server sehr mächtige Werkzeuge hast (hier würde ich anstatt einer temporären Tabelle vielleicht ein CTE oder eben eine View verwenden), musst Du bei Access die Aktionen vielleicht in-Memory durchführen, weil Access-SQL nicht so viele Möglichkeiten bietet und -soweit ich mich erinnere- etwas eigen ist.

[süden]

Zitat:

Ich habe mehrere Fragen:
1. Warum muss es Access sein? Ginge auch SQL-Compact oder eine lokale SQL-Express Installation?
2. Wie sehen die Queries aus? Weshalb sind sie so komplex?

zu 1)
Die ewig alte Diskussion. Wir Entwickler sind nicht allein. Was die Kunden wünschen, bekommen sie. Meine Kunden sind Architektur und Ingenieubüros; die sind sehr beständig und arbeiten z.T. noch mit DOS Programmen. Im Prinzip finde ich es gut, was läuft das läuft wenns genügt.

Access ist Tradition, vertraut, bekannt. Und ich finde - im Rahmen - ganz gut. Aber nicht meine Wahl sondern die der Kunden. Es laufen noch alte Programme mir Access.
Ich versuche den Umstieg näher zu bringen über SQL-Server. Das ist auch bekannt, viele haben Respekt vor ihm und trauen sich nicht ran. Ich leiste Überzeugungsarbeit und seit den Express-Verionen gelingt es immer besser.

zu 2)
Die Queries sind dazu da, eine Art Controlling zu bringen.
Das heißt, aus vielen Tabellen werden Zusammenfassungen erstellt, und zusätzlich noch Berechnungen (MwSt,wenn-dann-Szenarien usw.).
Die Queries hier vorzustellen würde zu weit führen.

[süden]

Nachtrag:

Zitat:

Die Syntax ist 'select * into TempTable from OtherTableOrView'.

Wieso funktioniert dann meine Syntax?
SELECT x,y FROM TableQ into TableZ

[süden]

Ne, quatsch, ich nehme alles zurück.
Vielleicht sollte ich Sylvester nicht arbeitet.

[Furtbichler]

Danke für die Antworten. Das hatte ich mir schon gedacht bzw. befürchtet. Aber es hätte idealerweise sein können, das Du die besseren Alternativen nicht auf dem Schirm hattest. Mist. Also muss man eben so klar kommen.

Die Queries sind also -würde ich mal behaupten- "Business Intelligence", wofür Du eh ein Datawarehouse aufmachen solltest. Die Anfragen an so ein DWH sind viel einfacher zu gestalten, da die Hauptarbeit über ETL-Prozesse bereits erledigt wurde. Im Grunde genommen ist so ein DWH einfach eine Ansammlung von Fakten-Tabellen mit wenigen FK-Ebenen=> Star-Design vs. Snowflake-Design). Die Fakten sind mit Dimensionstabellen verknüpft, über die sich standardisierte Gruppierungen (Tag=>Woche=>Monat=>Quartal=>Jahr, Kunde=>PLZ-Bereich=>Stadt=>Bundesland=>Land etc.) sehr einfach erstellen lassen. Und diese 'Fakten-Tabellen' enthalten jeweils Rohdaten für einen bestimmten Themenkomplex. So kann man z.B. eine (Fakten-)Tabelle 'Umsatz' erstellen, in dem einfach für jeden Kunden jede Einzelposition mit Datum und allem drum und drann aufgelistet ist. Eine weitere Tabelle 'Lager' enthält alle Lagerbewegungen.

Ziel dieser Faktentabellen ist es natürlich, alle verfügbaren Informationen zusammenzutragen und in einer einzigen Tabelle verfügbar zu machen. Man muss dann also nicht mehr für die Beantwortung einer Frage von hinten durch die Brust ins Auge und linksseitig die Hand hinterm Rücken über die Schulter die Tabellen in Hilfstabellen kummulieren, verknüpfen und verknurpsen, nur um blöde Umsatzstatistiken zu erzeugen.

Was Du versuchst, ist imho einfach schwer wartbar, da die Queries zu komplex werden (behaupte ich mal) und schlecht zu entwanzen und zu erweitern sind. Es ist einfach 'old school' (was nicht per se schlecht ist) aus einem Produktivsystem heraus komplexe Fragen beantworten zu wollen. Mehr noch: Es ist extrem ineffektiv, denn Du brichst Dir fürchterlich einen ab, um wieder eine neue Query zu bauen. Ich weiß, wovon ich rede: Ich hab den gleichen Mist fast 20 Jahre gemacht, bis ich mich endlich mit dem Thema 'DWH/BI' auseinandergesetzt habe. Seitdem mach ich mir lieber die Mühe, ein DWH aufzusetzen (und zwar mit Hausmitteln, d.h. kein BI-Service), das reicht mir vollkommen.

In deinem Fall können die Kunden mit Access, SQL-Server, Oracle, MySQL, äh.. Textdateien oder XML arbeiten. Du sorgst dafür, das deren Daten in ein einziges Format (z.B. auf einem SQL-Server) überführt werden (ETL). So und auf *dem* kannst Du dich austoben, *ohne* auf die individuellen, veralteten und schwachbrüstigen Datenbanken der Kunden eingehen zu müssen. Damit lassen sich auch heterogene Datenquellen elegant zusammenführen: Wenn eine Filiale mit Access arbeitet, aber die andere blöderweise mit der DBase-Lösung vom Sohn des GF und die dritte mit mySQL, weil der Webshop kein Access kann, dann führt man diese drei Filialdaten über ETL-Prozesse (1x täglich, alle 5 Minuten, in Echtzeit, egal) in ein DWH zusammen und macht seine Erhebungen bequem aus der Liege am Strand mit seinem Tablet.

Nebenbei sind Abfragen in einem DWH hochperformant, d.h. das Warten auf Daten gehört der Vergangenheit an.

[süden]

OK, ich frag nach was einfachem, sitz hier an einer kleinen Funktion ...

... und dann plötzlich ====>>>>> ein neues Universum.

ABER DU HAST RECHT!
Jetzt holt mich wieder ein, was ich lange vor mir hin geschoben habe.

Danke