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
