Storing a great many fields in a database

[Peter Haworth]

The engine (if you mean the Livecode engine) has nothing to do with it, or
at least it shouldn't.  How VARCHAR works varies between SQL
implementations.  For sqlite, there is no difference between TEXT and
VARCHAR - they end up using only as much storage as needed.  Pretty much
the same for mySQL, but I believe other implementations don;t work that way.
Pete
lcSQL Software <http://www.lcsql.com>



On Mon, Jul 16, 2012 at 11:26 AM, Bob Sneidar <bobs at twft.com> wrote:

> I think then that for SQLITE TEXT is actually synonymous with VARCHAR. It
> was my understanding that VARCHAR allowed for an economical use of space,
> but was slower to index. The engine would use just enough space, up to the
> limit set, to store the values, truncating the excess. I seem to remember
> that one of the string types (perhaps CHAR) always stored trailing spaces
> up to the limit, and this produced faster indexes.
>
> I could be wrong though as I am not terribly experienced in database
> stuff, being only a hobbyist.
>
> Bob
>
>
> On Jul 16, 2012, at 11:08 AM, Andre Garzia wrote:
>
> > Bob,
> >
> > SQLite will always use TEXT and allocate just as much space as necessary
> to
> > store the information at hand. I think it is a better option.
> >
> > So if you just store 10 chars in that column, the TEXT field will use
> just
> > that space and nothing more.
> >
> > On Mon, Jul 16, 2012 at 2:58 PM, Bob Sneidar <bobs at twft.com> wrote:
> >
> >> Wha?? I thought the whole point to using VARCHAR was that it only used
> as
> >> much space as the actual text needed. What is the difference between
> TEXT
> >> and VARCHAR then?
> >>
> >> Bob
>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>