SQL Server architecture Issue

  • Hello Everyone,

    I just moved to a new organization and I am the DBA and I realized that the databases here are all mixed up and is not a multitenant architecture  dbs(close to same database same schema but not exact). It seems a client was added few years back and the client requested his data to be segregated. The dev team convinced the client that we are multitenant but same database same schema. However the client now wants his data to be cleaned up whenever he terminates his contract.
    I suggested having him moved to a seperate database or making changes to the application by adding more connection strings pointing to seperate databases. One of the main reason is  cleaning up (lets assume 5 yrs of data is like restoring all databases and running the delete scripts on 3 approximately 200GB databases) is going to take forever. 
    Now the dev team is hard to convince and they dont want to rearchitect the application or add new connectionstrings but they are suggesting backup the database every night and save it as x and restore it at a different location and then delete the data after restore and then perform backup of it as Y and save both X and Y. This is really not easy and not the correct way of doing things. However the management is kind of convinced (not 100%).

    But is there a way or an alternative to fix this? or atleast fight this back?

    Experts need your valuable thoughts.

    “If your actions inspire others to dream more, learn more, do more and become more, you are a leader.” -- John Quincy Adams

  • sasken - Wednesday, May 17, 2017 1:48 PM

    Hello Everyone,

    I just moved to a new organization and I am the DBA and I realized that the databases here are all mixed up and is not a multitenant architecture  dbs(close to same database same schema but not exact). It seems a client was added few years back and the client requested his data to be segregated. The dev team convinced the client that we are multitenant but same database same schema. However the client now wants his data to be cleaned up whenever he terminates his contract.
    I suggested having him moved to a seperate database or making changes to the application by adding more connection strings pointing to seperate databases. One of the main reason is  cleaning up (lets assume 5 yrs of data is like restoring all databases and running the delete scripts on 3 approximately 200GB databases) is going to take forever. 
    Now the dev team is hard to convince and they dont want to rearchitect the application or add new connectionstrings but they are suggesting backup the database every night and save it as x and restore it at a different location and then delete the data after restore and then perform backup of it as Y and save both X and Y. This is really not easy and not the correct way of doing things. However the management is kind of convinced (not 100%).

    But is there a way or an alternative to fix this? or atleast fight this back?

    Experts need your valuable thoughts.

    You say that you aren't in a multi-tenant architecture, but you also say that you have clients with close to the same schema.  Is is safe to assume that you have multiple clients, each with their own database and they're similar?  Or is it that you have multiple clients sharing data in the same database?  Or both?

    If they're separate databases, I'd think the solution is  to simply delete the client's database(s) if they terminate their contract.
    If you have several clients in a single database, then is it an option to script the deletion of the client's data?  I wouldn't think you'd have to restore databases and then delete from the restored copies and then make all new backups.  If you do, then your company had better have a serious termination fee in the contract.

    I can understand why the developers don't want to rearchitect the entire system, as it could be a heavy amount of work.  It's also a fair amount of money spent on redesign when that could be put into new features, so management probably won't be in favor of it either.  Don't misunderstand me - I agree that the structure needs to be done right.  I just think you have an uphill battle ahead of you and you're relatively new in your role.  I think the best approach is to present the options to management, along with the pros and cons of each.  Let them make the final decision, as they will anyway. 😉  At least if you present it, they won't get only one heavily-biased view of the options.

    The situation where a client has terminated a contract must have been encountered before.  How was it handled then?  Is that still an option now?

    I know I have a lot of questions in here, but you know your organization a lot better than I do.

Viewing 2 posts - 1 through 1 (of 1 total)

You must be logged in to reply to this topic. Login to reply