SQL

I would read the primary key and the time in, get them all and sort them out in program code, rather than trying to do it in SQL. If the table's too big, then you could write a loop and get every x minutes' worth of data and pick out the rows you want.

Once you've got them, execute a big IN (...) query to get the rows you want.

You could avoid that step if you've enough memory/time to get the whole rows at a time, I guess.

You're right, it's a messy problem!

i guess my solution is a function of a) being self taught (and with an idiot for a teacher) and b) using vi or grep for editing / sorting needs and, consequently, seeing everything as a string.

getting away from Jaq's specific problem for the minute:

would it be better if you cut down the result space first, like (pseudocode alert!)

where time.hour = 6 and time.seconds = 00 and to_char(time, 'mm') like '_0'

(in the same way "make && make install" or "if (str == null || str.trim().length() == 0)" (ie there's an implicit AND or OR in there and the second part only executes if the first part passes / fails) or is what gets executed a whim of the oracle developers?

or would i be better off going the whole hog and doing it all as numbers:

where time.hour = 6 and time.seconds = 00 and (time.minutes % 10) = 0

returning to Jaq's problem, DatePart()?

http://office.microsoft.com/en-us/access/HP010984871033.aspx

I could see that working, using DatePart() to return the minute and second. WHERE (((DatePart("n",FI15B_TI15D.TIME)) Like '_0')) AND (((DatePart("s",FI15B_TI15D.TIME)) = '00')) doesn't throw errors but also doesn't return anything. Running it with just the seconds clause or just the minutes clause also don't return anything. I'll keep poking at it though.

This is a dataset extracted from our running system as .csv files, btw. About 35k records in a purpose-built .mdb so I can hack away at it w/ impunity.

There were hard brackets around the tablenames, btw, but the BBCode parser got all choked up on them.

put the datepart()s in the select part and take them out of the where part and see what they are returning, probably isn't what you expect.

True. I bailed on it though and wrote up a function in my favorite environment (which handles .dbfs natively, and very nicely) instead.

ha ha. just been sent some optimised versions of the queries i'd written:

he optimised out an entire join against the 'artist' table. which was nice of him. except the query was meant to be returning a list of artist objects to fill up the Artist ejb things.

(he also removed a left join which meant we had to populate the previously left joined table in order to get the required rows returned - 413,000 mostly empty rows. per service (of which we have 4 and counting.)

Disheartening: http://www.sdtimes.com/printArticle/LatestNews-20070715-44.html

How weird.. Eveything I've ever seen in the past 10 years or so has suggested Oracle #1 and DB2 #2... Not that that's anything but disheartening too.

I'm wondering how the question was framed. Also, not even 700 people asked = this is a very very very small sample.

Thing is, my enterprise uses it, but the strategy is DB2 and Oracle; SQL Server is tolerated for packages, but not in-house applications. By that logic, we would have voted yes, to this study, when in fact, it's accounts for about 0.5% of usage as compared with DB2.

http://blog.labnotes.org/2007/09/02/couchdb-thinking-beyond-the-rdbms/

oh shit son

JSONned