Tito Ciuro wrote:
Oh!... just a quick message for the row-scan non-believers out there:
SQLite flies, even under this scenario. I'm getting wonderful
performance numbers by keeping everything within SQLite-land. The
code is simple and I let SQLite do all the magic. What else can I ask
for? :-)
If only you would listen enough to understand how clueless this
statement is....
You are clearly too arrogant to even listen to the reasons you have
built and will continue to build
poor relational database designs.
This thing won't scale. I'd like to see it when you have the 4.5 million
records my database contains,
and that is still tiny for all intents-and-purposes.
Absolutely NO ONE suggested moving anything out of "SQLite-land".
It was pointed out that:
You have defeated the purpose even using a relational database, this
thing is just a data dump.
You have neglected the most basic rules of design.
You will never have the advantage of using an index.
You are forcing the database to read and parse every single record from
that table every single time you
select a set of records.
If you refuse to understand why it is better to design a properly
normalized database that will find and return a single record
from a table with 4.5 million rows in 2 dozen disk reads, or fewer if
properly cached, rather than to force it to
read and parse every single one of those 4.5 million rows, you deserve
what you get.
As to your 'real good reason' for doing it this way, I'd bet cash money
it's crap and based on nothing more than
'Because that's the way I decided to do it, and I'm smart'.
There is absolutely no reason this could not be properly designed and
STILL fit any possible need for that ugly
packed record.
MGC
