But it doesn't make sense. Surely it's better to just be right and actually make sense. Fools.

I think it's just missing its second half, much like "great minds think alike...". It's also ore sarcastic I think.

MyISAM has a concurrent insert mode, which you can play with to allow it to append records to the end of the data file (rather than hunting for a gap in the middle of the data file) if there is another SELECT in progress, thus avoiding locking that SELECT out.

 

You can tailor it to your individual circumstances.

 

http://dev.mysql.com/doc/refman/5.1/en/concurrent-inserts.html

Is Truffy an American now? I'm so confused!

I mean, if I went around saying "well, that's the way the gryphon crumbles" would you be like "well, he is half Welsh, so it's fine"?

You spelled it like that on purpose didn't you? :(

Truffy is some sort of foreign. They're all essentially the same.

Yeah, it's because I live in Zone 3 on the tube.

If you atomise though, which I do because I'm anal, all but the very simplest DB will involve joins of some sort or another though. Of course, 4.5M rows is a hell of a lot of rows!

It's kinda like saying I couldn't care less, but in a more sarcastic way as Xen said. I guess it should be 'I could care less, but not without trying hard' or some such but, frankly, I could care less.

 

I have no idea whether it's American usage. It's not Swiss German, that's for sure.

I think you need to either finish the sentence or use the less sarcastic form :-|

I could care less.
(hippo)
I like it as it is. (Even thought I feel dirty that it might be merkan.)

You mean normalise, surely?

 

And, I don't get your point. Were you making a point?

I do mean normalise, yes. I was getting confused with summat I as reading on atomicity and transactions.

 

The point I was making was that many DBs will have SELECTs that include joins (including most of mine), so the MyISAM's weakness in SELECTs with joins is hardly trivial. OTOH, if it really only affects large tables ... how large is 'large'?

Yes but mysql is *fast* so unless you are dealing with large volumes of data (e.g. 4.6 million rows and nasty self joins), it is more than likely you will never even hit a use case where 2 queries lock each other out - even if you do it will most likely only cause a lock of a few milliseconds which is moot for all you script kiddies writing your crazy blog sites in PHP and mysql.

Someone make InnoDB support compound auto-increments and fulltext searches and I'll love you forever.

I've ended up using SimpleDB, which has no concept of joins but permits multiple values for attributes. So instead of 4 million rows, I've got 100,000 rows with around 40 values on each. Doing the same search takes a tenth of a second, plus, I get more information back and my algorithm is much more accurate.

 

Just registered a cool domain name, going to have a prototype within a week and beta by Xmas.

 

Edit: makes that a million records with 200 values on each. Doesn't seem to make any difference to response time.

Script kiddie? Shit, I /wish/.

 

I did write a blog once in PHP/MySQL, but I wouldn't go so far as to say it was crazy. ATM I'm working on a (probably (very) low traffic) commerce site. From what you're saying it's highly unlikely that performance is going to be an issue.

Based on your podcast performance, I'm reading that as: "holding page by Xmas, prototype by summer, project abandoned for next fad by this time next year". :P



(Though I am interested in your thoughts/implementation of SimpleDB, assuming you're going to go into details on what you're doing at some point?)

This project is being driven by my brother, though, and he's more of a completer/finisher than me.

 

I've just discovered a limitation of SimpleDB that changes the approach somewhat, but it's still the most scalable solution by a mile. I will be sharing more details soon.