Re: why hierarchy?
Date: 28 Jul 2006 11:31:31 -0700
Message-ID: <1154111491.824366.37660_at_s13g2000cwa.googlegroups.com>
Neo wrote:
> > Basic Requirements: A business has many staff members (with full names
> > and a start date), some of whom are direct supervisors over other staff
> > members. The business has many clients (with full names), and each
> > client is registered on a specific date by a specific staff member.
>
> Ok, please specify a specific data for the above.
>
The data values are not part of the initial specifications. I suppose you could generate some test data, but ultimately, the client wants the freedom to write their own application input forms for data entry. Is dbd incapable of application and data storage independence? If so, bummer.
> > Constraints: ...
>
> Currently dbd doesn't implement user/app-defined constraints. To do so,
> one would need to write an application in C/C++ which calls dbd via its
> API. Some code examples at www.dbfordummies.com/Example/Default.asp
>
Does dbd have no framework for enforcing constraints - so the client must encode all business requirements explicitly into every application form that interfaces with the dbd database? If so, bummer.
One of the "new surprise" requirements was going to be "add Salary to each staff member" and "allow for pre-specified users to see salaries, but others not to". How would dbd hold up to that requirement?
Um, idea being, you'd show us what the query would look like...
>
> > Q: We need to make some staffing cuts. List all current employees who have signed less than 10 clients in the past month, in order of seniority.
>
> Currently, dbd's select statements do not perform math operations,
> sums, total, etc. For example, find all person who were hired after
> 1/1/06. It can do something similar, find all current employees who
> have signed clients X, Y and Z on Date1, Date2, and have senority A, B
> and C.
No aggregation, mathematics, or ordering? Bummer. Received on Fri Jul 28 2006 - 20:31:31 CEST