In SQL Server 2005, we can create temp tables one of two ways:
declare @tmp table (Col1 int, Col2 int);
create table #tmp (Col1 int, Col2 int);
What are the differences between the two? I have read conflicting opinions on whether @tmp still uses tempdb, or if everything happens in memor...
I work remotely and have 44GB of media files that I need to send back to my office. There are lots of free services out there that can handle up to 2GB, but I haven't seen talk of anything larger.
We both have 50mbps+ connections, so I would rather not mail physical media (though, that is an op...
well, it also helps if i practice some reading comprehension
you said move answer to comment (not vice versa)
Get them to sort out the firewall timeouts then. I'm not a big fan of writing nasty workaround SQL (and increasing remote DB roundtrips as a result) because of infrastructure issues. Sorry to be blunt! — Phil5 hours ago
Alex said "The infrastructure thing is i think i'm affraid is out of the question for this matter :) ill have to do the best with what i have :) sad but true" in a comment - therefore Rainier's answer was "Not an answer" in my book
basically the 'always' field only has two possible options (true or false). when choosing an index, you want to be discard as many entries as possible. I guess MySQL thought that if you can't discard 95% of the rows, it's not worth it :)
@MarkStoreySmith This is where it throws me. I need hard-and-fast rules. Read through use-the-index-luke.com and thought that I had a good idea and then thhhpppptttttt something changes and makes a large exception. Something along the lines of "I before E except after C and sounding in A as in Neighbor and Weigh ... and also weird because weird is weird."
A friend told me that in his first position, his responsibility was dealing and cleaning a lrage amount of MS-Access databases. All had been created by the previous No#2 (CEO?). All tables had names: George1, George2, ... GeorgeN and all columns were column1, column2, ... (guess who was named George :)
SELECT * FROM
(SELECT movies.* FROM movies JOIN showtimes ON movies.id = showtimes.movie WHERE showdate >= '2012-4-11' AND showdate < '2012-04-18') UNION
(SELECT * FROM movies WHERE always = 'true')
) AS movies
WHERE site = 5
GROUP BY id ORDER BY listorder
but he's being shy :-)
@ypercube Yeah, I know. Dude won't return my calls, LOL
@JoshGitlin yup, derived table is the way to go. the only thing I changed in his is to use site=5 on each subquery. especially in the 'always=true' query. Am hoping site=5 is a better selective index :)
I updated my answer with that. My derived table is aliased different than the movies table to avoid confusion as well.
We're having a few discussions at work around the naming of our database tables. We're working on a large application with approx 100 database tables (ok, so it isn't that large), most of which can be categorized in to different functional area, and we're trying to work out the best way of naming...
@Rachel his requirements seem a little too vague: "It's possible (although not guaranteed) we'll have a number of different applications which could require the same data structure, or even the same data, from one or more functional areas but not all of them."
@Rachel Oracle deities like @JackDouglas may be able to speak to this better, but it seems like you may have a good answer in there. It is an architecture decision ... I defer to @JackDouglas or @jcolebrand
hah, it's amazing to me how information comes. I just learned earlier today that bitmap indexes are decent at low-selectivity indexes...Then I read in this data-warehouse book that bitmap indexes are one reason to denormalize dimension tables.
@JackDouglas Bitmap indexes are very expensive to update; they're really designed for star schemas where you're loading in batches. You can drop or disable the indexes for the partition, load data and then rebuild the indexes. Not much use outside of data warehouse systems but quite good for certain types of queries on star schemas.