database

[MisterX]

no offense. no boasting...

I did the relational lookup in FMP, and it took minutes!

So I opted for a double-linked-list of records (this was a hierarchical
database - the relations were previously based on a parent id but searching
this was horribly slow...

So I made the search implicit by pre-creating the fetch index to the 
information. The relational didn't become flat but almost... 

The DBF database this came from originally was just as fast... Which tells
you lots about how macs were seen by the guy who hired me... 

Im sure it wouldn't compete in the real world though, then again for a
minimal
functionality DB it did work wonders and it hardly used any xternals ;)

cheers
Xavier

> -----Original Message-----
> From: use-revolution-bounces at lists.runrev.com 
> [mailto:use-revolution-bounces at lists.runrev.com] On Behalf Of 
> Ruslan Zasukhin
> Sent: Monday, October 24, 2005 4:59 PM
> To: use-revolution
> Subject: Re: database
> 
> On 10/24/05 5:37 PM, "xavier.bury at clearstream.com"
> <xavier.bury at clearstream.com> wrote:
> 
> > Not to say Lynn is wrong but if a database is well 
> organized in terms 
> > of functionality, it can beat the pants of a compiled 
> database which 
> > woudl suffocate with too much information.
> > 
> > Call it the space-folding starship...
> > 
> > Before valentina existed, i had to port a database from a 
> PC to Macs 
> > for a professional product.
> > Some 700000 records with relational links on which FileMaker just 
> > choked...
> > 
> > It took HC 3 days to import the data but after that it was 
> 2 seconds 
> > access even on a CDROM...
> 
> When you say: 2 seconds access. You NEED to say for which operation.
> 
> EXACT VALUE SEARCH:         WHERE fld = 55
> is 100-1000 times more easy than RANGE search  WHERE fld > 55
> 
> Even FileMaker can do EXACT search very fast. Really, this is 
> just few steps in the b-tree. No miracle here.
> 
> But if you do RANGE search again 2 cases:
> 
>     * few records found
>     * almost all records found.
> 
> Most dbs in second case start think very long.
> RANGE search is where Valentina shines.
> 
> BTW, SqlLite do not search all records never. They just 
> search first record which satisfy RANGE search, and stop. 
> When you do NEXT record they do search next one.  They can do 
> this only because they have claim: we are single used db. 
> This is why it is not possible right _correct_ server around 
> SqlLite. It can return few correct results, but also incorrect.
> 
> > But preparing the information was paramount for this trick which we 
> > can't all afford...
>  
> > Surely if i had Valentina then, i could have said it choked on that 
> > many records... ;)
> 
> Nope. :-)
> This is tiny db for Valentina. Again story which I love.
> 
> Marco did have 28 million records in table (20Gb db). 
> Valentina did answer in 0.2 seconds. On hardware as MAC G3 or 
> G4 it seems.
> 
> IMHO problem will all such home-made dbs is that developer 
> have made it to solve his tasks in one project. HE do not 
> care about tasks which YOU can meet in YOUR project.
> 
> Compare, To implement SQL92 in Valentina 2 have we have spend 
> about 3 developer-years I think.
> 
> 
> > And any database can be tuned for optimum performance one way or 
> > another for specific data sets...
> 
> Let me re-arrange this:
> 
> * for ANY db it is possible to develop more optimized 
> structure if "to think". :-) 
> 
> * but any db have own limit of power. Like a car or airplane.
> 
> --
> Best regards,
> 
> Ruslan Zasukhin
> VP Engineering and New Technology
> Paradigma Software, Inc
> 
> Valentina - Joining Worlds of Information http://www.paradigmasoft.com
> 
> [I feel the need: the need for speed]
> 
> 
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage 
> your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution