SQLite performance issues.
SQLite performance issues.
- Subject: SQLite performance issues.
- From: Bill Bumgarner <email@hidden>
- Date: Tue, 29 Nov 2005 11:38:34 -0800
(combining responses)
On Nov 29, 2005, at 9:54 AM, Lynn Fredricks wrote:
If your programmers work for free, then I see more reason to
consider SQLite
as free. But if you check what it costs to get into Valentina,
you'll see
that it's a minute drop in the bucket compared to a project cost --
something to weigh vs the performance benefits. If it makes the
difference
of if you have to troubleshoot just once with SQLite, odds are you've
already saved the cost of Valentina right there.
This is spinning dangerously close to non cocoa-dev related marketing
noise.
This is FUD. SQLite's author offers an excellent annual support
contract at a reasonable price and has proven to be incredibly
responsive; more so than most commercial vendors I have worked
with. Furthermore, bug reports are very quickly addressed and the
releases are incredibly stable (due to the 25,000+ unit tests).
There is also a burgeoning third party market for supporting and
innovating on top of SQLite. The same can certainly be said for
many open source projects -- Subversion, Apache, Sendmail, Postgres,
Python, Perl, Ruby, etc.etc.etc... Just because it is free does not
mean poor support and I'm really tired of claims otherwise (sorry --
that pushed my button).
If you disagree, please respond off list.
Back to the technical (and more relevant to the list) stuff.
On Nov 29, 2005, at 9:35 AM, Ruslan Zasukhin wrote:
On 11/29/05 6:53 PM, "Bill Bumgarner" <email@hidden> wrote:
On Nov 29, 2005, at 5:32 AM, Ruslan Zasukhin wrote:
SQlLite is really "LITE".
So nobody should expect miracles from it.
Too be clear -- SQLite isn't terribly LITE on anything but size of
the codebase and ability to be trimmed and embedded down to handheld
devices (several MP3 players and phones ship with SQLite
databases in
'em).
But, SQLite can also scale; up to 16 terabyte databases with
billions of tables, billions of columns per table, and billions of
rows per table.
Bill, this is only technical specification.
It means that SqlLite uses
ulong -- as counter of tables.
ulong -- as counter of fields
ulong -- as counter of records.
That is incorrect. Keep in mind that SQLite is optimized for
embedded use. Such waste of bits would be catastrophically offensive
to those folks using SQLite on embedded devices with less than 64MB
of combined flash and RAM.
SQLite adapts the size of said counters and indices based upon the
size of the dataset. Keys and indices will be 1 byte for very small
datasets (less than 128 items).
But this technical specification do NOT means in any way that you
really can
make such huge dbs. You will wait hours and days for answers. Who
need this?
That has not proven to be true in practice. There are many people
who are using SQLite quite successfully across multi-gigabyte databases.
End all, be all? Nope -- I'm quite interested in learning more
about
Valentina (as I have investigated tons of databases over the years).
...
A I have told, in near time, we want investigate if we can integrate
Valentina deeply into CoreData. For now Justin uses only bindings.
Please file an enhancement request via bugreport.apple.com giving
technical details as to how such an integration might be done from
the perspective of Valentina. It will come back as a dupe as many
developers have asked for access to external databases, but the Core
Data team will definitely appreciate your product's unique perspective.
As per the performance claims, I would love to see the code used to
do the test. Please post or send 'em to me in a private email.
That was REALbasic projects.
Is that okay ?
Sure. That may be the source of the performance issue, too. I have
no idea how efficient the RealBasic interface might be. In any case,
that it is RealBasic makes it a bit outside of the realm of cocoa-
dev. There are also
---
Bringing this back around to Core Data; the goal of CD is to be
store agnostic and to offer complete object graph management to the
Cocoa developer. While storage is a critical feature to Core Data,
the fact that it can transparently manage changes, including
validation, across an object graph is the more valuable asset. As
for storage, there are certain patterns of behavior available with
the SQLite store that cannot be achieved with the other store types;
partial object graphs, faulting, memory footprint pruning, etc...
b.bum
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden