Smart3D Episode #4 — The Answer is 2…

all rite! But what’s the Question?! Go on if you don’t afraid of databases.

As written earlier (Episode #1) we store our content in a database. Really just one? To learn more, read Episode #4, please… oops, endless recursion!

Now, seriously, this Episode is about the number of databases that should be involved to create a 3D product presentation at run-time.

Obviously, there’s a minimum: one. There’s nothing wrong with putting all and everything into one, self-contained database. However, at the end of the day, this can result in an unmanageable amount of entities. So, one may wish to split content into different databases, maybe separated by manufacturers or product collections, for instance. If you do so you’ll face sooner or later a Sharing issue: you want to use entities from one database in several other databases, i.e. the classic 1:n relation, on entity level.

Okay, easy, so lets allow M databases via external/run-time reference and N databases to be replicated over nite, into our specific database! Sorry, but Mission Impossible! Maybe this works nice under laboratory conditions, for research mockups, etc. but we need to consider industrial processes! And here is Not everything that Can be done Should also be done.

So, finally, how many databases should be involved for one product? We believe: 2 — the primary or Project database that defines the product and a secondary database, the so-called Support database. So you have exactly one chance to share things (geometries, textures, shaders, scripts, etc.) — put them into the associated Support database. We found this an optimal solution to the redundancy vs. complexity trade-off. Well, you still can use [partial] replication of further databases but that’s your turn, then.

Both data-creation and processing tools then merge these two databases at run-time, using the best data merge technology ever: LINQ! (Please believe this for now or put on stack at least, there will a separate Episode on LINQ vs. SQL some day…)

In the data-creation tools, access to the Support database is read-only, for good reason! But then, how you can ever manage a support DB with those tools? Easy, connect it as a Project database! Sounds like endless recursion? No! There can be databases w/o a Support database.