Design dispute
-
Having a little dispute with a friend about the design of this process - so I'm looking for tdwtf crowd to tell me I'm crazy, or not so much. Working on a multi-tenant system now that has a requirement that when a new company is initialized they get a "Tutorial" database to work with that shows how the system works and what not. So, my solution was to create a seperate database that contains any of this "tutorial" data. Now, when a company is added, I run a stored procedure that will go through all user-created tables and change the primary key, then update all related tables foreign keys. Once this process is done, I can just do basic 'insert into select from' type queries to insert this data.
Naturally this "re-keying" process is pretty processor intensive and has been offloaded to a sandbox server, but it's still somewhat nuts. So - I look to you, tdwtf crowd to set me straight - how would you have fulfilled this requirement, or what's a more friendly approach? Oh yea, and first posting, so be nice :)
-
@bobday said:
Having a little dispute with a friend about the design of this process - so I'm looking for tdwtf crowd to tell me I'm crazy, or not so much. Working on a multi-tenant system now that has a requirement that when a new company is initialized they get a "Tutorial" database to work with that shows how the system works and what not. So, my solution was to create a seperate database that contains any of this "tutorial" data. Now, when a company is added, I run a stored procedure that will go through all user-created tables and change the primary key, then update all related tables foreign keys. Once this process is done, I can just do basic 'insert into select from' type queries to insert this data.
Naturally this "re-keying" process is pretty processor intensive and has been offloaded to a sandbox server, but it's still somewhat nuts. So - I look to you, tdwtf crowd to set me straight - how would you have fulfilled this requirement, or what's a more friendly approach? Oh yea, and first posting, so be nice :)
Doesn't seem like a good solution to me - the way you plan it, it's impossible to create more than one tutorial database concurrently. Goodbye, scalability. Then, if something goes wrong in your stored procedure, you might damage the template for the tutorial database; the next clones coming from the templates are broken as well, then... causing even more headaches.
So, my advice:
a) the template database is "read only" (of course if your company decides to change some details, you are free to do so... but it is not modified in any way for the cloning process
b) these loops you were already planning... well, use them to copy the rows from the template tables to the target tables, changing the keys as necessary on the fly. Shouldn't be much more work.
