December 6, 2019 at 7:59 pm
What we ultimately ended up doing was creating a separate db to store user tables in. A view and/or a synonym can be used in other dbs to allow the tables to used locally to that db, just like its own tables would be. This helps deal with security and other security issues.
As background, most of the tables they create are to deal with ad hoc data, originating from many different systems/sources. Yes, in a perfect world, we'd devise some super-clean way to import data from any of these sources with some very strict rules in place. In practice, clients are constantly copying data and files, of all sorts at all times, in and out of our system. It would not be an easy task to get complete control of it. Besides, most of what they do is internal analysis or reporting, and they are very good at it. I am not; I'm not a business analyst, I'm a DBA.
Periodically I do have to go in and clean up old data in their db, because its size is capped. We don't allow them unlimited data, as that could indeed get out of hand.
I'll admit that many not be the ideal solution either, but it works for us, maybe it work for you. Maybe not. Only you can decide that, of course.
SQL DBA,SQL Server MVP(07, 08, 09) "It's a dog-eat-dog world, and I'm wearing Milk-Bone underwear." "Norm", on "Cheers". Also from "Cheers", from "Carla": "You need to know 3 things about Tortelli men: Tortelli men draw women like flies; Tortelli men treat women like flies; Tortelli men's brains are in their flies".
Viewing post 16 (of 15 total)
You must be logged in to reply to this topic. Login to reply