Suggestions

[ALbert Gráfica - Suporte]

Derek
John

Guys, thanks for the clarification.

Well regarding the personal use of the application, is really very good.
But unfortunately I can not use it in the company where I work, which
was the focus of the questions.

For now the only thing I can wish you is good luck, and say that despite
not using it in the company, I think the design is very good of you, and
can easily be used for personal finance, presenting a good yield.

Thanks for all the attention Dispencer. This can not be saying anything
just praise, because almost immediately you were answering my questions
and statements.

Em 03-12-2010 12:58, Derek Atkins escreveu:
> 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
>