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

[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