Table structure?

Ruslan Zasukhin sunshine at public.kherson.ua
Mon May 1 13:49:24 CDT 2006


On 5/1/06 12:43 PM, "Joakim Schramm" <joakim at astrocalc.com> wrote:

> "Another Example. Here we have five tables which must be linked as M : M.
> Using relational model or even ObjectPtr fields, developer need create 4
> Tables that play role of links. Now compare to the second picture where this
> task is solved using BinaryLinks.
> 
> You have now only five tables instead of nine. But yes. You have now 4
> BinaryLink objects. Have you win something? Answer is yes. Because
> BinaryLink use about 2 times less of disk space than Table-Link and it is at
> least 2 times faster."
 
> Is this really true?

Yes :-)

> I managed to establish binary links between my tables,
> and for the links Country->Places DB size grow 4.6 MB, for Country->Zones
> 5.2 MB and for Places->Zones, which has to be M:M as there is many places in
> zones and there is many zone records for many places,

So you have add records into binary links, and size of db grow.
This is normal right?

It seems you say that it have grow too much ?
But you compare to what ??

Have you remove your OLD KEY-PTR fields ?
After remove of fields you may also need do COMPACT.

Btw, Vstudio can show total size of a BLink in bytes.

> I just came to about
> 2000 places of 220 000 before the demo limit of 10 minutes stoped it and
> then DB had increased with anouther 145 MB!? Removing my old key fields and
> compact DB just removed about 5MB.

Hmm, so you have add 2000 places into SOME binary links, right?
HOW MANY records was added?
 
> I think Binary links is good, but maybe not for this sceenario. Maybe better
> to split zone files into one for each country, and/or maybe better to use
> ObjectPtr? 

Currently ObjectPtr will win in case of 1:1 and 1:M, but binary link 100%
wins the MM third table.

We need YET do (simple in fact) optimization, so binary links of 1:1 and 1:M
will be EXACTLY as ObjectPtr by size.

> This is how the original data structure is in text files, which I
> read. 1 file for for country names, 1 file for places in each Country (so
> there are many place files), and the same for TimeZone data, 1 file for each
> countrys zone data which can have 1 to 300+ internal sets of date ranges.

You see, you have described strange MM in your case, without third table.

I think the simplest case todo is next:

* make db with binary links,
    add some small amount of records, e.g. 1 country, 10 places, N ...
    now you can see size of db total, and by objects

* make similar db using ObjectPtrs and import THE SAME records

* may be make structure like it was with KEY-PTR

In this way you and me can fast to find where problem is.

Okay ?


-- 
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]




More information about the Valentina mailing list