|
|
|
|
| Zitat von -Marvin-
| Zitat von Ashtray
| Zitat von Noch_ein_Kamel
select a.foo from bla as a join ...?
| |
das will ich eben nicht weil dann alle querys ohne ende aufgeblasen werden. ich brauch nicht 2-3 Daten sondern eher 20 oder so
| |
dann musst du eindeutige spaltennamen vergeben..
| |
|
|
|
|
|
|
|
| Zitat von Ashtray
| Zitat von -Marvin-
| Zitat von Ashtray
| Zitat von Noch_ein_Kamel
select a.foo from bla as a join ...?
| |
das will ich eben nicht weil dann alle querys ohne ende aufgeblasen werden. ich brauch nicht 2-3 Daten sondern eher 20 oder so
| |
dann musst du eindeutige spaltennamen vergeben..
| |
| |
brauchst du denn wirklich alle spalten?
|
|
|
|
|
|
|
Besser die Querys aufblasen, als die Results aufblasen.
|
|
|
|
|
|
|
Ich möchte nicht alle querys anpacken müssen nur weil ich mal eine nicht brauch und einmal ne andere nicht
|
|
|
|
|
|
|
| Zitat von Ashtray
SELECT * FROM `videos` JOIN `users` ON `videos`.`userid` = `users`.`userid`
Aber: In beiden tabellen gibt es `date` und ich will das date von `videos`, bekomme aber das von `users`
| |
SELECT `videos`.*, `users`.* [...]
Ich formulier sowas aber lieber als impliziten Equijoin:
SELECT `videos`.*, `users`.* FROM `videos`, `users` WHERE `videos`.`userid` = `users`.`userid`
Geschmackssache.
|
|
|
|
|
|
|
Na, da haste beim Tabellen Design verkackt
Ein User braucht kein "date". Der hat vielleicht ein "registered" oder "last_login".
Genauso braucht eigentlich ein Video auch kein Date. Sondern eher sowas wie "edited", "uploaded" oder "last_seen"
Ansonsten geht natürlich "SELECT v.*, u.* FROM videos v JOIN users u ON u.id = v.id" grundsätzlich schon. Man muss sich aber darüber im klaren sein, dass dinge wie fetchObject() natürlich in die Namensfalle tappen. Ein fetchArray() hingegen vollkommen unbeeindruckt ist. Dein Result aber beim verschieben von Spalten komplett anders ausfallen wird
|
|
|
|
|
|
|
| Zitat von [Dicope]
| Zitat von Ashtray
SELECT * FROM `videos` JOIN `users` ON `videos`.`userid` = `users`.`userid`
Aber: In beiden tabellen gibt es `date` und ich will das date von `videos`, bekomme aber das von `users`
| |
SELECT `videos`.*, `users`.* [...]
Ich formulier sowas aber lieber als impliziten Equijoin:
SELECT `videos`.*, `users`.* FROM `videos`, `users` WHERE `videos`.`userid` = `users`.`userid`
Geschmackssache.
| |
Ist das nicht eh nur ein Feature von MySQL und wird intern eh zu nem Join umgebaut? Oder Irre ich da jetzt?
|
|
|
|
|
|
|
| Zitat von [Dicope]
(...)
Ich formulier sowas aber lieber als impliziten Equijoin:
SELECT `videos`.*, `users`.* FROM `videos`, `users` WHERE `videos`.`userid` = `users`.`userid`
Geschmackssache.
| |
Letztere Variante finde ich hässlich, weil die Joins mit den Bedingungen vermixt werden.
|
|
|
|
|
|
|
| Zitat von GH@NDI
Na, da haste beim Tabellen Design verkackt
[...]
| |
Mein Vorgänger bitteschön!
|
|
|
|
|
|
|
alternativ
select *, a.foo as afoo, b.foo as bfoo ...
aber da musste auch den query anfassen und halt die problematischen spalten eintragen und hast im ergebniss nen überflüssiges foo ;P
|
|
|
|
|
|
|
| Zitat von SirSiggi
Besser die Querys aufblasen, als die Results aufblasen.
| |
Kommt drauf an. (Yay. Die Topantwort um Zeit zu schinden.)
Letzlich kommt es insbesondere auf die Art der Selektion an. Wenn du zig Joins, Sorts, Gruppierungen, ... hast, gibt eine Projektion natürlich Sinn, weil im Baum ganz nach unten gezogen wird. Wenn du aber nur anhand eines einzigen Attributs selektierst und die Tabelle hoffentlich sogar einen Index auf dieses Attribut hat, ist ein Performancegewinn bei normalen Tupelgrößen zu vernachlässigen - insbesondere wenn du dadurch den Vorteil hast, eben nicht jede Spalte persönlich zu benennen.
|
|
|
|
|
|
|
| Zitat von GH@NDI
| Zitat von [Dicope]
| Zitat von Ashtray
SELECT * FROM `videos` JOIN `users` ON `videos`.`userid` = `users`.`userid`
Aber: In beiden tabellen gibt es `date` und ich will das date von `videos`, bekomme aber das von `users`
| |
SELECT `videos`.*, `users`.* [...]
Ich formulier sowas aber lieber als impliziten Equijoin:
SELECT `videos`.*, `users`.* FROM `videos`, `users` WHERE `videos`.`userid` = `users`.`userid`
Geschmackssache.
| |
Ist das nicht eh nur ein Feature von MySQL und wird intern eh zu nem Join umgebaut? Oder Irre ich da jetzt?
| |
du irrst nicht..
|
|
|
|
|
|
|
| Zitat von [Dicope]
| Zitat von SirSiggi
Besser die Querys aufblasen, als die Results aufblasen.
| |
Kommt drauf an. (Yay. Die Topantwort um Zeit zu schinden.)
Letzlich kommt es insbesondere auf die Art der Selektion an. Wenn du zig Joins, Sorts, Gruppierungen, ... hast, gibt eine Projektion natürlich Sinn, weil im Baum ganz nach unten gezogen wird. Wenn du aber nur anhand eines einzigen Attributs selektierst und die Tabelle hoffentlich sogar einen Index auf dieses Attribut hat, ist ein Performancegewinn bei normalen Tupelgrößen zu vernachlässigen - insbesondere wenn du dadurch den Vorteil hast, eben nicht jede Spalte persönlich zu benennen.
| |
also, ich glaube kaum, das da irgendwas indiziert ist, so wie ich das bis jetzt hier verstehe
|
|
|
|
|
|
|
| Zitat von -Marvin-
| Zitat von GH@NDI
Ist das nicht eh nur ein Feature von MySQL und wird intern eh zu nem Join umgebaut? Oder Irre ich da jetzt?
| |
du irrst nicht..
| |
Die Doku sagt:
|
The FROM table_references clause indicates the table or tables from which to retrieve rows. If you name more than one table, you are performing a join. For information on join syntax, see Section 12.2.8.1, “JOIN Syntax”. For each table specified, you can optionally specify an alias.
| |
Gut, es wird wohl nicht umgemoddelt, aber ist halt ne alternative Syntax für einen impliziten JOIN (Yeah, gut rausgeredet )
|
|
|
|
|
|
|
| Zitat von GH@NDI
| Zitat von [Dicope]
| Zitat von Ashtray
SELECT * FROM `videos` JOIN `users` ON `videos`.`userid` = `users`.`userid`
Aber: In beiden tabellen gibt es `date` und ich will das date von `videos`, bekomme aber das von `users`
| |
SELECT `videos`.*, `users`.* [...]
Ich formulier sowas aber lieber als impliziten Equijoin:
SELECT `videos`.*, `users`.* FROM `videos`, `users` WHERE `videos`.`userid` = `users`.`userid`
Geschmackssache.
| |
Ist das nicht eh nur ein Feature von MySQL und wird intern eh zu nem Join umgebaut? Oder Irre ich da jetzt?
| |
Nein. Das ist ein kartesisches Produkt aus dem du alles rausziehst, wo die Joinbedingung nicht stimmt. Das sollte eigentlich von jeder Datenbank so optimiert werden, dass es eben nicht erst das kartesische Produkt bildet. Die explizite Equijoin-Semantik (INNER JOIN) gibts soweit ich weiß erst seit SQL92.
|
|
|
|
|
|
|
| Zitat von Ashtray
| Zitat von GH@NDI
Na, da haste beim Tabellen Design verkackt
[...]
| |
Mein Vorgänger bitteschön!
| |
verkackt isses trotzdem..
|
|
|
|
|
|
|
| Zitat von Ashtray
| Zitat von GH@NDI
Na, da haste beim Tabellen Design verkackt
[...]
| |
Mein Vorgänger bitteschön!
| |
Dann halt der! Paddel ihn rückwirkend!
Ich hab ja schon immer einen Bogen um Namen wie "date" gemacht, weil es mich zwingt die ollen Hochkomatas (`) zu benutzen, damit der SQL-Parser nicht über den Datentyp stolpert sondern meine Spalte genommen hat
|
|
|
|
|
|
|
| Zitat von [Dicope]
| Zitat von GH@NDI
| Zitat von [Dicope]
| Zitat von Ashtray
SELECT * FROM `videos` JOIN `users` ON `videos`.`userid` = `users`.`userid`
Aber: In beiden tabellen gibt es `date` und ich will das date von `videos`, bekomme aber das von `users`
| |
SELECT `videos`.*, `users`.* [...]
Ich formulier sowas aber lieber als impliziten Equijoin:
SELECT `videos`.*, `users`.* FROM `videos`, `users` WHERE `videos`.`userid` = `users`.`userid`
Geschmackssache.
| |
Ist das nicht eh nur ein Feature von MySQL und wird intern eh zu nem Join umgebaut? Oder Irre ich da jetzt?
| |
Nein. Das ist ein kartesisches Produkt aus dem du alles rausziehst, wo die Joinbedingung nicht stimmt. Das sollte eigentlich von jeder Datenbank so optimiert werden, dass es eben nicht erst das kartesische Produkt bildet. Die explizite Equijoin-Semantik (INNER JOIN) gibts soweit ich weiß erst seit SQL92.
| |
okay, dann haben wir uns beide geirrt ghandi
|
|
|
|
|
|
|
Der Paragraphenreiter wieder
Marvin: *ShakeHands*
|
|
|
|
|
|
|
| Zitat von GH@NDI
Der Paragraphenreiter wieder
Marvin: *ShakeHands*
| |
vor allem faengt er um die uhrzeit auch noch mit kartesichem produkt und so nem scheiss an.. ich glaub's hakt..
|
|
|
|
|
|
|
| Zitat von Ashtray
| Zitat von GH@NDI
Na, da haste beim Tabellen Design verkackt
[...]
| |
Mein Vorgänger bitteschön!
| |
Bei der Arbeit hat man nichts mit Videos und Usern zu tun, privat kannst du schlecht der Vorgänger sein, es sei denn es ist für deine Freundin. Da du aber schon mit Verlobung ankommst, wirst du wahrscheinlich schon vor langer Zeit alle ihre Datenbank auf den neusten Stand gebracht haben (hätte ich auch als erstes gemacht).
Bleibt also nur die Lets-Play Geschichte, richtig?
|
|
|
|
|
|
|
Da gabs doch mal so ne Initiative...
Yay! \o/
|
|
|
|
|
|
|
Da würd ich auch joinen.
|
|
|
|
|
|
|
Kennt sich wer mit nUnit aus?
Muss das Projekt erst kompilieren, bevor ichs in nUnit bekomme?
|
|
|
|
|
|
|
i'm in..
|
|
|
|
|
|
|
| Zitat von -Marvin-
| Zitat von GH@NDI
Der Paragraphenreiter wieder
Marvin: *ShakeHands*
| |
vor allem faengt er um die uhrzeit auch noch mit kartesichem produkt und so nem scheiss an.. ich glaub's hakt..
| |
Ach... Joins in relationalen Datenbanken machen doch gar keinen Spaß. Multi-Dimensional Partitioned Join auf Map-Reduce-Basis für den Gewinn.
|
|
|
|
|
|
|
is ja gut jetzt..
|
|
|
|
|
|
|
wobei, das andere titten bild besser war also realistischer
|
|
|
|
|
|
|
Hey - ich muss gerade verkackte theoretische Informatik lernen. Ich freu mich doch, wenn ich an anderer Stelle mal nützliche Sachen anbringen kann...
|
|
|
|
|
|
|
Ich finds schön dass ihr euch so mit dem Problem beschäftigt, morgen hab ichs dann vielleicht auch nochmal gelesen und vielleicht auch verstanden
e: Gut kombiniert Senseo!
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Ashtray am 28.01.2010 22:20]
|
|
|
|
|
Thema: Gehirnsalat ( wir unter uns ) |