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