Tom Jackson said:
> I think that there are developers who are not familiar or comfortable with
> SQL
> and database management systems. This can lead to a number of bad choices
This seems to be a big problem everywhere. I didn't realize quite how bad
it was in our company until just two weeks ago with two very bad gaffes.
Developers seem to think of the database a "just somewhere to store your
app's data" rather than seeing it as the core of their application.
Pretty soon I am going to do a talk on this. It won't be enough to teach
people all they need to know, but at least it should wake them up and
realize that they do not know enough.
The saddest part is that most of our devs are top-marks grads from
London's top CS program. (Imperial College) And even though probably 90
percent of this uni's grads end up working with RDBMSs and SQL in the
companies they join, the universities just don't seem to have any
(comprehensive) courses on the subject.
They know how to - and spend time on - making their Java code go from 3ms
executiong time to 2.5ms, but not how to make a 2 minute query run in 30ms
just by creating the right indexes and slightly modifying their query...
("Well, it's slow now because there are 10 *THOUSAND* rows in the table!")
> other type of cache. Until traffic develops, it is hard to predict where
> the
> slow points will show up, but putting data into a key-value system from
You should be able to for most things, really. Plus it's pretty easy to
from the start of development fill your database with a lot of dummy data
and run your queries against that.
You are very right on "premature optimization"; there certainly is a time
and place for solutions like BerkeleyDB, but most applications should be
absolutely fine with an RDBMS, proper data design, indexes, queries and
caching. The latter especially for things like the mentioned "static
data"; in a properly normalized database, it is much more efficient to
lookup the "hair_color_id" and "drinking_habits" in an nsv, rather than
joining the profile table on the "hair" and "drinking" tables, and who
knows what other referenced tables.
My soon-to-lauch http://www.sativo.co.uk/ has a couple of one-to-many
relations between the profile table and the tables that store people's
prefered gym activities and workout times and a few other things. Joining
these in the search as most people would do is incredibly slow. Instead, I
turned all these entries into a string like "act_cardio act_weights
time_early_evening time_sun_morning", etc. Indexing this using tsearch2 in
Postgres and doing a full text query makes it fly. As addedd bonus I get a
"fuzzy" search (not all have to match) and the more match, the higher the
ranking.
I would say this could work very well for many other applications too,
just something to think about whenever you end up creating a service that
does any searching/matching; just becuase there isn't any text to index,
doesn't mean that a full-text indexer isn't the right tool!
Bas.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]>
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
