best solution to store data
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
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 <r.wobben@home.nl> 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
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 <r.wobben@home.nl <mailto:r.wobben@home.nl>> 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
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 <r.wobben@home.nl <mailto:r.wobben@home.nl>> 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
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 <stepharo@free.fr> 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 <r.wobben@home.nl> 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
Yep, the binary approach is a bit more fragile and less interoperable. STON, JSON or XML are all fine with such a small domain I imagine. On Tue, Sep 2, 2014 at 12:31 PM, stepharo <stepharo@free.fr> wrote:
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 <r.wobben@home.nl> 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
seeing that use case is really small, I would probably try the simplest approach possible. Something like sandstonedb can make the trick here :) http://smalltalkhub.com/#!/~gnaritas/SandstoneDb Esteban On 02 Sep 2014, at 14:31, François Stephany <tulipe.moutarde@gmail.com> wrote:
Yep, the binary approach is a bit more fragile and less interoperable. STON, JSON or XML are all fine with such a small domain I imagine.
On Tue, Sep 2, 2014 at 12:31 PM, stepharo <stepharo@free.fr> wrote:
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 <r.wobben@home.nl> 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
When I was coding in Python for small local databases SQlite was recommended , I only have played briefly with it but it looked to me fairly easy to use and with a very good performance. But I dont know how well it works in Pharo, so maybe someone can jump in and tells us about it . On Tue, Sep 2, 2014 at 3:49 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
seeing that use case is really small, I would probably try the simplest approach possible. Something like sandstonedb can make the trick here :)
http://smalltalkhub.com/#!/~gnaritas/SandstoneDb
Esteban
On 02 Sep 2014, at 14:31, François Stephany <tulipe.moutarde@gmail.com> wrote:
Yep, the binary approach is a bit more fragile and less interoperable. STON, JSON or XML are all fine with such a small domain I imagine.
On Tue, Sep 2, 2014 at 12:31 PM, stepharo <stepharo@free.fr> wrote:
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 <r.wobben@home.nl> 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
On Tue, Sep 02, 2014 at 03:55:50PM +0300, kilon alios wrote:
When I was coding in Python for small local databases SQlite was recommended , I only have played briefly with it but it looked to me fairly easy to use and with a very good performance. But I dont know how well it works in Pharo, so maybe someone can jump in and tells us about it .
Give it a spin: http://www.samadhiweb.com/tags/sqlite http://ss3.gemtalksystems.com/ss/NBSQLite3/ Pierce
ah yes thats it , thanks Pierce . It may come handy for my project Ephestos, though I prefer to keep things inside the Pharo image personally. On Tue, Sep 2, 2014 at 4:04 PM, Pierce Ng <pierce@samadhiweb.com> wrote:
On Tue, Sep 02, 2014 at 03:55:50PM +0300, kilon alios wrote:
When I was coding in Python for small local databases SQlite was recommended , I only have played briefly with it but it looked to me fairly easy to use and with a very good performance. But I dont know how well it works in Pharo, so maybe someone can jump in and tells us about it .
Give it a spin:
http://www.samadhiweb.com/tags/sqlite http://ss3.gemtalksystems.com/ss/NBSQLite3/
Pierce
problem with relational databases is that they do not match really well with object models. nowadays you have a lot of cool solutions that allow you to avoid them (several document-oriented databases, object-oriented, etc.) 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! Esteban On 02 Sep 2014, at 15:18, kilon alios <kilon.alios@gmail.com> wrote:
ah yes thats it , thanks Pierce . It may come handy for my project Ephestos, though I prefer to keep things inside the Pharo image personally.
On Tue, Sep 2, 2014 at 4:04 PM, Pierce Ng <pierce@samadhiweb.com> wrote: On Tue, Sep 02, 2014 at 03:55:50PM +0300, kilon alios wrote:
When I was coding in Python for small local databases SQlite was recommended , I only have played briefly with it but it looked to me fairly easy to use and with a very good performance. But I dont know how well it works in Pharo, so maybe someone can jump in and tells us about it .
Give it a spin:
http://www.samadhiweb.com/tags/sqlite http://ss3.gemtalksystems.com/ss/NBSQLite3/
Pierce
Hi, It depends⦠how? which framework do you want to use? if you use sandstonedb, you can check this old post from Ramon Leon (its author): http://onsmalltalk.com/sandstonedb-simple-activerecord-style-persistence-in-... is old, and related to squeak⦠but it still works :) if you use Voyage (and then MongoDB), you can check the documentation section here: http://smallworks.eu/web/projects/voyage and specially the "Voyage chapterâ, from Johan Fabry, here: https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSuccess... finally⦠if you chose a relational approach, there are several ways to do it, but you could use Glorp and PostgreSQL, and then you can take the article Sven released yesterday as an example )it just came out from the oven): https://medium.com/@svenvc/reddit-st-in-10-cool-pharo-classes-1b5327ca0740 sadly, for sqlite I cannot help you, but someone from this list will have some tips, for sure :) cheers, Esteban ps: btw⦠a common mistake from people coming to pharo for the first time is to carry with them the way of thinking of other environments. For example, to take a decision of which persistence storage use before having clear the design and demands of the applications. I would postpone that decision until you have a clear view of your needs. I usually do that by using Voyage-Memory (a set of voyage that allows you to keep the data in a singleton, but in an ordered way), and then, when I know how my app will behave, I decide what to use :) On 02 Sep 2014, at 16:32, Roelof Wobben <r.wobben@home.nl> wrote:
Hello Estaban.
Do you have a tutorial or a example how I can store my data in objects.
Roelof
Esteban Lorenzano schreef op 2-9-2014 15:23:
problem with relational databases is that they do not match really well with object models. nowadays you have a lot of cool solutions that allow you to avoid them (several document-oriented databases, object-oriented, etc.)
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!
Esteban
On 02 Sep 2014, at 15:18, kilon alios <kilon.alios@gmail.com> wrote:
ah yes thats it , thanks Pierce . It may come handy for my project Ephestos, though I prefer to keep things inside the Pharo image personally.
On Tue, Sep 2, 2014 at 4:04 PM, Pierce Ng <pierce@samadhiweb.com> wrote: On Tue, Sep 02, 2014 at 03:55:50PM +0300, kilon alios wrote:
When I was coding in Python for small local databases SQlite was recommended , I only have played briefly with it but it looked to me fairly easy to use and with a very good performance. But I dont know how well it works in Pharo, so maybe someone can jump in and tells us about it .
Give it a spin:
http://www.samadhiweb.com/tags/sqlite http://ss3.gemtalksystems.com/ss/NBSQLite3/
Pierce
When I was coding in Python I was using dictionaries a lot. I have made a tutorial about them here https://www.youtube.com/watch?v=MmTxJ_VBrIA&list=PLqbtQ7OkSta0ULYAd7Qdxof851... Esteban I have instictive dislike since databases that started 23 years ago when I was taught Dbase a database language that was popular at the time in a private school for coding. Party because the teacher was really bad but mostly because I don't like anything that is not a true programming language. So I am 100% for keeping everything objects. On Tue, Sep 2, 2014 at 5:32 PM, Roelof Wobben <r.wobben@home.nl> wrote:
Hello Estaban.
Do you have a tutorial or a example how I can store my data in objects.
Roelof
Esteban Lorenzano schreef op 2-9-2014 15:23:
problem with relational databases is that they do not match really well with object models. nowadays you have a lot of cool solutions that allow you to avoid them (several document-oriented databases, object-oriented, etc.)
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!
Esteban
On 02 Sep 2014, at 15:18, kilon alios <kilon.alios@gmail.com> wrote:
ah yes thats it , thanks Pierce . It may come handy for my project Ephestos, though I prefer to keep things inside the Pharo image personally.
On Tue, Sep 2, 2014 at 4:04 PM, Pierce Ng <pierce@samadhiweb.com> wrote:
On Tue, Sep 02, 2014 at 03:55:50PM +0300, kilon alios wrote:
When I was coding in Python for small local databases SQlite was recommended , I only have played briefly with it but it looked to me fairly easy to use and with a very good performance. But I dont know how well it works in Pharo, so maybe someone can jump in and tells us about it .
Give it a spin:
http://www.samadhiweb.com/tags/sqlite http://ss3.gemtalksystems.com/ss/NBSQLite3/
Pierce
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
On 2/9/14 13:01, Roelof Wobben wrote:
Thanks.
Could Magna also be a good solution ?
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).
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 <r.wobben@home.nl <mailto:r.wobben@home.nl>> 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
On 2 September 2014 22:02, stepharo <stepharo@free.fr> 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
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 <r.wobben@home.nl <mailto:r.wobben@home.nl>> 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
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 <r.wobben@home.nl <mailto:r.wobben@home.nl>> 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
Esteban talked about Voyage at ESUG, its on the list of talks here: http://goo.gl/E1VF53 You can of course scale up to Gemstone (or indeed start with that as well if you need something more commercial and supported - there is a Gemstone talk in that link as well). Tim On 2 Sep 2014, at 07:17, Roelof Wobben <r.wobben@home.nl> 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
What about transactions and ACID things with voyager and Mongo? Ing. Pablo Digonzelli Software Solutions IP-Solutiones SRL Metrotec SRL 25 de Mayo 521 Email: pdigonzelli@softsargentina.com pdigonzelli@gmail.com Cel: 5493815982714 ----- Mensaje original ----- De: "Tim Mackinnon" <tim@testit.works> Para: "Any question about pharo is welcome" <pharo-users@lists.pharo.org> Enviados: Martes, 2 de Septiembre 2014 6:33:26 Asunto: Re: [Pharo-users] best solution to store data Esteban talked about Voyage at ESUG, its on the list of talks here: http://goo.gl/E1VF53 You can of course scale up to Gemstone (or indeed start with that as well if you need something more commercial and supported - there is a Gemstone talk in that link as well). Tim On 2 Sep 2014, at 07:17, Roelof Wobben < r.wobben@home.nl > 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
there is no such thing as ACID or transactions in MongoDB, and therefore also not in Voyage. instead, for MongoDB each commit is atomic. It happens or it doesnât :) Esteban On 02 Sep 2014, at 16:46, Pablo R. Digonzelli <pdigonzelli@gmail.com> wrote:
What about transactions and ACID things with voyager and Mongo?
Ing. Pablo Digonzelli Software Solutions IP-Solutiones SRL Metrotec SRL 25 de Mayo 521 Email: pdigonzelli@softsargentina.com pdigonzelli@gmail.com Cel: 5493815982714
De: "Tim Mackinnon" <tim@testit.works> Para: "Any question about pharo is welcome" <pharo-users@lists.pharo.org> Enviados: Martes, 2 de Septiembre 2014 6:33:26 Asunto: Re: [Pharo-users] best solution to store data
Esteban talked about Voyage at ESUG, its on the list of talks here: http://goo.gl/E1VF53
You can of course scale up to Gemstone (or indeed start with that as well if you need something more commercial and supported - there is a Gemstone talk in that link as well).
Tim
On 2 Sep 2014, at 07:17, Roelof Wobben <r.wobben@home.nl> 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
Hello,
I want to try to make a financial app for a organisation.
We want you do succeed :)
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.
Indeed the number are low. So this is good because you can use simple approaches.
What are my options for storage of those data.
I could use a database , but I wonder if there are more and better options.
You can use Voyage and MongoDB. Cheap and nice. You can use STON (text based serialisation). You can use Fuel (really fast serializer) but this is binary.
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
Forgort to say: It's great to see Pharo apps coming to business world ! keep on. I wish you succeed Alain
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
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:... 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
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.
participants (11)
-
Alain Rastoul -
Alain Rastoul -
Esteban Lorenzano -
François Stephany -
kilon alios -
Pablo R. Digonzelli -
Pierce Ng -
Roelof Wobben -
stepharo -
Stuart Herring -
Tim Mackinnon