Scott wrote:
>It depends on what you call a character. If you consider a "character" the
>same way most people do (one typographical unit), then you have to deal
>with varying numbers of code points per character, even in a "fixed width"
>encoding like UTF-32. There is no hard limit on how many
On Mon, Apr 25, 2016 at 8:38 AM, James K. Lowden
wrote:
> On Mon, 25 Apr 2016 02:31:25 +0100
> Simon Slavin wrote:
>
> > > These are different concerns, and they don't really pose any
> > > difficulty. Given an encoding, a column of N characters can take
> > > up to x * N bytes. Back in the
On Mon, 25 Apr 2016 02:31:25 +0100
Simon Slavin wrote:
> > These are different concerns, and they don't really pose any
> > difficulty. Given an encoding, a column of N characters can take
> > up to x * N bytes. Back in the day, "x" was 1. Now it's something
> > else. No big deal.
>
> No.
On Mon, Apr 25, 2016 at 3:31 AM, Simon Slavin wrote:
> > These are different concerns, and they don't really pose any
> > difficulty. Given an encoding, a column of N characters can take up to
> > x * N bytes. Back in the day, "x" was 1. Now it's something else. No
> > big deal.
>
> No.
On 25 Apr 2016, at 1:42am, James K. Lowden wrote:
> Simon Slavin wrote:
>
>> Another reason is that we use Unicode not ASCII/SIXBIT/EBCDIC, and in
>> Unicode different characters take different numbers of bytes. So
>> even if you're storing a fixed number of bytes the convenience of
>>
On Mon, Apr 25, 2016 at 1:08 AM, Dominique Devienne
wrote:
> On Mon, Apr 25, 2016 at 3:31 AM, Simon Slavin
> wrote:
>
> > > These are different concerns, and they don't really pose any
> > > difficulty. Given an encoding, a column of N characters can take up to
> > > x * N bytes. Back in the
On Sun, 24 Apr 2016 08:51:09 -0400
Carlos wrote:
> But, with very fast CPUs and RAM memory buffers for the directory
> entries in the disks, the variable length records would probably
> result in gain for much less I/O for the data.
On Sun, 24 Apr 2016 14:09:50 +0100
Simon Slavin wrote:
>
> On 24 Apr 2016, at 1:51pm, Carlos wrote:
>
> > But, with very fast CPUs and RAM memory buffers for the directory
> > entries in the disks, the variable length records would probably
> > result in gain for much less I/O for the data.
>
On Sat, 23 Apr 2016 19:22:04 -0600
Scott Robison wrote:
> So if you could make your table up of integers, floats, and text
> with character limits on them you could get fixed-length rows, which
> might reduce your access time by 60% or more. Such a decrease in
> access time could mean the
On Apr 24, 2016 6:42 PM, "James K. Lowden" wrote:
>
> On Sat, 23 Apr 2016 19:22:04 -0600
> Scott Robison wrote:
>
> > So if you could make your table up of integers, floats, and text
> > ...
>
> As I tried to make clear in my reply to Keith, efficiency concerns ar
> ...
1. I think the quote
On Sat, 23 Apr 2016 14:50:45 -0400
"Keith Medcalf" wrote:
> > On Sat, 23 Apr 2016 08:56:14 -0400
> > "Keith Medcalf" wrote:
> >
> > > Those things that those other DBMSes do are holdovers to maintain
> > > backwards compatibility with the good old days when dinosaurs
> > > ruled the earth
>
>
On 24 Apr 2016, at 1:51pm, Carlos wrote:
> But, with very fast CPUs and RAM memory buffers for the directory entries in
> the disks,
> the variable length records would probably result in gain for much less I/O
> for the data.
Agreed. Which is one reason why fixed-length string columns are
But, with very fast CPUs and RAM memory buffers for the directory
entries in the disks,
the variable length records would probably result in gain for much
less I/O for the data.
On 23/04/2016 21:22, Scott Robison wrote:
> On Apr 23, 2016 6:21 PM, "Simon Slavin" wrote:
>>
>> On 24 Apr 2016,
On 24 Apr 2016, at 12:58am, Scott Robison wrote:
> For any SQL datastore, the way the data is stored is completely an
> implementation detail. The SQL engine would be free to serialize all values
> to text and store them in 4K pages if it wanted to, then deserialize them
> on the way back. I
On Apr 23, 2016 6:21 PM, "Simon Slavin" wrote:
>
>
> On 24 Apr 2016, at 12:58am, Scott Robison wrote:
>
> > For any SQL datastore, the way the data is stored is completely an
> > implementation detail. The SQL engine would be free to serialize all
values
> > to text and store them in 4K pages if
On Sat, Apr 23, 2016 at 12:50 PM, Keith Medcalf wrote:
>
> When a file is a bag-o-bytes rather than a collection-of-records (fixed
> length records at that), there is no longer any need to keep the records
> the same length, hence no need to specify the "reserved length" of things
> (contrary to
On 2016-04-23 4:58 PM, Scott Robison wrote:
> On Sat, Apr 23, 2016 at 12:50 PM, Keith Medcalf
> wrote:
>>
>> When a file is a bag-o-bytes rather than a collection-of-records (fixed
>> length records at that), there is no longer any need to keep the records
>> the same length, hence no need to
On Sat, Apr 23, 2016 at 3:22 PM, Richard Hipp wrote:
> On 4/23/16, Igor Korot wrote:
>> I merely tried to ask why in SQLite one can't have an information
>> about the table field size - that is all.
>
> Answer: That information would consume memory.
Thank you.
That was that simple. ;-)
>
> We
On 4/23/16, Igor Korot wrote:
> I merely tried to ask why in SQLite one can't have an information
> about the table field size - that is all.
Answer: That information would consume memory.
We are under constant pressure to reduce the (already small) memory
footprint of SQLite even further.
> On Sat, 23 Apr 2016 08:56:14 -0400
> "Keith Medcalf" wrote:
>
> > Those things that those other DBMSes do are holdovers to maintain
> > backwards compatibility with the good old days when dinosaurs ruled
> > the earth
> As amusing as your rant is, it's not accurate. Treating columns as
>
On Sat, 23 Apr 2016 08:56:14 -0400
"Keith Medcalf" wrote:
> Those things that those other DBMSes do are holdovers to maintain
> backwards compatibility with the good old days when dinosaurs ruled
> the earth
As amusing as your rant is, it's not accurate. Treating columns as
types is a
On Fri, 22 Apr 2016 19:11:46 -0700
Darren Duncan wrote:
> The general case of a data type definition is an arbitrarily complex
> predicate expression whose parts vary on the base type and other
> factors. Given this, if component details of type definitions were
> split out into their own
Hi, Keith,
On Sat, Apr 23, 2016 at 5:56 AM, Keith Medcalf wrote:
>> > What you are seeing there is SQLite just repeating back the type that
>> the CREATE TABLE command used. It is not the type of data SQLite is
>> actually storing.
>
>> > There is no 'varchar' datatype in SQLite. And it never
> > What you are seeing there is SQLite just repeating back the type that
> the CREATE TABLE command used. It is not the type of data SQLite is
> actually storing.
> > There is no 'varchar' datatype in SQLite. And it never truncates
> strings.
> > I think that the best thing for you may be to
On 23 Apr 2016, at 2:46am, Igor Korot wrote:
> However, what I'm saying is that most DBMS out there do store the size
> of the field.
>
> Even though I issue something like:
>
> CREATE TABLE test( id INTEGER, PRIMARY KEY, test1 VARCHAR(25), test2
> INTEGER(3), test3 FLOAT(25,2) );
>
> if I
Hi, Simon,
On Fri, Apr 22, 2016 at 9:23 AM, Simon Slavin wrote:
>
> On 22 Apr 2016, at 2:09pm, Igor Korot wrote:
>
>> The field type is set to be "varchar(100)" for the name field.
>> Wouldn't it be more logical to have it as "varchar" and have another field
>> for data size?
>
> What you are
The general case of a data type definition is an arbitrarily complex predicate
expression whose parts vary on the base type and other factors. Given this, if
component details of type definitions were split out into their own
table_info()
columns, you'd have a large number of columns where
On Fri, Apr 22, 2016 at 3:09 PM, Igor Korot wrote:
> [code]
> SQLite version 3.9.2 2015-11-02 18:31:45
> Enter ".help" for usage hints.
> sqlite> PRAGMA table_info(leagues);
> 0|id|integer|0||1
> 1|name|varchar(100)|0||0
> 2|drafttype|integer(1)|0||0
> 3|scoringtype|integer(1)|0||0
>
On 22 Apr 2016, at 2:09pm, Igor Korot wrote:
> The field type is set to be "varchar(100)" for the name field.
> Wouldn't it be more logical to have it as "varchar" and have another field
> for data size?
What you are seeing there is SQLite just repeating back the type that the
CREATE TABLE
Hi, ALL,
[code]
SQLite version 3.9.2 2015-11-02 18:31:45
Enter ".help" for usage hints.
sqlite> PRAGMA table_info(league);
sqlite> PRAGMA table_info(leagues);
0|id|integer|0||1
1|name|varchar(100)|0||0
2|drafttype|integer(1)|0||0
3|scoringtype|integer(1)|0||0
4|roundvalues|integer(1)|0||0
30 matches
Mail list logo
