nicht angemeldet
2 Tabellen verbinden?
suitHallo,
wie kann ich 2 Tabellen gleicher Struktur miteinander verbinden.
Also, es geht darum, dass ich eine Artikeltabelle habe, in die ab und an neue Artikel eingespielt werden.
Deshalb möchte ich die einzuspielenden Artikel in eine temporäre 2. Tabelle einspielen, dann kontrollieren und hiernach die komplette Tabelle 2 an die Tabelle 1 anhängen.
Gibt es dafür einen besonders performanten Kniff?
VG, Fred
-
Deshalb möchte ich die einzuspielenden Artikel in eine temporäre 2. Tabelle einspielen, dann kontrollieren und hiernach die komplette Tabelle 2 an die Tabelle 1 anhängen.
INSERT INTO
tabelle1SELECTfield1,field2FROMtabelle2Gibt es dafür einen besonders performanten Kniff?
An der Performance wirst du imho nicht groß drehen können.
Gruß,
jumini-
Deshalb möchte ich die einzuspielenden Artikel in eine temporäre 2. Tabelle einspielen, dann kontrollieren und hiernach die komplette Tabelle 2 an die Tabelle 1 anhängen.
INSERT INTO
tabelle1SELECTfield1,field2FROMtabelle2Hi jumini,
geht auch SELECT * FROM tabelle2 ?
Danke und Grüße, Fred
-
geht auch SELECT * FROM tabelle2 ?
SELECT INTO wäre auch denkbar - es kommt auf das DMBS an.
-
SELECT INTO wäre auch denkbar - es kommt auf das DMBS an.
MySQL 5
Gruß, Fred
-
-
geht auch SELECT * FROM tabelle2 ?
Sofern die Felder wirklich identisch sind, sehe ich da kein Problem. Aber nur ein Test beweist dir, dass ich nicht lüge ;)
Gruß,
jumini
-
-
-
Gibt es dafür einen besonders performanten Kniff?
Man packt alles in eine Tabelle und verpasst den noch zu kontrollierenden Artikeln ein Flag welches man bei bedarf nur ändern muss - ob das nun Artikel im Sinne eines Shops sind oder Artikel im Sinne eines CMS/Blog oder wie auch immer spielt dabei keine Rolle.
-
»»» Gibt es dafür einen besonders performanten Kniff?
Man packt alles in eine Tabelle und verpasst den noch zu kontrollierenden Artikeln ein Flag welches man bei bedarf nur ändern muss - ob das nun Artikel im Sinne eines Shops sind oder Artikel im Sinne eines CMS/Blog oder wie auch immer spielt dabei keine Rolle.
Das ist aber nicht performanter, sondern Benutzerfreundlicher. Für die Performance der Abfragen sind kleine Tabellen ausschlaggebend. Ich behaupte jetzt einfach mal, dass die seltenen Übertragungen der Tabelle eine unverhältnismäßig kleinere Rechenzeit in Anspruch nimmt und möchte Friedhelm dazu raten, bei zwei Tabellen zu bleiben - egal ob es nun um ein kleines News-Archiv geht, oder riesige Artikel-Tabellen.
Gruß
jumini-
»»» Gibt es dafür einen besonders performanten Kniff?
Man packt alles in eine Tabelle und verpasst den noch zu kontrollierenden Artikeln ein Flag welches man bei bedarf nur ändern muss - ob das nun Artikel im Sinne eines Shops sind oder Artikel im Sinne eines CMS/Blog oder wie auch immer spielt dabei keine Rolle.
Das ist aber nicht performanter, sondern Benutzerfreundlicher.
Zwei Tabellen die redundanzen zueinander erzeugen sollen performanter sein?
Für die Performance der Abfragen sind kleine Tabellen ausschlaggebend.
Oder ein ordentlicher Index - das spielt keine Rolle, ob das jetzt 1000 oder 10 Millionen Datensätze sind, wir reden hier von Millisekunden.
-
Zwei Tabellen die redundanzen zueinander erzeugen sollen performanter sein?
Wieso Redundanzen? Die Daten in der anderen Tabelle unterscheiden sich doch.
Es sollen ja unveröffentlichte Inhalte vor veröffentlichung gespeichert werden, die im produktiven Betrieb noch nicht benötigt werden = weniger Daten.OT: wo ist denn hier der Login-Button? Habe mich registriert, aber das Cookie wohl aufgegessen.
Gruß,
jumini-
Zwei Tabellen die redundanzen zueinander erzeugen sollen performanter sein?
Wieso Redundanzen? Die Daten in der anderen Tabelle unterscheiden sich doch.
Die Datenstruktur ist redundant - und nachdem die Daten von einer in die Andere kopieren werden (bis jetzt reden wir nicht von verschieben) werden danach auch Redundanzen in den Daten erzeugt.
Es sollen ja unveröffentlichte Inhalte vor veröffentlichung gespeichert werden, die im produktiven Betrieb noch nicht benötigt werden = weniger Daten.
Schon klar - aber dennoch sind es dieselben Daten die sich genau durch ein Kriterium unterschieden welches in keinster Weise eine weitere Tabelle rechtfertigt.
OT: wo ist denn hier der Login-Button? Habe mich registriert, aber das Cookie wohl aufgegessen.
Einfach den Pfad /my/ aufrufen.
-
Die Datenstruktur ist redundant - und nachdem die Daten von einer in die Andere kopieren werden (bis jetzt reden wir nicht von verschieben) werden danach auch Redundanzen in den Daten erzeugt.
nein, sorry. Ich würde die 2 Tabelle nach dem kopieren leeren. Also ist verschieben gemeint.
Es sollen ja unveröffentlichte Inhalte vor veröffentlichung gespeichert werden, die im produktiven Betrieb noch nicht benötigt werden = weniger Daten.
Absolut perfekt erkannt von jumini.
Schon klar - aber dennoch sind es dieselben Daten die sich genau durch ein Kriterium unterschieden welches in keinster Weise eine weitere Tabelle rechtfertigt.
Auch mal klugscheißen will: Von "kein" gibt es keinen Superlativ ;-) (Sorry, der mußte jetzt sein)
Grüße, Fred
-
Es sollen ja unveröffentlichte Inhalte vor veröffentlichung gespeichert werden, die im produktiven Betrieb noch nicht benötigt werden = weniger Daten.
Absolut perfekt erkannt von jumini.
Diese Erkennnis ist wie schon erwähnt sehr bläuäugig da es für das DBMS vermutlich sogar Ressourcenintensiver ist Indizes für mehrere Tabellen zu erhalten als für eine.
Schon klar - aber dennoch sind es dieselben Daten die sich genau durch ein Kriterium unterschieden welches in keinster Weise eine weitere Tabelle rechtfertigt.
Auch mal klugscheißen will: Von "kein" gibt es keinen Superlativ ;-) (Sorry, der mußte jetzt sein)
Wer sagt das? Sick? Der Typ hat doch nicht mehr alle Beisammen :)
"keinster" wird hier als Adverb und nicht als Indefinitpronomen verwandt und kann darum imo auch gesteigert werden :p
-
Diese Erkennnis ist wie schon erwähnt sehr bläuäugig da es für das DBMS vermutlich sogar Ressourcenintensiver ist Indizes für mehrere Tabellen zu erhalten als für eine.
Und genau dein *vermutlich* ist der Knackpunkt.
Es kommt schlichtweg auf die anderen Abfragen der primären Tabelle an.
Sofern diese so wenig Datensätze wie möglich erfordern, (z.B. weil es sich dabei um besonderst komplexe, tabellenübergreifende Abfragen handelt) bietet sich eine Aufteilung an.Gruß,
jumini-
Und genau dein *vermutlich* ist der Knackpunkt.
Es kommt schlichtweg auf die anderen Abfragen der primären Tabelle an.
Sofern diese so wenig Datensätze wie möglich erfordern, (z.B. weil es sich dabei um besonderst komplexe, tabellenübergreifende Abfragen handelt) bietet sich eine Aufteilung an.Es geht doch eh nur um die temporäre Aufteilung.
D.h. ich mache den Testlauf und die Kontrolle in Tabelle 2 und danach spile ich T2 komplett in T1 ein.
Grüße, Fred
-
-
-
-
-
-
-
-