Storing a great many fields in a database

[Dr. Hawkins]

On Saturday, July 14, 2012, Mark Wieder wrote:
>
> Saturday, July 14, 2012, 3:16:25 PM, you wrote:
>
> > Or split it into two tables, and let my get/set functions figure out
> > which to use, one for currency values, and the other for everything
> > else?
>
> OMG. You have that many fields in *one* table? I think you need a
> serious database redesign. Or "design", since it sounds like it was
> never really designed in the first place. Come up with a database
> schema, split the data into component tables, and this will all become
> much easier.
>
 Name address, phone,,last 4 of SS, prior filing, total wage income for six
prior months, total business income 6 mo, bus expenses 6 mo, bus net 6 mo,
real estate gross 6 months. . . . .  Employer, Employer address, monthly
health insurance from wages, monthly health insurance no wage, total health
ins. Monthly, ... Total insurance monthly . . .

It's really a situation of 400-500 variables to report, some of which are
dependent upon and calculated by others (and once calculated, need to be
kept available for further calculation, and for which the calculated value
may be overridden).

Unfortunately, there is no general pattern, although for a significant
portion, they are repeated for the codebtor (wife) in a joint filing.

Currently, with SQLite, I que
there are that many "single use" data  (outside of the assets and debts) in
a bankruptcy petition.


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