Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.org!de-l.enfer-du-nord.net!feeder1.enfer-du-nord.net!feeds.phibee-telecom.net!usenet.ukfsn.org!not-for-mail From: Martin Gregorie Newsgroups: comp.lang.java.programmer Subject: Re: Storing large strings for future equality checks Date: Wed, 8 Jun 2011 22:02:37 +0000 (UTC) Organization: UK Free Software Network Lines: 21 Message-ID: References: <171dpt2926br2.dlg@kimmeringer.de> NNTP-Posting-Host: 84.45.235.129 Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Trace: localhost.localdomain 1307570557 9460 84.45.235.129 (8 Jun 2011 22:02:37 GMT) X-Complaints-To: usenet@localhost.localdomain NNTP-Posting-Date: Wed, 8 Jun 2011 22:02:37 +0000 (UTC) User-Agent: Pan/0.133 (House of Butterflies) Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:5141 On Wed, 08 Jun 2011 20:28:11 +0200, Lothar Kimmeringer wrote: > If you write seldom and read often, why not using two columns: > > string_hashcode > sha1_hashcode > You haven't given us a maximum size for the string or the name of the target database, so its possible that implementation constraints will prevent the strings from fitting into a character() column and you'll have to use a character varying, text, clob etc. instead. If this type isn't allowed as the table's primary key, you can use the hash code as the primary key. Since it doesn't matter if some strings have clashing hash codes this can't cause a problem. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |