Suggestions

[Derek Atkins]

Hi,

Please remember to CC gnucash-user on all your replies using your
mailer's reply-to-list or reply-all functionality!

ALbert Gráfica - Suporte <suporte at albertgrafica.com.br> writes:

> Hello, everyone, I have some suggestions to the project:
>
> I pursued the project, so maybe some things that suggest to you that they
> develop the project to be absurd or impracticable, but they are only
> suggestions, anyway I'm not a programmer.
>
> First, GnuCash, the ram carries all data, so in some situations it made the
> program extremely slow loading or unbearable.

This is due to historial reasons.  Historically (read: for the past 10+
years) the only storage mechanism available was an XML file.  So, the
data was read in from the XML at startup, and then when you "saved" your
data it would write out the full XML file.

The SQL database backend was added more recently, but all the core code
assumed all the data would be available in RAM.  So, as a first step in
migrating towards using a DB, the DB is being used just as a datastore
to "replace" the XML file.  The one benefit of this is that data can be
saved to the database immediately.  However, the internals still require
all the data in core.

Obviously, moving forward, we will try to rectify this, but for now it
is what it is.  Changing it now would have delayed the feature even
longer.

> Well I'm not sure what the purpose of the developers, but if for medium and
> large enterprise, I suggest you do not load all data in memory (change by
> period, month), to open around 50,000 trasações, it takes around 5 minutes to
> 15 minutes (When everything is fine, usuarly 25 minutes). Well that is the
> 50,000 transactions a month working for some companies.

We're not targeting medium or large enterprises. We're targeting
Personal and SOHO businesses.  I.e., we're targeting the users of
Quicken, Money, and Quickbooks, not Peachtree or SAP.

If you have 50,000 transactions a month, GnuCash is *NOT* the solution
for you.  You should look at an Enterprise solution, like GnuE (if it's
still alive).

> Referring to the database, especially when postgres instead of using the DBI
> driver, why not directly use the functions in postgres, causing them to call
> from within GnuCash (Or create a file for calls), do not understand why the
> data need to be loaded into ram and that is a database.

We want to allow multiple databases.  In fact, Postgres is only #3 on
the list -- SQLite is #1.  But instead of coding directly to SQLite we
coded to DBI so that we would enable the use of multiple databases.
This lets you use whichever you want for your environment.

See above about loading into RAM.

> Multiple users, usually in a company if you need simultaneous access to the
> database, I read that implementation will not occur or is in version 2.4.

Correct.  Again, it's a hard problem based on our internal structures.
Not that we don't want to support it, but 2.4 is an incremental step
towards supporting it.  Would you rather get 2.4 now as a single-user
system with DB support, or wait another 2-3 years to get it with
multi-user support?  Personally, I'd rather get 2.4 out now single-user,
and then we can work on multi-user for 2.6 or 3.0.

> Well as I said at the beginning am not a programmer, much less understand the
> development of GnuCash. But I would make these suggestions.

Thank you for your suggestions.

> Thank you for listening.
>
> Have a nice day!
>
> Gabriel Bortolotto
> Ouvir
> Ler foneticamente

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available