SQL, lite lite lite

[Aaron Brady]

On Dec 30, 11:16 am, prueba... at latinmail.com wrote:
> On Dec 29, 1:06 pm, Aaron Brady <castiro... at gmail.com> wrote:
snip
> > My idea is to create a 'Relation' class.  The details are basically
> > open, such as whether to back it with 'sqllite3', 'shelve', 'mmap', or
> > just mapping and sequence objects; what the simplest syntax is that
> > can capture and permit all the basics, and how much and what else can
> > fit in at that level; how and whether it can include arbitrary Python
> > objects, and what constraints there are on them if not; how and
> > whether to permit transactions; and what the simplest and coolest
> > thing you can do with a little Python syntax is.
snip
> You really do like to reinvent the wheels do you? :-) Nothing wrong
> with that. Just be aware that most people that really need what you
> are proposing are probably already using mature feature rich libraries
> for that.
>
> http://wiki.python.org/moin/HigherLevelDatabaseProgramming

Look at these options!  Who invents the wheel?  Naturally, I've had
time to master every one.

The page on Dee reminded me that there was some relational algebra
early on in the databases course.  I'd forgotten.  Maybe I wouldn't
feel so sheepish if I'd tried starting there, to see exactly what I
need.

It's possible that if I had a real goal, it could drive the
requirements for my Relation class.  I don't.  What I have is very
vague, somewhat second-hand, and also inspired by a tangent in a
recent thread here on c-l-databases, er, -py.

You remember the days of parallel arrays before records were
invented.  The bare minimum I can think of for a relation is just a
set of tuples.

TakingClass( Arthur, Science )
#TakingClass.add( ( Arthur, Science ) )

It's just that 'what classes is Arthur taking?' is an O( total ) op.
Next is a parallel mapping.

TakingClass( Arthur, Science )
# science.add( arthur )
# arthur.add( science )

O( key ) read and O( 1 ) add, but it's repetitious.  I feel it's
really error prone, but maybe it's the best balance.  The actual
abstraction is something more like this:

# Emps( Name, EmpID, Department )
Emps( KnightsOfNi, NiNiNi, Gardening )
# tupA= EmpsTuple( KnightsOfNi, NiNiNi, Gardening )
# KnightsOfNi.add( tupA )
# NiNiNi.add( tupA )
# Gardening.add( tupA )

(If KnightsOfNi will appear in more than one relation, it will need to
distinguish: 'KnightsOfNi.emps.add( tupA )'.)

A single predicate is just a set.  A relation is just a set of tuples.

Dee lets you write lambda expressions for filters/selects.  Django
lets you chain selects with a double underscore.