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