Обсуждение: 9k limit?
It appears that there is a 9k (8,991) limit on queries ... I have text files that need to go in TEXT fields that are much longer than this. Does anyone have any suggestions as to how to add them to the database? Has anyone else encountered this problem? Justin Long Never retreat. Never surrender. Never cut a deal with a dragon. _______________________________________________________________ Justin Long CIO / Site Editor 616 Station Square Ct Network for Strategic Missions Chesapeake, VA 23320 977 Centerville Trnpk CSB 317 JustinLong@xc.org Va Beach, VA 23463 Check out our site at: http://www.strategicnetwork.org
Justin Long wrote: > > It appears that there is a 9k (8,991) limit on queries ... I have text files > that need to go in TEXT fields that are much longer than this. Does anyone > have any suggestions as to how to add them to the database? Has anyone else > encountered this problem? Database records may not exceed 8k so increasing the query limit isn't going to help you much (although I still think it should be increased). There arn't many good options. You could use large objects (except that their implementation sucks). Or you could break up the object. Something like.. CREATE TABLE textfile (t text); CREATE TABLE extrabits (ord int4, textfile oid); If it fits into 8k you just use the text file class. If it spills over you start having to populate the extrabits with an order by field ord. Then you would SELECT textfile from extrabits order by ord where textfile = 'the-oid-of-text-file-you-are-looking-for'; and join them all back together Really ugly I know. I hope these arbitrary limits are removed sometime soon.
On Fri, 23 Apr 1999, Chris Bitmead wrote: > Justin Long wrote: > > > > It appears that there is a 9k (8,991) limit on queries ... I have text files > > that need to go in TEXT fields that are much longer than this. Does anyone > > have any suggestions as to how to add them to the database? Has anyone else > > encountered this problem? > > Database records may not exceed 8k so increasing the query limit isn't > going to help you much (although I still think it should be increased). > > There arn't many good options. You could use large objects (except that > their implementation sucks). Or you could break up the object. Something > like.. > CREATE TABLE textfile (t text); > CREATE TABLE extrabits (ord int4, textfile oid); > > If it fits into 8k you just use the text file class. If it spills over > you start having to populate the extrabits with an order by field ord. > > Then you would SELECT textfile from extrabits order by ord where > textfile = 'the-oid-of-text-file-you-are-looking-for'; and join them all > back together > > Really ugly I know. I hope these arbitrary limits are removed sometime > soon. > > Another solution (although not particularly platform-independent) is to store a path name in the database, and have your app open the file pointed to thusly, read it, and display/ manipulate it however you want. This is perhaps even more ugly than Chris's solution :) You could even store just a file offset, and then you might only need one text file to store all your text. No forget that. You would have too many problems updating file offsets to make it worthwhile. Simon. -- "The real reason Heisenberg and Schrodinger didn't get along is because, unknown to many historians, Heisenberg had a dog." Simon Drabble Somewhere in cyberspace
On Thu, 22 Apr 1999, Justin Long wrote:
// It appears that there is a 9k (8,991) limit on queries ... I have
// text files that need to go in TEXT fields that are much longer than
// this. Does anyone have any suggestions as to how to add them to the
// database? Has anyone else encountered this problem?
When I do something like this, I do it in two tables where the
large data is referenced from the other table. For instance, a logging
system I designed for work uses a table called ``events'' that stores
timestamps and other generic event information, then another called
``messages'' that stores the actual textual data. The source of this data
is any random application and some people make *very* verbose event
entries. The way I handle this is to start a transaction, store all of
the event data, then break the message data into 3000 byte chunks, base64
encode it, then store each chunk referencing the id generated from the
event id sequence with an incrementing part number each time. This lets
me store an amount of data on a single message limited only by disk space.
It also means that people using it may start to send movies back as error
messages and all will be well (though it'll be a little painful getting it
into the database).
--
Principal Member Technical Staff, beyond.com The world is watching America,
pub 1024/3CAE01D5 1994/11/03 Dustin Sallings <dustin@spy.net>
| Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE
L______________________________________________ and America is watching TV. __
If I have a UNIQUE or PRIMARY KEY clause on my class, does that create a btree or hash index? I guess if I have a UNIQUE constraint or PRIMARY KEY at class creation, I don't have to create an index explicitely via CREATE INDEX ?
If I want to have an index on oid, which will obviously be unique anyway, is it more efficient to have or not to have the UNIQUE option on CREATE INDEX ?
Does CREATE INDEX properly support the * notation ? Like if I go CREATE INDEX on foobar*, does that index foobar and all its subclasses?