Table structure?

[Joakim Schramm]

> -----Original Message-----
> From: valentina-bounces at lists.macserve.net 
> [mailto:valentina-bounces at lists.macserve.net] On Behalf Of 
> Ruslan Zasukhin
> Sent: 01 May 2006 13:07
> To: valentina at lists.macserve.net
> Subject: Re: Table structure?
> 
> On 5/1/06 12:43 PM, "Joakim Schramm" <joakim at astrocalc.com> wrote:
> > set criteria for Places to display as displaying 207 000 
> places in one list isn't useful.
> 
> Apple products and other MAC now love to specify filter, User 
> type one or few first letters and list in live mode become small
> 
Yes but loading 207 000 records into a M$ ListBox will take too long time I
think, but never mind this isn't really any problem.

> > So the returned place is connected to a country and this country is 
> > then used to lookup zones belonging to country. Each Place 
> also have 
> > an zone identifier to pair with which of the country's zone to use. 
> > From this zone a value is looked up based on a date and 
> time. The data 
> > and time data is from user input.
> 
> So you have path of search
> 
>     Place -> Country ->
>                          Zone
>           ------------>
> 
Not really, Country is never searched directly, Places are searched, and
places belong to a Country and a TimeZone. However, a country can have more
then one timezone. The timezone data as such is datetime records setting a
point in time for change between normal and daylight saving time (summer
time). This is not my data but data I have purchased, I got it delivered in
a certain way in text files. It's my job then to make use of it in best
possible way. But the relation between the data is pretty clear but it is as
well kind of two foulded.

So again, places is searched for and returned. From pointers in place data
to country and to correct timezone table as value is looked up based on
passed data which is to be compared with dates in table. The relation
between Place and Zone really is M:1 but direction is always from the M side
which makes it a bit akwards. But the 1 side (Zone) actually do consists of
not one but many records. This is why I think my current structure is wrong
at least for use with Binary (and possibly PrtObject) links. I have it
implemented like this now though, using an other type of db which not is
relational but simply process one table at a time and then go on to next.

Nevermind, I will give this some more thinking and test. At this point my
main objective was to learn something about how Valentina works and can be
used. I prefare to do this with real data rather then dummy data.


> When user choose ONE place he expect to get ONE record in result ?
> This is the target of your application?
> 
One (or more) record for a place is return, and user select which to use (if
more then one). From identifyer of this data a second value is looked up
(zone) which in sense is a lookup table. This is also why I think maybe it
can be an idea to split this data up in many tables to simplify things.
Originally it was like all places for each country was in it's own
table/file and all zonedata for each country in it's own file, then it was
easy BUT it didn't allow for searches across places in whole world easily.

> You see, deal is that BinaryLinks now implement the most general case.
> They allow do effective search in both directions.
> 
>     T1 -> T2    and T2 -> T1
>  
> This is one more possible optimization, that when you create 
> a Blink you claim that you need only e.g. T1 -> T2 direction 
> of search. Then Blink wil be exactly 2 times less.
> 
This is exactly what I am after here, I only need to look in one direction.

> I very hope that in nearest few months we will implement all 
> these optimizations. 
> 
Ok that's fine, I think I have some fresh ideas on this now as well.
Yesterday my head was full of all new things with Valentina, now I have
digested it a bit so more space for new things.

> > Did you know by the way that Russia have 76 TimeZones? This 
> is not of 
> > today of course, but my data is not only for today but also 
> historical 
> > AND in the future.
> 
> I still do not know what means TimeZone, and why so many.
> I know only about that earth have 24 hours zone.
> 
In teory yes, but not when used practically and over a spann of time. This
data starts at end of 1800 and there has been many changes upto today.
Nevermind, you don't need to know this :-)

> > Well too nice day today to sit in front of computer so will look at 
> > restructure later, but I think I really need to restructure db but 
> > maybe even then binary links is not right here.
> 
> May be. 
> 
> Until we finish all optimizations, ObjectPtr can be more 
> effective for 1:1 and 1:M types of links.
> 
Yes will look at this.

> Still not clear how you get such big grow of db. I have never 
> see this before.
> 
Neirher me, but we will see, time will show...

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
>