Gambler wrote:It was slow as Christmas.
Could you please open any page of
http://korsengineering.com/ (it uses that DB package), view the page's source code and scroll down to the bottom? There will be a comment with page generation time. Not bad, eh?
No, it's not bad, but ....
1) How do I know that's not based on cached queries (MySQL has had a query cache since 4.0).
2) How do I know they aren't caching data in memory (Turckmcache has an API that allows one to do just that, as just one example)
3) How do I know that large portions of that page aren't cached somehow with only small bits being generated dynamically.
4) That page alone doesn't look like that big of a dataset. With the last team I worked for, the performance appeared to be good until they threw a dataset at it that was more representative of the apps real world intended usage.
Gambler wrote:
Caching is hot yet implemented, and my code is compatible with MySQL 3.x and PHP 4.3. There is plenty of room for improving performance. Using MySQL 5 queries would significantly speed the things up. Rewriting the whole thing in pure PHP 5 (without the use of MySQL) would elliminate all kinds of oveheads, making this thing truly scalable.
I don't think MySQL 5's query optimization is going to make
THAT big of a difference. Sure, they've prolly found some speed, but the myisam tables were allready pretty damn fast at simple selects anyways. The real question
As for writing the entire thing in PHP5 with no storage (no database), care to explain in more detail? Are you going to persist this data in memory or something? Is this a web based app? If so, where is the information going to live between requests? In a file?
There is a reason the relational database was invented. I think we should be careful that we don't forget that. Below is one of my favorite quotes along those lines. Emphasis is mine.
Fabian Pascal in an Interview with Tony Shaw from Wilshire Conferences wrote:
XML was invented by text publishers, who had no knowledge of data management, purportedly for data exchange. But exchange requires a physical format, not a data model. First, there are tons of formats in the industry and any one could have been used, why invent yet another? And second, XML is actually a bad physical format for exchange; it is highly and unnecessarily inefficient, to the point where it is increasingly violated to get performance out if it.
Now they are adding a data model to it, to be able to do any data management (see Tags Do Not a Language Make) and, as Chris Date points out, the first thing they had to do to define their “model” was to discard the notion of an XML document as the fundamental data object! What can you conclude from this fact? The model they did come up with is the same hierarchic model which we discarded 30 years ago and replaced with SQL, because it was too complex, inflexible and lacked rigor. I call the whole insanity “The Exchange Tail and the Management Dog”, the title of my new seminar. Would such regressions be accepted if practitioners understood data fundamentals? No way.
What you're suggesting is essentially a hierarchal data structure and as a programmer or biologist, it can seem pretty intuitive. But as a data model, it shouldn't be extended into the real of data management.
Cheers