Stashing 3 or 4 characters into a text for db storage

Dr. Hawkins dochawk at gmail.com
Sat Jul 21 14:52:55 EDT 2012


On Sat, Jul 21, 2012 at 10:59 AM,  <dunbarx at aol.com> wrote:
> Not sure I understand what you want, but are you married to having a single numeric
> string encode your three/four char data?

no, just trying to be efficient--an integer has four bytes, which
invites me to use it :_)

> It would be so much easier to store them as direct strings, with something unambiguous as
>delimiters, maybe even a comma?

The main data about the debtor (pretty much everything but the debts &
assets) is, for the most part, fields valued in dollars.  I'll have a
table with columns for a keyword, an override value for entered data,
and a default, all saved in an integer as cents rather than dollars
(currently I have a column for the value itself, but that is
redundant--if there's an overide, it's that, else it's the default).

There are also text fields ranging from 1 to about 200 characters;
I'll use a second table for that, with VARCHAR() to store them.

Sticking the booleans & integers in the numeric table is a no-brainer,
as is single-character string.

But is it more effecient to convert a four byte integer back and forth
to string in livecode, or to store it as one of these variably
lengthed strings?  I assume that the database is an order of magnitude
more efficient speedwise than a livecode conversion script, but it
also means more data in this less-optimized table and a modest
increase in storage space.

Database usage is the "precious" resource given bandwidth & storage,
while livecode execution on the desktop is "cheap"


-- 
The Hawkins Law Firm
Richard E. Hawkins, Esq.
(702) 508-8462
HawkinsLawFirm at gmail.com
3025 S. Maryland Parkway
Suite A
Las Vegas, NV  89109




More information about the use-livecode mailing list