Storing a great many fields in a database

[Dr. Hawkins]

On Sun, Jul 15, 2012 at 8:13 AM, Dr. Hawkins <dochawk at gmail.com> wrote:
> More seriously, to the extent that they "group" with any rhyme or reason,
> it's currency values with the occasional Boolean, integer, and string.
>
> THe more I think about it, the more I think it will be an issue of storing
> strings in their own table;the others can transparently cohabit in a
> currency table.


OK, blobs are overkill, and then some.  It looks like varchar() is the
way to go.

It looks like a main table for the financials, with the booleans and
integers stuffed there as well and then a varchar table for the
strings. (storing true as 1 and false as 0?)

I note documentation that refers to numeric/decimal as "very slow" as
compared to floats (i'd need doubles, anyway).  Just how much is "very
slow"; is it even relevant on a remote database?  An occasional penny
rounding error isn't really critical for this type of work.


-- 
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