Hi!
>SQLite is very storage efficient in the common case. In a typical table,
SQLite will use
>about 4 or 5 bytes of disk space for every 3 bytes of actual data stored.
Put another
>way, about 60% to 75% of an SQLite database file is the actual data being
stored
>and the other 40% to 25% is overh
Echoing some others' responses, particularly Darren's:
1. I don't see the rationale for putting much priority on
multiple string encodings. After all, blobs still can't
be stored natively :).
UTF-16 adds extra complexity, because of embedded nulls,
and because of its own need for a byte-order-ma
Greg Obleshchuk wrote:
>
> The data types I think are great but can we have a large and small integer?
> I noticed some people (embedded systems people) complain about this.
Version 3.0 will use 1, 2, 4, or 8 bytes to store an integer, depending
on how big the number is. It uses the fewest number
it would collate using the open parameter by default. If
there was a column override then it would use that
Greg
- Original Message -
From: Darren Duncan
To: [EMAIL PROTECTED]
Sent: Monday, April 12, 2004 8:46 AM
Subject: RE: [sqlite] A proposal for SQLite version 3.0
At
At 11:22 PM +0100 4/11/04, Steve O'Hara wrote:
I agree with Greg, the most irksome feature of SQLite is the case
sensititvity - it's one of the few things MS got right with SQLserver. I
know this is more mainstream/standard SQL behaviour but it's outdated in
modern SQL applications that nearly alw
At 11:22 PM +0100 4/11/04, Steve O'Hara wrote:
I agree with Greg, the most irksome feature of SQLite is the case
sensititvity - it's one of the few things MS got right with SQLserver. I
know this is more mainstream/standard SQL behaviour but it's outdated in
modern SQL applications that nearly alw
Hi Will,
Thanks for clearing that up for me, it make more sense now.
Greg
- Original Message -
From: Will Leshner
To: Forum SQLite
Sent: Monday, April 12, 2004 8:06 AM
Subject: Re: [sqlite] A proposal for SQLite version 3.0
On Apr 11, 2004, at 3:01 PM, Greg Obleshchuk
rching.
In fact, I'd go one step further and advocate making SQLite case-insensitive
as a rule.
I'm waiting for the flames...
Steve
-Original Message-
From: Greg Obleshchuk [mailto:[EMAIL PROTECTED]
Sent: 11 April 2004 23:02
To: D. Richard Hipp; [EMAIL PROTECTED]
Subject: Re:
On Apr 11, 2004, at 3:01 PM, Greg Obleshchuk wrote:
You state that there may or may not be the call-back function wrapper.
I would be an advocate for keeping it. This way of handling returned
data is most useful. Sometimes when returning thousands or more rows
of data you want to cancel the
Hello,
I just read the proposed changes and they seem fine. A couple of thing.
The data types I think are great but can we have a large and small integer? I noticed
some people (embedded systems people) complain about this. I quite happy with the
large type but as integers will now be store
=== On 2004-04-09, D. Richard Hipp wrote ===
..
>
>The reason for not doing this is that maintenance of the counter
>slows down inserts and deletes. Is having a constant-time count(*)
>really work slower inserts and deletes? If you have opinions on
>this, speak up now, because it won't be an opti
Windows UTF-16 is represented by WCHAR. It is always 2 bytes. UCS-2 can
be 3 or more bytes but these are for extended characters outside the ones
used for real language. For example, musical notation symbols use the
third byte. I don't think any OS's use UCS2 directly. I know Oracle
supports U
I'm assuming UTF-8 support will still be there as well? For Windows
applications, UTF-16 is much more prevalent.
--
Andrew
On Wed, 7 Apr 2004, Christian Smith wrote:
> On Wed, 7 Apr 2004, D. Richard Hipp wrote:
>
> >A design proposal for SQLite version 3.0 can be found at:
> >
> > http://w
Friday, April 9, 2004, 6:54:44 AM, D. Richard Hipp wrote:
> Nuno Lucas wrote:
> > I have a feature that would be nice in a 2.8.x version, but I can live with
> > it if only on 3.0. It's the optimization for the many times used "SELECT
> > COUNT(*) FROM ...", at least if FROM is a table or a vi
Nuno Lucas wrote:
> I have a feature that would be nice in a 2.8.x version, but I can live with
> it if only on 3.0. It's the optimization for the many times used "SELECT
> COUNT(*) FROM ...", at least if FROM is a table or a view.
>
> I don't know exactly why it takes so much time, but if a file f
Hi,
I passed my eyes over the proposal and all seems ok to me (haven't made a through read
yet, but I have total confidence on the good work of D. Richard Hipp).
I have a feature that would be nice in a 2.8.x version, but I can live with it if only
on 3.0.
It's the optimization for the many times
D. Richard Hipp wrote:
> The 1st and 3rd APIs above will work, but not the second. Remember,
> SQLite 3.0 will have manifest typing, which means that type of the
> data can change from one row to the next. Type is not associated
> with a column, as in standard SQL. So there is no way to know the
> >
> > A statement's parameter values would be reset to null
> values when the
> > statement is reset.
> >
>
> Is that really the desired behavior? If you want to reset
> parameters on a statement reset, wouldn't it be better to do
> so explicitly. That way, if a statement has 10 paramete
Dennis Cote wrote:
The API should provide functions that allow the application to inspect the
number, type, and names of the parameters that were discovered while parsing
the SQL. These functions could be called any time after the statement is
prepared.
int sqlite3_param_count(sqlite3_stmt* stm
On Thu, 8 Apr 2004, Dennis Cote wrote:
> I would like to propose some additions to the API to support named
> parameters in the SQL statement. These features will make it easier to use
Well explained, Dennis. I had also given a paragraph in support for named
parameters, but you explained the ma
D. Richard Hipp wrote:
> A design proposal for SQLite version 3.0 can be found at:
>
> http://www.sqlite.org/prop2.html
>
Richard,
I read your proposal and it all look very promising to me.
I would like to propose some additions to the API to support named
parameters in the SQL statement. T
The proposal for version 3.0 looks very promising and I hope all the major
changes
will be implemented. Most of the enhancements seem to add flexibility and
scalability to
to the "C" based api. This is great as at the "C" api call level you can do
anything you want.
But I do not see any changes to
Yes, that is right, my database consists of mainly numbers. Some of them
have 10 digits, some have less. This would explain part of the
difference. I was also wondering if Access perhaps has some type of
index comprimation, like cutting pre- and postfixes in the B-tree.
Jakub
Simon Berthiaume
> Could we please see the current behaviour set in stone? I'd like to know
> that generated keys will always fit into 32 bits (provided I don't
> exceed ~4.3 billion records, naturally).
I think that it's a dangerous precent to fix these things in stone, certainly at the
source level. Perhaps
I have an application which depends on INTEGER PRIMARY KEY values
fitting into 32 bits.
I know that currently, the keys are generated with MAX()+1, but this
behaviour is "undocumented and liable to change.: Now that rowid's are
going 64 bit, a truly random INTEGER PRIMARY KEY may not fit into 3
I would like to request that pages be exactly a power of 2 size (including
headers), and that when reading and writing pages the buffers are aligned to
a reasonably large power of 2 size.
The reason for this is that often in embedded systems the low level device
drivers and filesystems work *much*
Null is not a value. The definition of NULL is that a value has not been
assigned and is therefore unknown. Once a value is assigned, Null is no
longer valid. Unless somebody changed the definition in the last thirty
years or so :-)
> -Original Message-
> From: Tom Shafer [mailto:[EMAIL
At 12:08 PM 4/8/2004 +1000, [EMAIL PROTECTED] wrote:
A little while ago a list reader suggested a kind of index (from ms
access, if I recall... I don't recall the term they used) that is not
external. Instead the index changes the order in which the table itself is
organised.
I believe you're think
Peoples :)
"D. Richard Hipp" <[EMAIL PROTECTED]>
07/04/2004 11:22 PM
To: [EMAIL PROTECTED]
cc:
Subject:[sqlite] A proposal for SQLite version 3.0
> A design proposal for SQLite version 3.0 can be found at:
> http://www.sqlite.org/prop2.html
> Feed
Darren Duncan wrote:
Here are some of the things I like (correct me if any actually not
present):
Your summary looks very good. Thanks you.
- SQL strings given to prepare() can have "?" placeholders for
inspecific literals to fill in later with bind() functions. VERY VALUABLE.
- Actual blobs c
eno wrote:
well, the question is: Support UTF-16 to what extent? I think here of
sorting questions, (but other may arise). Obviously, sorting within a
single language is specific to that language, whereas sorting a, say,
german word with an ukrainian word is what a programmer calls
"undefined".
D. Richard Hipp wrote:
A design proposal for SQLite version 3.0 can be found at:
http://www.sqlite.org/prop2.html
Feedback from the user community is strongly encouraged.
An executive summary of the proposed changes follows:
* Support for UTF-16
well, the question is: Support UTF-16 to w
At 9:22 AM -0400 4/7/04, D. Richard Hipp wrote:
A design proposal for SQLite version 3.0 can be found at:
http://www.sqlite.org/prop2.html
Feedback from the user community is strongly encouraged.
Hey, this looks great!
Here are some of the things I like (correct me if any actually not pres
D. Richard Hipp wrote:
Jakub Adamek wrote:
> My experience is that SQLite makes roughly about 3x bigger files than MS
> Access. How would this change in 3.0?
>
SQLite is very storage efficient in the common case. In a typical
table, SQLite will use about 4 or 5 bytes of disk space for every 3
It might be true if you mostly store large quantities of NUMERICAL data
(float, int, ...) since they are currently stored as strings (the value
1234567, would be stored using at least 7-8 bytes instead of 4). If you
were in the same situation as I, where I use database mostly for
strings, you would
"D. Richard Hipp" <[EMAIL PROTECTED]> wrote:
So what datatype
are most systems expecting to use for UTF-16 strings? Who can provide
me with a list? Or even a few examples?
Here's one: On Mac OS X, a UTF-16 string would typically be UniChar*,
where UniChar is a typedef for unsigned short, with a
TED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, April 07, 2004 9:10 AM
Subject: Re: [sqlite] A proposal for SQLite version 3.0
Jakub Adamek wrote:
> My experience is that SQLite makes roughly about 3x bigger files than MS
> Access. How would this change in 3.0?
>
SQLite is very
ECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, April 07, 2004 9:10 AM
Subject: Re: [sqlite] A proposal for SQLite version 3.0
Jakub Adamek wrote:
> My experience is that SQLite makes roughly about 3x bigger files than MS
> Access. How would this change in 3.0?
>
SQLite is v
Jakub Adamek wrote:
> My experience is that SQLite makes roughly about 3x bigger files than MS
> Access. How would this change in 3.0?
>
SQLite is very storage efficient in the common case. In a typical
table, SQLite will use about 4 or 5 bytes of disk space for every 3 bytes
of actual data stored
Simon Berthiaume wrote:
>> Notice that text strings are always transferred as type "char*" even
if the text representation is UTF-16.
This might force users to explicitely type cast some calls to function
to avoir warnings. I would prefer UNICODE neutral functions that can
take either one of t
On Wed, 7 Apr 2004, D. Richard Hipp wrote:
>A design proposal for SQLite version 3.0 can be found at:
>
> http://www.sqlite.org/prop2.html
>
>Feedback from the user community is strongly encouraged.
>An executive summary of the proposed changes follows:
>
>* Support for UTF-16
>
>I do not
Hello,
I am using SQLite in a car navigation system which should work on PDAs
as well. Thus speed and size is crucial for us. SQLite is superb in the
speed category, but the size of its file is not so superb. I see you
mentioned something about file size. My experience is that SQLite makes
rou
As a developer of Delphi components for SQLite I would recommend a new
function for both releases to investigate the fileversion. Perhaps it's
already there. Of course you can open a database and wait for an
exception to occur, but this is not a very clean way of doing things.
Having this possi
43 matches
Mail list logo
