Or, if you are binding the values you can always do something like (a single statement):
insert or ignore into table (val) values (:val); select id from table where val = :val; Where you bind you long val string value to the parameter named "val". This has the advantage that you only bind (pass in) the long string once, and you will always get back the id to use whether the value had to be inserted or not. > -----Original Message----- > From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users- > boun...@sqlite.org] On Behalf Of James K. Lowden > Sent: Friday, 13 September, 2013 20:20 > To: sqlite-users@sqlite.org > Subject: Re: [sqlite] Insert statement > > On Thu, 12 Sep 2013 18:15:29 +0000 > "Joseph L. Casale" <jcas...@activenetwerx.com> wrote: > > > > If you make val unique -- and I see no reason not to -- then you > > > can select the id for every val you insert with "where val = > > > > I omitted the fact that val in table_a is unique. > > Ah, that will be very helpful. > > > Sending one large statement in this case would bypass the overhead, > > but using val as the reference would make the string very long. That > > text data might be several thousand chars long. > > So, the integer is a proxy for a giant unique string. OK, I might > have done the same thing. > > In principle, because the text is unique, you can find the id with > > select id where val = 'giant string' > > and that might be fine. If it's not fine --if it's too slow or > unwieldy -- you might consider computing, say, an MD5 has of the giant > string and adding that as a unique column instead of the integer > primary key. > > --jkl > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
