Smalltalk › Pharo › Pharo Smalltalk Users

best solution to store data

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

32 messages Options

stepharo

Re: best solution to store data

BTW remember that if you charge people for your application, then you will need to pay if you use VW.

Thanks.

Could Magna also be a good solution ?

Saving and loading an object in fuel is two lines of code. So with a little strategy 2014-09-02-Bills-252
you can save fast your data.

Same goes with Voyage. Have a look at the talk about Voyage at ESUG 2014 on youtube.

Stef

Roelof

François Stephany schreef op 2-9-2014 9:11:

If you don't want a separate DB, object serialization with Fuel is an option. It's very easy to serialize a graph of objects to disk.

You can also have a look at SandstoneDB, it's pretty small and some people use it.

Cheers,

Francois

On Tue, Sep 2, 2014 at 8:17 AM, Roelof Wobben <[hidden email]> wrote:

Hello,

I want to try to make a financial app for a organisation.

There are some 50 customers so also 50 invoices a year.
Then the payments . Also 50 a year.

Cash and bank accounts . Every month some 10 - 20 things.

So on my disk on the programm I now use it costs me some 30 - 50 Kb a year.

What are my options for storage of those data.

I could use a database , but I wonder if there are more and better options.

Roelof

stepharo

Re: best solution to store data

In reply to this post by Roelof

Have a look at the PharoForTheEntreprise chapter (I'm in the high speed train - no internet connection).
And there is also the web site of Fuel on rmod.

Stef

On 2/9/14 14:01, Roelof Wobben wrote:

Thanks all.

Is there a good tutorial how I can work with Fuel ?

Roelof

stepharo schreef op 2-9-2014 12:31:

On 2/9/14 09:11, François Stephany wrote:

If you don't want a separate DB, object serialization with Fuel is an option. It's very easy to serialize a graph of objects to disk.

You can also have a look at SandstoneDB, it's pretty small and some people use it.

pay attention that images can get corrupted so I would in addition use a file based approach (STON or whatever).

Cheers,

Francois

On Tue, Sep 2, 2014 at 8:17 AM, Roelof Wobben <[hidden email]> wrote:

Hello,

I want to try to make a financial app for a organisation.

There are some 50 customers so also 50 invoices a year.
Then the payments . Also 50 a year.

Cash and bank accounts . Every month some 10 - 20 things.

So on my disk on the programm I now use it costs me some 30 - 50 Kb a year.

What are my options for storage of those data.

I could use a database , but I wonder if there are more and better options.

Roelof

Stephan Eggermont-3

Re: best solution to store data

In reply to this post by Roelof

Roelof wrote
>I think I wil go for a Magma or a xml approach.

http://wiki.squeak.org/squeak/2665

Magma might be overkill for this amount of data.
Magma needs an upgrade for recent Pharo.
Chris uses it on Squeak and found maintaining
it on Pharo too much work.

With XML you'll need to do more work than with
STON, and the objects will be less readable.

Do you know
https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSuccessfulBuild/artifact/EnterprisePharo.pdf

See: Fuel, Mapless, NeoCSV, JSON, STON, Voyage

Stephan

Alain rastoul

Re: best solution to store data

In reply to this post by Roelof

Hi Roelof,

This is a very broad question with a lot of options, there is no short
answer.

If I had to choose a relational database approach from the beginning,
I would choose Sqlite, it's a very nice db, small, fast, works very well
with Pharo (I used it some time ago with FFI, didn't know about native
boost mapping, it's cool),
can be used with other guis and tools and, should my data or requirements
grow unexpectedly, I could move to Postgresql or some other bigger db
without too much stress.

For an object approach , I would still choose a relational db for
storage (same as previously) with an object relational mapping
framework like Glorp on top of it,
not an object system for storage (magma or gemstone - I'm not saying
that they are bad!).

Beware that relational system (like object systems) will require some
specific skills
at some point (I like relational systems for myself, but very often see
they are widely misunderstood, even by those who develop with).

In any case, if I were you, I would first choose to defer my choice :)
until I have a more detailed idea of what I want/have to do, and I would
start very small with a file based approach (STON) and a Data Access
Layer of my own on top of it, so that I could adapt it to my future
requirements or choices (relational, object or nosql database like mongo).
I would even develop this DAL later and start with a single document
approach (a simple read/write of the whole stuff with STON).

The most important is : don't get lost in underlying technical choices
from the beginning (plus it's bad for health), make choices you can
change. And stay focused on your goal : your application.

my 2c

Regards,
Alain

Alain rastoul

Re: best solution to store data

Forgort to say:
It's great to see Pharo apps coming to business world !
keep on.
I wish you succeed

Alain

Stuart Herring-2

Re: best solution to store data

In reply to this post by stepharo

On 2 September 2014 22:02, stepharo <[hidden email]> wrote:
> For such quantity of information my impression is that it is oversized. May
> be Chris Mueller will reply.
> Now Magma does not work in Pharo (or may be it does but I do not know).

Magma actually scales down pretty well, and given how ridiculously
easy to use it is, it's actually a pretty good fit for small
applications - particularly if you use the standalone mode, rather
than client-server. I definitely wouldn't call it oversized or
overkill.
The biggest problem is as you say, it doesn't work in current Pharo.
The last version I've successfully used it in is 1.3 (and I still have
a couple of running applications with Magma and Pharo 1.3).
I've made a couple of attempts at porting it in the past, but it's a
non-trivial task and lack of time, and lack of a deep understanding of
both Magma itself and the changes in Pharo meant that I never got very
far, and in the end I decided it would be better for me to port my
applications to a different persistence solution. (Currently trying
Oak - but might end up just using Riak directly).

Regards,
Stuart

Roelof

Re: best solution to store data

In reply to this post by Alain rastoul

I know what I want.
The steps that I have to take.

1) Users and user management.

User has username and password.

2) entering and editing plans.

Plans has sort and amount.

3) entering and editing way of payment.

this has name and sort payment

4) Entering and editing customers.

Customers has :

name, adress, city , plan, way of payment.

5) Entering financial accounts.

name, number and so on.

6) Making invoices.

Client data like name ,adress, city , amount to be payed. (depends on
plan), issued data, date before the invoice must be payed, date where
the invoice is payed.

6) Making bank and cash accounts.

date, amount credit, amount debit, description, financial account

Roelof

Alain Rastoul schreef op 2-9-2014 22:23:

> Hi Roelof,
>
> This is a very broad question with a lot of options, there is no short
> answer.
>
> If I had to choose a relational database approach from the beginning,
> I would choose Sqlite, it's a very nice db, small, fast, works very
> well with Pharo (I used it some time ago with FFI, didn't know about
> native boost mapping, it's cool),
> can be used with other guis and tools and, should my data or requirements
> grow unexpectedly, I could move to Postgresql or some other bigger db
> without too much stress.
>
> For an object approach , I would still choose a relational db for
> storage (same as previously) with an object relational mapping
> framework like Glorp on top of it,
> not an object system for storage (magma or gemstone - I'm not saying
> that they are bad!).
>
> Beware that relational system (like object systems) will require some
> specific skills
> at some point (I like relational systems for myself, but very often
> see they are widely misunderstood, even by those who develop with).
>
> In any case, if I were you, I would first choose to defer my choice :)
> until I have a more detailed idea of what I want/have to do, and I
> would start very small with a file based approach (STON) and a Data
> Access Layer of my own on top of it, so that I could adapt it to my
> future requirements or choices (relational, object or nosql database
> like mongo).
> I would even develop this DAL later and start with a single document
> approach (a simple read/write of the whole stuff with STON).
>
> The most important is : don't get lost in underlying technical choices
> from the beginning (plus it's bad for health), make choices you can
> change. And stay focused on your goal : your application.
>
> my 2c
>
>
> Regards,
> Alain
>
>
>

kilon.alios

Re: best solution to store data

In reply to this post by stepharo

I really like Fuel , nice design and easy moving data between images, Pharo Grid Computing for the win :) I am sure it will come handy. Also great work with Pharo for The Enterprise this book is growing and growing and growing will eventual turn into a encyclopedia for pharo :)

On Tue, Sep 2, 2014 at 7:45 PM, stepharo <[hidden email]> wrote:

Have a look at the PharoForTheEntreprise chapter (I'm in the high speed train - no internet connection).
And there is also the web site of Fuel on rmod.

Stef

On 2/9/14 14:01, Roelof Wobben wrote:

Thanks all.

Is there a good tutorial how I can work with Fuel ?

Roelof

stepharo schreef op 2-9-2014 12:31:

On 2/9/14 09:11, François Stephany wrote:

If you don't want a separate DB, object serialization with Fuel is an option. It's very easy to serialize a graph of objects to disk.

You can also have a look at SandstoneDB, it's pretty small and some people use it.

pay attention that images can get corrupted so I would in addition use a file based approach (STON or whatever).

Cheers,

Francois

On Tue, Sep 2, 2014 at 8:17 AM, Roelof Wobben <[hidden email]> wrote:

Hello,

I want to try to make a financial app for a organisation.

There are some 50 customers so also 50 invoices a year.
Then the payments . Also 50 a year.

Cash and bank accounts . Every month some 10 - 20 things.

So on my disk on the programm I now use it costs me some 30 - 50 Kb a year.

What are my options for storage of those data.

I could use a database , but I wonder if there are more and better options.

Roelof

Pierce Ng-3

Re: best solution to store data

In reply to this post by EstebanLM

On Tue, Sep 02, 2014 at 03:23:41PM +0200, Esteban Lorenzano wrote:
> so unless you are really constrained for some reason (like imposition of
> customers), or you have real use cases (like doing complex tabular
> projections), I would always recommend to take another approach than
> relational.
>
> stay in objects as much as you can!

SQLite is very popular, and the relational model well known enough that a lot
of data is available as SQLite database files or easily transformed into them.
When dealing with such data, it is nice to be able to work with SQLite data in
Smalltalk.

Philosophically, I agree with staying in objects as much as possible. However,
right now if I am to build a web app with "real world" storage requirements,
i.e. *not* on the scale of FB or Google, I'd probably go with PostgreSQL, just
by the sheer availability of knowledge and expertise on running a serious
PostgreSQL setup. That, or Gemstone.

Pierce

Alain Rastoul-2

Re: best solution to store data

In reply to this post by Roelof

Great!
As of your requirements there is very few business logic, and lot of
data entry.
With the estimation you gave about data size, I would try STON
straightforward to start prototyping.
see (for example)
http://www.jarober.com/blog/blogView?showComments=true&printTitle=ST_4U_389:_STON_Serializer&entry=3546585097
and EnterprisePharo.pdf, there is a chapter on STON (and lot of other
interesting chapters too).

Example: storing 1000 couples of string (a fake user/password list) of
about 23k of data on disk, takes 70 ms on my laptop.
Quite enough to start your development, as I said earlier no need for a
database from the start, make a DAL for your users storage that write
your user list with STON and modify it later to write to a db.
Simple: the write in itself is 3 lines of code.

| users fileStream |
users := (1 to: 1000)
collect: [ :i |
Array with: ('user',i asString)
with: ('pwd-',i asString) ].
[
fileStream := FileStream fileNamed: 'junk.txt'.
[ STON writer on: fileStream ; nextPut: users .
] ensure: [ fileStream close ].
] timeToRun inspect

HTH

Alain

Alain Rastoul-2

Re: best solution to store data

This example is just about storage, for a real app, dont use Arrays, but
make a User with name and password members, and a UserDAL class that do
the write.

stepharo

Re: best solution to store data

In reply to this post by Roelof

BTW remember that if you charge people for your application, then you will need to pay if you use VW.

Thanks.

Could Magna also be a good solution ?

Roelof

François Stephany schreef op 2-9-2014 9:11:

If you don't want a separate DB, object serialization with Fuel is an option. It's very easy to serialize a graph of objects to disk.

You can also have a look at SandstoneDB, it's pretty small and some people use it.

Cheers,

Francois

On Tue, Sep 2, 2014 at 8:17 AM, Roelof Wobben <[hidden email]> wrote:

Hello,

I want to try to make a financial app for a organisation.

There are some 50 customers so also 50 invoices a year.
Then the payments . Also 50 a year.

Cash and bank accounts . Every month some 10 - 20 things.

So on my disk on the programm I now use it costs me some 30 - 50 Kb a year.

What are my options for storage of those data.

I could use a database , but I wonder if there are more and better options.

Roelof