Re: Resiliency To New Data Requirements

Neo wrote:
> After implementing the prior solutions, we find we need to store each
> department's attributes thus requiring a separate table.
>
> RMDB:
> CREATE TABLE dept (deptID, name, ...);
> INSERT INTO dept (1, finance);
> INSERT INTO dept (2, safety);
> INSERT INTO dept (3, personnel);
> INSERT INTO dept (4, marketing);
> Update employee_dept table, replace field dept with deptID, update
> data.
>
> Update Query:
> SELECT employee.*
> FROM (employee INNER JOIN employee_dept ON employee.empID =
> employee_dept.empID) INNER JOIN dept ON employee_dept.deptID =
> dept.deptID
> WHERE (((dept.name)="safety") AND ((employee.salary)=20000));
>
>
> DBD:
> No change. Original query still ok, returns Mary.
> (and (select employee instance *)
> (select * dept safety)
> (select * salary 20000))
>

(You ain't still smokin' that ditch-weed, are you, Neo?)

So, which parts of all these are the lambda analogs?

Maybe, instead of pounding in some not-quite SQL, you could write some cons ( cdr ( ... stuff that might illustrate what all the chicken scratching and ju-ju are doing...

A number of us are still hanging -- trying to see whether the lights will go on -- but it's still pretty dark where I'm sitting. Received on Thu Aug 03 2006 - 00:45:01 CEST