On Sun, 17 Dec 2000 21:54:32 EST, the world broke into rejoicing as
Jean-David Beyer <[EMAIL PROTECTED]> said:
> David Merrill wrote:
> >
> > On Sun, Dec 17, 2000 at 08:49:02PM -0500, Jean-David Beyer wrote:
> > > Christopher Browne wrote (in part):
> > > >
> > > > This is something that is indeed appropriately generated in the "engine
,"
> > > > not in the DB; the relevance to the DB is to ask whether it can use the
> > > > GUID as one of its keys, and whether or not the DB supports foreign key
s.
> > >
> > > What is this "foreign key" stuff? [snip]
> > >
> > > Whether you consider that field to be a foreign key or not depends on
> > > whether or not it is the primary key of another table, relation, or
> > > whatever you want to call it. Even then, you would not need to declare
> > > it to be a foreigh key unless you want to enforce the relationship
> > > between the two tables (which you probably should).
> > >
> > > Or am I missing something?
> >
> > Just that the primary place a GUID is used is as a primary key, and
> > foreign keys in those tables' child tables.
> >
> So of course an rdbms would support foreign keys, and this is a
> non-issue, right?
That assumes that MySQL is not considered to be an RDBMS that would be
a candidate. Its lack of foreign key support is fairly conspicuous...
And the issue is _quite_ to the point, irrespective of anything
having to do with MySQL.
The examination of DB schema has thus far concentrated on what the
field types need to be; that is important enough, but only goes half
way towards describing the data.
The _next_ thing that needs to be done is to outline the relationships
between table entries.
Assuming "standard" SQL, that might be outlined in the form of a number
of foreign key relationships.
Supposing the SQL is "dumbed down" to the lowest common denominator
form supported by MySQL, that means that we need to establish what the
relationships are that the _engine_ will have to manage.
What may ultimately prove necessary is to build something like CORBA
IDL that outlines the operations supported by the engine.
Something looking something like the following:
module GnuCash {
struct Commodity {
string fullname;
string namespace;
string mnemonic;
string exchange;
long long numerator;
long long denominator;
};
interface Accounts {
enum AccTypes { BANK, STOCK, CREDIT, INCOME /* and others */ };
typedef sequence<Account> AccountList;
struct Account {
string GUID;
string accountName;
string accountCode;
string description;
AccTypes accountType;
Commodity currency;
Commodity security;
long currencyscu;
long securityscu;
AccountList parent;
AccountList children;
Splits::SplitList splits;
};
add_account (in Account Acc);
add_accounts (in AccountList Accs);
find_account (in string GUID, out Account Acc);
search_accounts (in string name, in string code,
in string descr, in AccTypes acctype,
out AccountList Accs);
/* There perhaps ought to be a more flexible search, allowing
constructing a complex search. Perhaps even including an SQL
query string. */
};
interface Transactions {
/* Define a "transaction" structure */
/* And operators to query and update them */
generateGUID (in string hostname, out string GUID);
};
interface Splits {
/* Localizing the definition of a "split" */
/* And defining SplitList, referred to up above */
/* Although it's perhaps *NOT* meaningful to publish
operations for Splits as such; that should instead probably be
tied to transactions. You don't, not publicly, update splits.
Instead, you update complete transactions */
};
};
--
(concatenate 'string "cbbrowne" "@ntlug.org")
<http://www.hex.net/~cbbrowne/>
VERITAS AETERNA -- DON'T SETQ T.
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
