[sqlite] Putting an index on a boolean

2015-12-12 22:50 GMT+01:00 Keith Medcalf : > > > One other point: The use of grave accents to quote column names is a > > > mysql-ism. SQLite also supports that for compatibility. But you > > > still shouldn't do it. The proper SQL-standard way is double-quote. > > > ?That is funny: I did not

[sqlite] Putting an index on a boolean

2015-12-12 22:44 GMT+01:00 Keith Medcalf : > > The first question(s) I would ask are: > Are all the fields case sensitive? (according to your definition they are) > ?Do you mean the name or the contents? ? > Are any of them, other than the primary key, unique? (according to your >

[sqlite] Putting an index on a boolean

2015-12-12 22:12 GMT+01:00 Mark Hamburg : > Though to the extent that speed is proportional to data size, it would be > good to use something other than hexadecimal to store UUIDs. Binary blobs > would be the most compact, but ASCII85 encoding would work well if you need > strings. > > Also, if

[sqlite] Putting an index on a boolean

2015-12-12 22:07 GMT+01:00 Darren Duncan : > On 2015-12-12 12:56 PM, Cecil Westerhof wrote: > >> By the way: I am thinking about using UUID for projectID and groupID, >>> but I >>> heard somewhere that it was a bad idea to use UUID for an indexed field. >>> Is >>> this true??

[sqlite] Putting an index on a boolean

2015-12-12 21:45 GMT+01:00 Richard Hipp : > On 12/12/15, Cecil Westerhof wrote: > > I am playing with SQLite. I am thinking about writing an application for > > projects. At the moment I have the following: > > > > CREATE TABLE `projects` ( > > `projectID` TEXTPRIMARY KEY, > >

[sqlite] Putting an index on a boolean

I am playing with SQLite. I am thinking about writing an application for projects. At the moment I have the following: CREATE TABLE `projects` ( `projectID` TEXTPRIMARY KEY, `groupID` TEXT, `isPersonal`INTEGER NOT NULL CHECK(isPersonal in (0, 1)), `name`

[sqlite] Putting an index on a boolean

> > One other point: The use of grave accents to quote column names is a > > mysql-ism. SQLite also supports that for compatibility. But you > > still shouldn't do it. The proper SQL-standard way is double-quote. > ?That is funny: I did not use them at first (or double). But I am using 'DB >

[sqlite] Putting an index on a boolean

sage- > From: sqlite-users-bounces at mailinglists.sqlite.org [mailto:sqlite-users- > bounces at mailinglists.sqlite.org] On Behalf Of Cecil Westerhof > Sent: Saturday, 12 December, 2015 15:32 > To: SQLite mailing list > Subject: [sqlite] Putting an index on a boolean > > I am playing with SQLite

[sqlite] Putting an index on a boolean

On 12/12/15, Cecil Westerhof wrote: > I am playing with SQLite. I am thinking about writing an application for > projects. At the moment I have the following: > > CREATE TABLE `projects` ( > `projectID` TEXTPRIMARY KEY, > `groupID` TEXT, > `isPersonal`INTEGER NOT

[sqlite] Putting an index on a boolean

For my part, in a database I designed that used a SHA-256 hash for a unique identifier that was then a foreign key from many other tables, I stored that as an integer and not as a hex string. If UUIDs are similarly numbers fundamentally, they possibly could do likewise. I agree with Mark's

[sqlite] Putting an index on a boolean

Though to the extent that speed is proportional to data size, it would be good to use something other than hexadecimal to store UUIDs. Binary blobs would be the most compact, but ASCII85 encoding would work well if you need strings. Also, if these values are reused repeatedly as I suspect

[sqlite] Putting an index on a boolean

On 2015-12-12 12:56 PM, Cecil Westerhof wrote: >>> By the way: I am thinking about using UUID for projectID and groupID, >> but I >>> heard somewhere that it was a bad idea to use UUID for an indexed field. >> Is >>> this true?? >> >> I think you might have misunderstood. UUID is almost always a