Modelling an Interface table in an OO world.
-
Fresh from the success of my Inheritance question last week, I have another relating to the data behind those objects. Remember I have been using a 1:1 relationship between objects and database tables. I had Routes, Stages and a Many : Many relationship between them coverd by a RouteStage table But the new design will be along the lines
Class CStage
{
Stage details
}Class CRoute
{
Route Details
List List of Stages
}How do I represent this on a relational database. My research is leading me to a term called "Object Impedance". I have ideas for some none-too-pretty methods on the revised CRoute, but I am open to clever suggestions to best represent this scenario.
Ger
-
Fresh from the success of my Inheritance question last week, I have another relating to the data behind those objects. Remember I have been using a 1:1 relationship between objects and database tables. I had Routes, Stages and a Many : Many relationship between them coverd by a RouteStage table But the new design will be along the lines
Class CStage
{
Stage details
}Class CRoute
{
Route Details
List List of Stages
}How do I represent this on a relational database. My research is leading me to a term called "Object Impedance". I have ideas for some none-too-pretty methods on the revised CRoute, but I am open to clever suggestions to best represent this scenario.
Ger
The most common route is to map the OO-objects to a relational model. Your database will need to have it's own design thought out, and preferably, normalized. OTOH, if you're using it merely as a datastore for said objects, then it might be more beneficial to dive into serialization.
Bastard Programmer from Hell :suss: