Vining: Are you running mysql 5.6+?

Schilsky: Do you have the free disk space, and can you afford some maybe downtime, as well as turn on innodb_file_per_table? if yes, just do it

Feldmeier: There are basically no downsides apart from fulltext innodb search which is added in 5.7 iirc

Causey: Unless your hardware is constantly failing, in which case myisam is simpler to repair

Coyner: Yeah innodb isn’t as simple as a repair command

Waker: With sane innodb settings e.g.: big enough logfiles and plenty of binlogs you probably won’t have corruption

Connely: I only had to use recovery modes and then checksum verification after a botched operation of some kind

Helfenbein: I’ve had innodb corruption, but it was due to very small logfiles default I think? 8mb

Newstrom: I forget what it was 😛

Shaginaw: And no binary logging

Funaro: I think I resized the log file without turning it off first

Simonian: I’ve got a table full of thousands of rows, with a column ‘***etid’ which varies in value. Another table lets me look up the names of those ***etid’s. I’d like to query ***et.price WHERE ***etid IN x,y,z, then return a single column for each ***et – what is the best strategy to use for such a query?

Cheslak: Juxta: Your description is ***ue. You probably just want a join. If you have other questions, just post a testcase to sqlfiddle.com or more explicit table layout to pastie.org

Meuse: Xgc: it is, I apologise. I’ll put up a testcase.

Dubrey: Juxta: Additionally, you can’t easlily produce one column per item. You want one row per item. An alternative might be GROUP_CONCAT

Maziarz: Juxta: You can JOIN for each expected item, but that’s fairly rigid.

Krass: Xgc: I’d prefer to do things by rows, but I’m trying to prepare output in a format which can be p****d by another tool unfortunately

Strei: Juxta: It’s much more common to return a row per item and combine the results as needed in the app.

Boteilho: Juxta: Right. For parsing, you probably don’t need columns, but one column with all the items. That’s doable as long as your list is small enough.

Wagenaar: Juxta: The better general solution is to build that string in your application.

Kwok: Xgc: I agree, but in this case I can’t vary the application. I could write a helper to take my sql output and reformat it, I may need to do that

Leichtman: Xgc: my schema looks like this: http://pastie.org/private/fuc7mmz6myxuctc6mydua

Fanoele: Juxta: Now ask a simple question based on that schema.

Orsi: Juxta: What list are you trying to return, in what form?

Warmbier: Juxta: How will you know which column is for which ***et?

Hoel: Juxta: Is this ordered by ***etid

Vezza: Juxta: We could generate pairs of ***etid, price.

Tanious: Juxta: How many items do you expect max?

Joehnck: Xgc: essentially I want rows returned as follows: price.date, ***etX.close, ***etY.close, ***etZ.close

Do: Juxta: and X, Y and Z are ordered how?

Beemon: Juxta: Is X the lowest id?

Gramajo: Xgc: I’d be setting the column name/heading to the name that corresponds to the ***et – masterlist.code

Alvez: Juxta: What if one item has no close for some date?

Cappellini: Xgc: the returned data set would be ordered by the date column

Bores: Xgc: there should be no gaps in the data, but ***uming there are then returning a null is no problem

Perham: Juxta: I was asking about the order of the columns. So you will be asking for 3 and only 3 or is this width not known?

Mercer: Xgc: right, my mistake. the width is not known, the order of the columns is not too important, alphabetically is ok

Walliser: Juxta: But for each query, the number of items is known, correct?

Ruprecht: Xgc: yes – a list of ***et codes would be specified ‘AAPL, GOOG’