9 posts • joined 16 Apr 2007
> That sounds fishy.
>This would mean your sample space is the space of "two dead people in a row". This doesn't sound well-defined.
*sigh* - yes there is a bunch of stuff missing from my post because I a) didn't have all the details to hand, and , b) assumed that intelligent people would go digging with the details I'd given to get the full picture*.
To clarify, head on over to badscience.net and search for "The Prosecutor's Phallusy" to get all the info. To quote, what I believe is the main point in this, I'll quote from the original post:
"Two babies in one family have died. This in itself is very rare. Once this rare event has occurred, the jury needs to weigh up two competing explanations for the babies’ deaths: double SIDS or double murder. Under normal circumstances – before any babies have died – double SIDS is very unlikely, and so is double murder. But now that the rare event of two babies dying in one family has occurred, the two explanations – double murder or double SIDS – are suddenly both very likely. If we really wanted to play statistics, we would need to know which is relatively more rare, double SIDS or double murder."
I will point out that my initial statement of twice as likely was wrong - it appears to be between 4.5:1 and 9:1 in favour of it being SIDS.
* I've deliberately tried to be a bit vague as, I assume, Tim Worstall would have given the details if he could/felt it appropriate.
The other thing regarding the cot death conviction...
The other thing is that you are comparing the realtive likelihood of a double cot death (in itself rare) to that of a double murder (also a rare event). So as I understood it from reading Bad Science (by Ben Goldacre) you have to think in terms of which is more likely - double murder or double cot death, i.e. given that one of two very unlikely things have happened what are the chances it was one or the other.
If I recall correctly the upshot was that it was twice as likely to be a double cot death than double murder.
Well my iPhone 3G was virtually unusable
After upgrading to iOS 4 my 3G was terrible, things in generally were slow even trying thing such as "Double Hard Resets" only worked for a short while, many apps were prone to crashing and were slow and worst of all for me it stopped playing nice with the car stereo.
So I reverted it back to 3.1.3 and it really did highlight the performance difference between 3.1.3 and iOS4.
Perhaps it's a function of how you use it and the apps you have on there, but just because it didn't affect you doesn't mean everyone else is mad. By the same token if I was the only person with issues doesn't meant everyone else is - but I think it's established that there are issues with iOS4 - particularly on the 3G.
Actually it can be free...
Granted you'll have to use Oracle XE but that is free to use and deploy and I would have thought is upgradable to v4 (it upgrades to 3.2 just fine). With that come some restrictions (e.g. 1 CPU/core will be used, 4GB of user data and only 1GB of RAM will be used).
But provided you can live with those limits its a great way into Oracle and provides you with a path to upgrade to full fat Oracle in future if you need.
Grrrr.... SQL != SQL Server.
SQL = Structured Query Language.
SQL Server = Microsoft's implementation of a relational database.
I'm fed up of people thinking SQL = SQL Server. How do you think you query an Oracle/MySQL/Postgres database?? That's right with 'SQL'...
The idea looks like great - it also has that "D'oh! Why didn't I think of that feel about it...". Let's hope it makes it into production.
Bind, bind, bind!
As Dominic says this is VERY easy to avoid - simply binding the variable would prevent the attack - in addition it would likely save you resources as well as it would only soft parse the query instead of the hard parse everytime it has a new date plugged into the code.
@Aodhhan - is it a vulnerability though? Poor coding practice yes, but a vuln that needs fixing? I'm not convinced - IMHO it's a bit like saying that because you can shoot yourself in the foot with pointers in C, C needs fixing...
Re: Posted Sunday 20th May 2007 07:50 GMT
The statement regarding the CBO is pointless without more information. If you are accessing more than quite a small percentage of data it IS actually MORE efficient to access it without the use of indexes, try it (if you haven't already) and see what happens with and without the index.
Even if you hint it to use an index and it is more performant for you at what cost is the performance increase? For example you may be annihilating disk IO. This might be fine in your case but is not necessarily good in every situation.
You may well have done all of this and found that actually the CBO really is choosing a bad plan - it's not unheard of, but your statement is a best misleading at worst plain wrong with out facts to back it up.
Yeah but, no but...
IMHO one of the biggest problems today for RDBMS's is the fact that many people still view it as a black box and believe that there is no need to understand the underlying engine - they do treat it as a commodity.
Usually this is with the misguided notion that they will be able to write once, deploy anywhere regardless of the underlying RDBMS. This is generally, however, a recipe for disaster. There is an interesting Blog post from Tom Kyte who is a prominent member of the Oracle community on this sort of subject here:
The other misnomer is actively avoiding or re-inventing features available in a given RDBMS - this is generally a worthless exercise as you will end up with a system that will not scale. I would argue that in general it doesn't so much matter which database you are using, but you must know how to get the best out of it. So whilst work with Oracle I don't pre-suppose that I know how SQL Server/DB2 does the same thing. That is not to say that they are inferior (they may or may not be - I don't know) just that each does it slightly differently and it is easier/better to work with a particular implementation rather than re-invent the wheel.
So is the database a commodity? Yes and no, as you say in your article there are some very capable "free" databases (not just MySQL, but also from Oracle with Oracle XE). In the case of XE this IS Oracle 10g, with some of the features pared down and some restrictions on sizing, for free. So you can become productive and achieve results in a commodity fashion.
However to get true scalability RDBMS's simply aren't a commodity, it takes skill and practice to get the best out of them.
- DAYS from end of life as we know it: Boffins tell of solar storm near-miss
- Put down that Oracle database patch: It could cost $23,000 per CPU
- Bose says today IS F*** With Dre Day: Beats sued in patent battle
- The END of the FONDLESLAB KINGS? Apple and Samsung have reason to FEAR
- Review Porsche Panamera S E-Hybrid: The plug-in for plutocrats