I'm late too, but here you have my opinion
At 02:03 05/02/2007, you wrote:
FWIW I don't interpret any posts on this thread as an attempt to change
SQLite, either. But there seems to be some who see value in more clearly
defining *when* SQLite *does* work. I guess that there is a lot of
enthusiasm for SQLite's ability and performance and it's nice to be able
to prove that SQLite does actually compete in areas it was not even
designed for. Perhaps an argument for less complex design as a generic
software design strategy.
Well, I am a powerpc developer and i really love Risc architecture,
not only on hardware, in software too. SQLite is a true Risc
application, it's small, easy to use, fast for the things it do, and
a lot of things it can't do they can be done using the fast existing
ones(yes, there are things it can't do). Also it's structure (SQL
Parser + VDBE + Pager/Btree) has low complexity and completly
separate and independent so adding important features to one (adding
the last SQL standard, change file format, f.e.) only means changes
in one and they can run at different speeds. Perhaps it's a bit hard
to understand, but if you know how Risc work i hope you understand me.
The principal problem i see is "How can i do that without
**whatever** feature i had on another RDBMS?" It's in fact the same
problem CISC guys have when doing the switch to RISC. The answer
usually is "Make it simpler". For example, when someone asks, "I have
a database with a superbig table, how can i speed it up?" answer,
"Simplify the problem using more tables with simple designs, aka
database normalization."; or when other asks "I have a huge database
with 30 tables but can't access for write when already writing to it"
answer, "Simplify the problem using, where apropiate, 1 table in 1
database, so you can access 2 tables/databases for write
simultaneously". Resuming, using SQLite needs a change in
thinking/designing/using databases and going back to the first
question, generally reading a SQL book for refreshing knowledge or
redesigning the query is enough.
P.S. Don't know, but is VDBE threaded? Or in other words, Has VDBE
state machine/processor, not C code of VDBE, threads/fibers/parallels
or can run 2 different querys vdbe code simultanely?
-----------------------------------------------------------------------------------------
Useful Acronymous : FAQ = Frequently 'Answered' Questions
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
