Re: Long text fields
- From: "dawn" <dawnwolthuis@xxxxxxxxx>
- Date: 7 Nov 2005 09:39:28 -0800
None wrote:
> Here are the QM answers....
>
> dawn wrote:
> > 1. I haven't looked it up for any particular db, but is there a
> > standard longest field across pick environments? (An actual dtabase
> > storage restriction)
>
> QM will support strings up to 2Gb throughout. Of course, you probably
> run out of other resources before you hit this limit.
Yes, that is excellent. I won't come close.
> > I would like the database to work in openQM and UniData, but would also
> > like it to be compatible with the others -- UniVerse, Revelation,
> > jBASE, D3, UniVision if I ever made the application work with those.
>
> As an aid to cross-platform portability, QM always sets a define token
> named QM. Thus you can insert code such as
> $ifdef QM
> ...qm stuff...
> $else
> ... non-qm stuff...
> $endif
>
> How nice it would be if the other vendors did this too.
I agree. And of course I'd also like that standard data source
definition and connectivity for use with all client-server access
across all flavors and within all languages. ;-)
>
> > 2. I realize the FMT is for display, not storage size, but is there a
> > maximum in the FMT in the dictionary, such as FMT(99999T)?
>
> Contrary to its general design policy, QM does impose a limit here of
> 4096 characters.
That's too small for the field, but I can start with that.
> If someone came up with a realistic reason to want
> this to be bigger, I'm sure we would do it.
I don't know enough to know my options yet. Thanks.
> > 3. Are there performance implications if I make a long single-valued
> > text field instead of multivalued short lines of text? Other
> > implications?
>
> This all depends what you are trying to do. A bit more information
> would help. Mutlivalueness (new word) is usually determined by the
> nature of the data, not some arbitary string length consideration.
Yes, I agree. The text is all a single "script" as in the "script" of
a 30-minute TV show (for lack of better term -- more information once I
have the design complete). My original thinking was to handle these
documents using XML at the file system and simply store a URL. But I
want to consider queries against this data as well as the other that is
stored, which is why I would like to store it in the database.
> > 4. These questions might not even be the right ones, so what do you
> > consider to be "best practices" related to long text fields in an MV
> > environment where the application code will be in languages other than
> > DataBASIC (e.g. PHP), retrieving data using a dictionary definition.
>
> An explanation of what this long data represents would be useful.
After I think about it a bit more, I might catch you offline on that,
but if you think of it as scripts as indicated above it will give you
an idea of the nature and length of the data.
Thanks a bunch. --dawn
>
>
> Martin Phillips, Ladybridge Systems.
.
- Follow-Ups:
- Re: Long text fields
- From: Glen B
- Re: Long text fields
- References:
- Long text fields
- From: dawn
- Re: Long text fields
- From: None
- Long text fields
- Prev by Date: Re: Long text fields
- Next by Date: Re: Attempt to de-mystify AJAX
- Previous by thread: Re: Long text fields
- Next by thread: Re: Long text fields
- Index(es):
Relevant Pages
|