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’