How do you handle users that want Perm space

Database
DJM
Enthusiast

How do you handle users that want Perm space

As more and more of our users acquire access to our Teradata data warehouse, some of them desire perm space and the ability to create their own tables. I've searched through these forums but haven't really seen this discussed. I'm curious as to how others handle this. What have you created for your users and what restrictions do you place on them.

 

The concerns I have are:

1. No control over what users would be creating. I wouldn't know if users are creating critical business processes around data they own.

2. The source of this data could be outside of the data warehouse, so it's consistancy is suspect.

3. If they are loading their own data, this data could very well already exist elsewhere.

4. Users owning objects that have become important to the business, and then leaving the organization.

 

 

3 REPLIES
Teradata Employee

Re: How do you handle users that want Perm space

For all of the reasons you mentioned we just say no.

Knowledgeable users are given data labs for prototyping and those are closely monitored. Good ideas are then taken through normal development process.

Dave

Re: How do you handle users that want Perm space

Another option is to provide a scratch database that is regularly purged.  Users must know that the data is not backed up, and that that tables ingested will be temporary.  Space is limited to a reasonable size, so when the database is full, they have to clean up to add more.  If the access given is simply Create Table, they have access only to the objects they create.

Teradata Employee

Re: How do you handle users that want Perm space

My response expands a bit on both David's and Deborah's responses.

 

If you provide them with temp space, they could at least create temp tables within their sessions, but that's probably not the ideal solution.

 

For years, a great many of our customers, including our largest ones, have created "sandbox" databases that are accessed by users belonging to a particular role.  Sometimes they've created more than one sandbox with each assigned to a different role.  And these sandboxes were created on the production system, so they would have access to all available data.

 

In almost all cases, the sandbox was a decent size but limited, and the users were mostly responsible for monitoring their own use of the space.  Many companies created these databases with an automatic purge - any object older than x (30 to 90 usually) days would get dropped.  Other companies simply issued automatic space reports to the active users.

 

The addition of Data Labs made the sandbox process a little more formal and made managing the space much easier.

 

Depending on their role, having a space in which to experiment is critical for many users.  For a particular business problem (probably a new one), the data warehouse might not have the right structure or data to address it.

 

The ability to create tables and load subsets of data in smaller chunks for temporary work (like 6 months out of 36 months of history) can be a big help to the user without impacting production processes.  Again depending on the warehouse design, a user might not have been given enough spool space to capture 6 months in one pass, but would have enough space to assemble it 1 month at a time.  There are at least 3 companies where I've consulted that I executed analyses in this very manner.

 

I hope this helps.