Table structure?

[Joakim Schramm]

Ruslan, 

> > 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?
> 
Size of DB grow when adding records yes, that's quite logical.

> It seems you say that it have grow too much ?
> But you compare to what ??
> 
To how it was before with my Primary and Foreign Keys. Before I setup links
I added all data to db including fields for keys, primary and Foreign. This
db is about 55MB. Adding Blinks, two table pairs with 1:M and one table pair
M:M, removing old Primary and foregin keys and compacting db ends at 204MB.
A point though, of the M:M I was only able to process about 2000 of about
207 000 "Owner" records before the demo limit time trow me out, so if all
those was processed db will become enourmous in size.

But it's quite possible I do this in wrong way!

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

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

Yes I see my first Blink is 4788K, second 5680K and third 145.54M (the not
completed one)

> > 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'm not sure what you mean by this, the records was added first then they
have been traversed through and links set up. There is about 207 000 places
and 243 000 zone records.

> > 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.
> 
Ok.

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

Yes this is what I think is wrong in structure, but the relation between the
2 tables are a bit odd.

> 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 ?
> 
Yes I will have a look at it now, after reading your other emails. I have
been out in the forest all day.

Joakim
> 
> --
> 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]
> 
> 
> _______________________________________________
> Valentina mailing list
> Valentina at lists.macserve.net
> http://lists.macserve.net/mailman/listinfo/valentina
>