Muistan sen hyvin. Pitkä yö käytetty yrittää selvittää, miten parhaiten vastaa käyttötiedot jopa vierekkäin. Klo käyttävät yrittää selvittää, jos se on enemmän työtä vain luomalla olet oma looginen taulukko ratkaista tuo typerä rajat liittyä ongelma, joka ei mene pois. Olen haluton kuulemaan Microstrategy www-sivuston, koska se todellakin vain tuntuu olen copping ulos ...
Jos sinulla on staattinen varastoon, että suunnittelijat ovat sitoutuneet, mitä muuta on teidän vaihtoehto?
Late night ..
Lisäys: Tiedätkö joskus unohtaa, että SQL optimointi on vain, että ... optimointiehdotuksen. Voin aikaa koota laatu kysely, joka menee palauttamaan tietoja tiettyjen tuotteiden aluksia ja palauttaa. Oletetaan, että jokainen näistä tuotteista on eri tapa seurata. Voisin heittää yhteen käsin tehty kysely, että populates luettelo näiden erityisten viitenumeroita alukselta taulukosta siten, että voin jättää liittyä vastaan merenkulun tiedot, jotta voin nähdä erityistä palauttaa vastaan tiettyjä aluksia, ja sen jälkeen yhteensä näitä ratkaisuja, mutta näet, mitä tein? Kävin läpi ongelmia vastaavien tuhansia kirjaa toisiaan vastaan ... ja mitä? Niin että voin myöhemmin yhdistää tietoja jonkinlaisen ryhmän.
Anna SQL Optimization. Ratkaisee ongelman nopeampi tapa, että en luultavasti ole ylittäneet mieleeni, koska se toimii lineaarisesti.
- Get aluksia.
- Get palaa.
- Vasen Liity alusten tuoton perusteella yksilöllinen tunnus.
- Count kirjaa asiaa sarakkeessa.
- Ryhmän tarvittavat tuotteet.
Mutta ... Miksi tieto on tarpeen?
Microstrategy korjauksia.
(
Valitse a12.date,
count (a11.sales_number) SALES_COUNT
myynnistä A11
jossa (a11.item_desc = "widget")
ryhmän
a11.date
) PA11
koko ulompi Liity
(
Valitse a11.date,
count (a11.rma_number) RMA_COUNT
alkaen RMA A11)
jossa (a11.item_desc = "widget")
ryhmän
a11.date
) PA12
päällä
(pa11.date = pa12.date)
Paljon järkevämpää. Miksi liittyä alussa, kun kaikki välität on yhteensä ... Liity on yhteensä!
RYDW.
Notes from asennus
Viimeaikainen kommentit