EDB from a system designer's viewpoint
posted by: shenpen at freemail.hu
Hi!
I'm new to EUPHORIA. I like it very much, because it seems to achieve the
impossible: to be simple and elegant, but still able to get close to the
machine if needed. I'm quite enchanted that only one step under the
elegant EUPHORIA library routines there is usually a machine_proc()
or machine_func() - this is the way things should be in all languages... 
I'm actually more of a system designer (SD) than a programmer, so what I'm
most interested in is the EDB. Well, it seems a bit "untraditional" to me.
So let me ask how traditional relational SD issues are
usually handled in EDB.
1) Keys.
What EDB call "key" is what SD's usually call "primary key" - "the
thing that must unique in all records in a table". Let's suppose you have an
accounting/business software. Invoicing, inventory management etc.
You put the items you sell in a table. Let's suppose just three fields:
Item No., Description,Sales Price. Item No. is uniqe, so it's the (primary) key.
But you should maintain a secondary key (in other words: an index) for the
Description, to be able to quickly show your items on screen in ABC-order.
You don't want to use a sorting algorithm every time - try to sort ten thousand
items in ABC order and you will see why. How to maintain secondary keys
(indexes)
in EDB?
2) Transaction management, commit/rollback features.
Let's suppose you sell something with an invoice. You have two choices:
Your accounting software should:
- insert a record in the Issues Invoces table (and print it)
- insert a record in the Customer Entry table to show the change of
the customer's balance
- insert a record in the Inventory Movement Entry table to show the change
of inventory
- insert records in the General Ledger Entry table
and check many, many things in the way. This 4 inserts and one
printing is called a transaction.
Now, let's suppose some problem happens in the process: the customer is over the
credit limit, you have
no inventory, or someone pulls the plug of the computer off the wall.
In this case, NONE of the above 4 inserts and 1 printing may happen or else you
have
and inconsistent database or the Tax Office takes your head for
printing and invoice but not booking (posting) it in your accounting database.
So you must first put these records and the printing process into some
kind of buffer, check everything, and insert and print them in one step -
it's called commiting (or flushing) the transaction.
Or if some problem occurs, you insert nothing and print nothing - it's called
rolling back the transaction.
How to do it in EDB?
3) Multi-user features - locking.
One of the key points of having a multi-user database is the above-mentioned
transaction management. For example, you may see an inventory of 1 of some item,
but it may be sold by someone else in the middle of your invoice issuing process
if she pressed "Issue" button 0,00000001 seconds earlier. In this case, you must
roll
back the transaction, give an error message etc.
Anothe issue is locking. You issued an invoice, and the software got to the
point of inserting Inventory Movement Entries. The key of this table is
something like "Entry No.", an integer, which must be in strictly growing
order by 1 without any holes, or else the Tax Office will think you deleted
some entries to cheat with the tax. So what you do? Create the records in the
memory of your computer, lock the Inventory Movement Entry table, find the last
record, assign
next Entry No. to your record and insert it, and then unlock the table.
(If you have many users, you even need record-level locking like in MS SQL.
But even table-level locking could be a good compromise for less than 50 users.)
It seems EDB supports only database-level locking - it means while you insert
Inventory Movement Entries to sell stuff, someone else can't post Fixed Asset
depreciations (which has absolutely no effect to the Inventory Movement Entry
table) in the General Ledger Entry table. It means that over 10 users they
will hate the software. Or is there another way in EDB?
bye,
Miklos Hollender
System Designer / Developer
Budapest, Hungary
|
Not Categorized, Please Help
|
|
