Database structure : How to design the track system of a railway station

Question

Dear Oracle experts,
I'm interested in your opinion about a database design problem.
I want to design a database which describes e.g. the tracks of trains in
a big railway station with many switches. What I always know is the position of every switch in my railway station.
If I know all of the present switch-positions I know automatically where a train which is at a certain position would move.
In my database I would like to store these pathways and search the pathway of train at a certain position and the present switch positions.
One problem is that if one of the switches is at a position which leads to a pathway which would the train drive round the next switch the position of the next switch would be uninteresting. Since I have to search the table with my pathways with my set of switch positions I willl have to put datasets for all positions of the circumscribed switch
into my table.
Exampel :
I have 3 switches. If switch 1 is at position 1 switch 2 is circumscribed and the train drives to switch 3. If switch 1 is on position 2 the train drives to switch 2. If switch 2 could have 10 positions then I would have to create datasets for all the 10 positions of switch 2 for all positions of switch 1 although these positions are not always interesting.
To solve this problem I would like to describe some kind of search tree in my database structure. Does someone of you have an idea how to solve this problem ?
Best ragards,
Daniel

Answer 1

Hirachical is interesting, but you pay a big performance/feature penalty by using it.
If this is a real train station, then changes probably won't be done on the tracks for a long time, and if so, it's a rare event that your program may not need to be able to handle dynamically?
If that, then your DB becomes simple ... have a table of tracks coming into the station, and another list of tracks going out. Maybe also "destination tracks" within your station.
Then simply have a table that takes a source/destination pair of tracks, and then a column for each switch. The column holds the setting of the switch to provide the path between source and destination.
Then you have a simple and fast query access. It's rather easy to turn the table for reporting if you want a more dynamic query access; but I guess your main need for the system is to ask "what do my switches need to be set at if a train needs to go from point A to point B". If so, a simple table layout as above is going to be your solution. And it's going to be fast and efficient.
Only if you dynamically want to be able to design the track layout does this become a harder problem. But you could still use the same "construct":
Table: Destination Pairs
PairID Number
FromTrack Number references tracks
ToTrack Number references tracks
Table: Switch settings
SwitchID Number references Switches
PairID number references Destination Pairs
SwitchSetting number
primary key: SwitchID, PairID
Now your query is a join - but it's possible to simply list all the switch settings on a given pair. No need for hirachical queries.