On 23 Feb 2005 at 18:36, Nathan Kurz wrote:
> But maybe I'm not really understanding the advantages of the in-memory
> database. Is it in some way inherently faster on lookups than just
> setting SQLite to use a really large cache?
Well the way I think of it is the if you don't need to keep the
On Tue, Feb 22, 2005 at 09:38:53PM -0700, John LeSueur wrote:
> >In my model, a 'song' record consists of a unique artist/album/title
> >A 'tag' is a name/value pair associated with a 'song':
> > Song: song_id artist album title
> > Tag: song_id name value
> >Searching for the tags associated w
>
> > In my model, a 'song' record consists of a unique artist/album/title
> > A 'tag' is a name/value pair associated with a 'song':
> >Song: song_id artist album title
> >Tag: song_id name value
> > Searching for the tags associated with a given song would be pretty
> > easy, but compl
> In my model, a 'song' record consists of a unique artist/album/title
> A 'tag' is a name/value pair associated with a 'song':
>Song: song_id artist album title
>Tag: song_id name value
> Searching for the tags associated with a given song would be pretty
> easy, but complicating matter
Nathan Kurz wrote:
Hello --
I've got a SQL problem that I'm guess is about half general and half
SQLite specific. I'm pretty new to SQLite, familiar with basic SQL
(mostly from MySQL), and I'm accessing SQLite through C and Perl.
The problem I'm working on relates to tagging music for some music
m
Hello --
I've got a SQL problem that I'm guess is about half general and half
SQLite specific. I'm pretty new to SQLite, familiar with basic SQL
(mostly from MySQL), and I'm accessing SQLite through C and Perl.
The problem I'm working on relates to tagging music for some music
management softwar
6 matches
Mail list logo
