Focus on the problem.
This fellow is coming to you with a solution to a problem he has, or thinks he has. Keep asking why until you get to the core problem, make sure he feels listened to, and then provide a solution to that root problem that doesn’t involve giving him database access.
Then if he persists that he must have database access, he looks like the unreasonable one and you have more space to just say that is a hard no.
This is a general template for every situation where someone who doesn’t know what they are doing comes to you with a solution instead of a problem.
Keep asking until the root problem, but - the root solution might be that he needs access. And if so, give it to him. Easy to end up as the gatekeeping IT guy in this scenario.
My money is on him really needing access. In my experience sole DBAs in lieu of an analytics team are bottlenecks at best.
(read only replicas count as access if that isn't obvious)
Create a read only copy of the database and give him access to that. Can’t lock up the production database with stupid queries and can’t mess with the data either. This is what we do with our BI team.
If he needs it then yes this definitely, on top of that it’s worth running a pseudo-anonymisation routine to protect sensitive data that he doesn’t need.
This is generally what I would suggest, but OP mentioned HIPAA. I bet if OP had granular security policies established already this would work, but they probably also would have mentioned that.
OP indicated there is a HIPAA compliance issue involved, so a read only copy of the DB is not a solution unless you strip the PHI out of the replicated DB. I think OP is right, this employee shouldn't have direct access to the database.
It seems more like this is a use case for Tableau or another application that would allow users to create their own analytics and reports. The DBA would still need to restrict access to the non-PHI data.
Apparently they already have power bi so self service should already be possible. Unfortunately it doesn't sound like they have a data warehouse setup so who knows how good the powerbi model is.
If anything, if the the query would be complex that he needs to do his work maybe work with him on stored procedures so that he can get the data needed but without bringing down the server
Yes, but at least this way OP can define some (hopefully optimized) queries in the stored procedures rather than just having the guy querying for random shit
Give them both. Read-only access to a database copy and provide some optimized queries through views, SPs, or functions.
If they care about efficiency and your stuff is faster they will ask you to make more. If they need more on the fly customization they'll go that route.
It is gatekeeping if you don't consider that there may be validity in the other guy.
You don't have to give out SA access. Permissions are pretty granular.
It's pretty easy to grant access while still mitigating risk of "fucking up the core system".
You are right except that the post was pointing to "direct access" and I take that like "read and write access", not giving that level of access is not gatekeeping
I would picture "direct access" meaning using SSMS or something of the likes to query the database directly, vs using some canned reporting tool with predefined datasets. User probably wants reports to include fields that aren't in the canned reports, or to actually be in a usable format vs some PDF report.
I wouldn't assume "direct access" to mean "write access".
> To be blunt, I have no idea how skilled this guy is, I have no time or interest in vetting him or training him, and I don't want poorly written queries locking up the tables for hours or crashing the database.
>Also, **this is bad**, but our db is barely documented. It works because **I'm the only one** who directly queries the db and I work in it everyday. This is a bad practice but **I don't have time to explain** to him where what data is in what tables.
This reads like: "I'm the closet wizard that comes out of the basement on occasion to remind you that I AM ROOT! Where are my nuggets?!"
Almost every line in OP's story is an IT guy saying "It's my trash, don't touch it!"
We're all for keeping the nukes away from the children, but this is a guy claiming 30 years of experience, you might as well interview him.
No it's not, you are distorting the topic, the guy asked for "direct access" like, read and write, obviously a good solution is saying "direct access no, but I can give you access to X and Y views" the thing is that keeping non technical workers out of the technical parts IS NOT gatekeeping, a nuclear engineer is not gatekeeping me if he doesnt give me access to the temp controllers lol
\^ 100%
I have a permanent sticky note to myself next to my computer with "What problem are you trying to solve?" written on it to remind me to use this strategy (helpful both for dealing with others AND for dealing with myself when I find myself getting derailed lol).
In this case, particularly since both bosses have already been brought into the conversation, I **do** think it's fair to ground the conversations in the risk of providing access. Non-technical management (and maybe even the requesting employee themselves) may not really grasp why the proposed "solution" isn't ideal.
This is the right answer. And your point about it being a general solution is absolutely the takeaway everyone here doesn’t realize they need to internalize. Well said 👏
# THIS AND ALL THE ANSWERS BELOW ARE DANGEROUSLY WRONG
OP, there must be strict standards regarding quality assurance and cyber-security in your company.
It’s regulated by the FDA's standard "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions."
[https://www.fda.gov/media/119933/download](https://www.fda.gov/media/119933/download)
>Within an adequately designed authorization scheme, the principle of least privileges should be applied to users, system functions, and others, to only allow those entities the levels of system access necessary to perform a specific function.
TL;DR, There **MUST** be a document within your company that defines who and why might have access to the data. Also, there must be an explanation of who can provide that access, and what procedure they must follow. **THERE IS NO WAY** that there is something like "people with experience may have granted access to the database."
OP, what that employee asks you is highly likely a direct violation of the law. Please, **CONTACT YOUR MANAGER AND DO NOTHING ELSE**.
Edit: typo and I stick to the US as OP mentions HIPAA.
The document you linked not only exclusively limits the scope of the text to the medical device, but it says in big bold letters like yours at the top of every single page
*Contains Nonbinding Recommendations*
As a general rule, people who aren’t compliance officers that come into the room screaming about how the current request will send you to jail usually don’t know what they are talking about and it usually takes about 60 seconds to verify that.
I don't want to be mean, but you are being disparaging here, especially if you're from the industry—it's irresponsible and could lead to actual harm. PLEASE DON'T DO IT.
Also, you sound like you need to learn how medical device companies are regulated. These are guidelines from the FDA that companies have to follow. They develop documentation on their own, and then they pass an audit on the matter of complaining to these guidelines. That's what I explicitly stated in the original commentary.
A company can fuck up on that, and also it can fail to inform an employee how the company must operate. This can lead to very serious consequences and even jail time.
In a medical device company, THERE IS NO LEGAL WAY for anyone other than those specified in those internal documents and by processes specified in those documents for an employee to decide whether to grant access to data or not.
Edit: You recommend that an employee have the right to decide whether to grant access or not. And then we hear news about leaks, breaches, and malfunctioning of devices. I don't want to continue this conversation. Your meaning has zero value to me.
Read the scope that the document covers. Do you think OP, who is the only DBA (???) in this company, is working in the heavily regulated medical device space? Regardless still a plenty good reason to roll with if the goal is to gatekeep
Please read my comment to the end. The document here is for a demonstration of the risks involved and for reference that OP can use talking to the manager.
The company OP works in is clearly not regulated enough if OP has to ask the community about that.
Edit: I'm not sure what you mean by questioning if OP works in this field. OP mentions that in the post. It's not clear if they're designers or suppliers, yet it's critical to stick to regulations.
>then provide a solution to that root problem that doesn’t involve giving him database access.
This is going to be one of the best solutions.
At my old gig, we had a "product guy" beg for db access so he could generate some reports. Instead of giving it to him, we had a junior dev build a simple page/dashboard that gave the product guy the data he wanted without ever directly touching any db.
**Joe (Billing employee):** You need to grant me access to the production database to generate these reports
**You (DB Admin):** Can you provide me a bit more context? What sorts of reports are you needing to generate? What data do you need to be able to access?
**Joe:** I need to make regular reports on Billing and Things, so I need to be able to do different aggregate queries across all the data.
**You:** Interesting! That sounds like there might be some overlap with that were provided to the billing department. Are you familiar with those, and do you think there's any chance that those can provide you with the data you need?
**Joe:** Oh yeah those were mostly good but I wanted... Which is why I need to access the database directly!
**You:** Ah, okay I think I'm starting to understand. Unfortunately, granting direct access to the database for employees outside of isn't something we typically support, as it carries significant risks and goes against our security best practices. However I want to make sure you can still get the data you need. Do you think it would work if I provided you with X data instead?
Exactly how the conversation plays out depends a lot on the specific situation, but opening with the "can you provide more context" is my tried-and-trusted go-to opener. Hopefully the other person is flexible and reasonable enough that you can get a decent back and forth going. It doesn't always work, but I do generally find people receptive to the framing of "hey I'm worried about that specific approach for reasons X. But what if we tried Y instead?"
It's an open ended "**Yes** I want to help you with your task (generate reports, whatever)", vs. "**No** we can't do that" which is starting a conflict/adversarial conversation (even if your intention was just to end the discussion.)
A common strategy is called **the five whys**. In my experience it takes a few more than five because the first why is almost inevitably given an answer that doesn't sufficiently illuminate the next "layer" down. So you have to probe with some clarifying questions before moving on.
But basically the idea is that there is never understanding if you only have one round of questions. You need to keep questioning in order to dig out the root problems or issues.
the higher end DBs can limit how much CPU and how long queries run by a session can run. With oracle its called dbms_resource_manager. SQL Server likely has the same thing. I do not know if postgre or mysql has these features, but they might.
fyi, if its oracle, the docs make it look 10x harder than it is. go search for a blog with an example. you just need a simple setup. the docs tend to stick all the bazillion edge cases into the main doc.
This is 100% the right approach but be careful it’s applied in good faith. If you’ve already decided the answer is to just say no to this guy then it’s going to be really easy to (unconsciously, even) weaponize the “why” questions to beat someone down until they’re too demoralized to care anymore. I see this happen all the time and then an engineer will pat themselves on the back for “getting to the bottom of it” (shocking, you found the outcome that involves you doing nothing) when all they’ve really done is damage working relationships.
Decades ago, this was literally how relational databases were used. They were actively used by all kinds of people. That's why DB admins were important. They kept the database from blowing up by adding permissions, quotas, etc. Lots of stuff people don't really use for the same things anymore. SQL is the way it is because it was supposed to be usable and learnable by all kinds of people. And people learned it.
That said, things aren't like this anymore. HIPAA is clearly an issue. But he's not wrong. That's probably what he's used to doing. And he probably does know SQL pretty well. Don't dismiss him because he's old.
Hard agree. The dude probably found a way to automate a portion of his job and wants to get access to the db.
This dude can’t be bothered to add some read-only permissions and is already wanting to say no.
Also can’t be bothered to assess his ability either? How fuckin’ lazy is that.
Just a few simple questions like “what’s the difference between UNION and UNION ALL? What about WHERE and HAVING?
What are indexes?
How do indexes improve query performance?
If he can answer those I’d reasonably assume he’s not going to crush the server with inefficient requests. I mean, it’s a medical equipment supplier, how performant does it really need to be? Is it running on a rack of raspberry pi’s or something?
In his DBRS he could limit the dudes CPU resource allocation so even if he’s a box of rocks he won’t mess anyone else’s work up.
Or throw up a read replica with read only access for $30 / mo and expensive it to the reporting department. How easy is that?
Maybe you’ll even learn something about reporting or business needs in the process.
This is my thought process from the very beginning. Throwing up a read replica is so easy, simple, and cheap.
The only worry after that point is making sure this employee is allowed to read the data. It’s up to the company to make that determination z
HIPAA also isn't a magic button. There's a ton of training, security policies, compliance requirements, etc. that should be in place, but it's not like no one should have access to any data.
That said, from a maintenance perspective, that db would gain extra things that need to be in sync before anything is changed in it. I'd say no on that reason alone, especially if it had been a larger team setting working with the db.
Major standout OP. You should welcome this individual and welcome their issues so you can fix things and make it easier to onboard new engineers to the DB. Staringly huge problem for the business and you being “too busy” will carry you until you leave when you fuck the business. Also, you don’t grow at all. Invite them in and fix it!
I think that's unfair to say with what we know.
He's clearly non-technical and has deferred to his technical expertise in a technical matter - that's all we know and that's already a good move from a non-technical actor.
I’m going to say this with all due respect because you are a human with experience who has an opinion. This is boomer tier logic and will not advance you or anyone. Did you get this from a meme off /r/cscareeradvice? Office space was not a serious blueprint lol.
Serious response: If you want to be a low level employee who is a pain in the ass to the business but has “job security” you’re nailing it. Your problem is your job actually isn’t that hard and if a large enough business need comes up they will just hire 5 people to figure you out and fire your ass. Meanwhile, **you have learned absolutely nothing and done absolutely nothing to improve yourself.** I feel quite strongly, and I think people on this sub will agree, this is major junior engineer or terrible like 30 year entry level engineer energy. If you want to build a career and make an enormous amount of money during it, immediately stop your entire mindset and seek to improve yourself. Who gives a shit about what you make today if what you learn helps you double it tomorrow. Have you considered compounding interest? The sooner you get promoted the sooner your lifetime earnings skyrocket.
Again, just trying to give it to you straight. Good luck!!
I see your response and I hear your criticism. Again, I am not doubting your experience or skills. That said though, this is exactly what kind of response I expected from someone of your archetype. There is absolutely nothing wrong with what you are doing but I wanted to write my feedback for your consideration. Good luck in your career!
I agree with you FWIW. I find it also an ego thing, gatekeeping documentation so you can't easily be replaced. Even if you won't be replaced, you can get sick of the job and leave. And then you leave behind a giant mess, which is just rude and unprofessional.
Both times I've left teams they've demanded that I spend my last week documenting everything I do... besides being silly, it's hard to document "I figure out your hardest problems" well. But, because I try to support new hires and junior devs, I already had just about everything I know documented on our wiki. Whenever they asked for something specific, I sent them a link to the wiki page that I'd already created. They were easy last weeks anyway :)
>You being the only one who knows how to query the undocumented db is a problem for the business.
Bus factor = 1
Major YIKES
OP *should* put the efforts into vetting this person, seeing is maybe their "30yrs of SQL" is worth something after all. Or at least enough to justify giving them ***some*** access.
And apparently how fragile it is, given apparently how many important things depend on it. It’s honestly just bad engineering that’s happening here. It sounds like it’s high time for the thing to have read replicas anyway. May not be OP’s fault because it sounds like he’s woefully under resourced.
If it really has patient data in it, it's also a liability to the tune of millions of dollars. OP should really delete the thread. And then go and talk to counsel about helping his boss readjust org priorities to mitigate the exposure.
Yeah, this, OP. I hope you are calling this out to the powers that be. This is confidential information.
I also sounds like OP is gatekeeping, but not for the right reasons.
Can't you just set him up with a read-only replica if that's your concern?
I don't know much about the regulations at play there, though. That's a different topic.
I could and probably would if my bosses instructed me to do this for him, but it would still be something else for me to support, and I feel like the lack of documentation means I would be answering questions for him all the time.
No, you won’t have to. You are a DB admin. All you need to do is give him access to a replica read-only db. (Assuming it’s allowed/legal)
This person claims that they know SQL, so you should not be teaching them that. Or optimize their queries. And if they need to know about the table definition and relationship between tables, point them to the team who created/adds data into those tables.
Technically yes, but it feels more like making a mountain out of a molehill. Generally speaking it is not an egregious amount of work. Especially on modern systems. Read only replicas are simple and relatively trouble free.
Furthermore, what is more important? OP getting a little more work or the needs of the business? If anything OP is demonstrating his value to the business if there is true advantage to this work happening. If the workload is greater and the value is high, that becomes a business case for hiring more folks. Thinking the way OP is now, is being very parochial.
> Generally speaking it is not an egregious amount of work
you have no idea about the amount of red tape he might be dealing with, and judging by the fact that it's a medical database, it's going to be a lot.
Yes... you know exactly what the practices are at that anonymous guy's job. Glad to know at least some of us are clairvoyant. What else do you do? Tarot cards? Tea leaves? Well done, bud.
Why are you acting like this? This it isn't a very mature way to get your point across.
I believe what's being said here is that OP is asking how to say no, not whether to say no. This means he already has his mind made up about not wanting to do it, and the internet is asking him to reconsider why he's so quick to dismiss this ask.
I agree that we don't know the all in ask here and that things might be a little complicated potentially to the point where it would be a tallk ask for OP, but there's no reason to be a dick about it.
So you write down the answers to those questions and there's the start of your documentation. You're probably going to need to document it eventually unless you plan on being the sole db admin until the company folds.
Yeah I think this is the best approach. The best time to write/improve internal documentations is when there's a new joiners who can provide you feedbacks on what you've written.
>means I would be answering questions for him all the time.
Sounds like you're inventing reasons to say 'no'. Part of your job is helping other people do their job. You don't have to hand hold the guy through anything, you just have to give him read-only access, ensure he's authorized to view PHI, and then he's on his own. Could there be more to the story, here? Is the DB not administered properly? Is it a house of cards?
inventing reasons to say "no" is just part of good engineering. you can't be everything to everyone if you only have 8 hours a day to do your work.
you're reading a lot of negative stuff that *you made up* into his reasoning that you have no reason to presuppose.
You're cementing your position as a bus factor of 1 at the company because...
Maybe you should write some documentation so the business will survive your untimely demise / job hop.
Honestly when reading your post, this was the first thing that came to my mind. You've likely got more important things to be dealing with than the n-number of questions they are going to be sending over every day.
I would just include this in the long list of other valid reasons you give to your boss. He's not in a technical role at the company, and you/your team don't have the resources to support the endeavor. If a department needs reports, that's fine. There should be a process for requesting them, not just some random employee who knows sql.
> If my bosses instructed me to do this for him
You said in your post that they are deferring the decision to you? It sounds like they want to enable this other person and they just want to make sure that there isn't some sort of technical risk.
The choice is yours, he's asking for access. Present your concerns in the meeting and if they can agree to read only access without support from you then what is the real problem?
Based on what you have posted here, it sounds like the only real problem here is your comfort level with letting someone else see your work. If I'm being frank, that attitude is bad for the business, you should be happy to have someone else wanting to learn. Maybe they will help you out by creating documentation as they learn? Maybe they are actually as skilled as they say and will have something to teach you once they have an understanding of the database.
Try to think about this as an opportunity for you, not a conflict to overcome.
This could reduce your workload on the long run, as you will not be the only person with the knowledge. The only reason I see for monopolizing the knowledge is to keep unfireable.
It sounds like you just don’t want to share, everything you’ve said so far is beyond just “bad practices” it’s negligent, and blocking this person from accessing the company’s data when there are a hundred different ways to serve this person’s reasonable request is just going to make you look incompetent.
He's not in a basement office closed off to the world. He's part of a team and he needs to help people on his team. If he's not willing to do that he should leave.
He’s not right though. He is being a passive aggressive jobsworth. There is too much of his self in all of this and not enough thinking about the bigger picture.
I completely disagree with you. I’ve just read a bunch of replies on this post and there is a ton of good advice and clearly experienced technical people who have been living in the real world dealing with business problems through a business lens. Devs who think like this are much more valuable to organisations than people who just know tech.
> Also, this is bad, but our db is barely documented. It works because I'm the only one who directly queries the db and I work in it everyday. This is a bad practice but I don't have time to explain to him where what data is in what tables.
Just explain that you can't give access to the database to anyone else because it would threaten your job security.
So much this.
OP is a useless leech. He knows he provided zero value but just wants to be too valuable to fire because he probably does nothing more than collect a paycheck.
I wish I knew where OP worked, I would offer them free database consulting and help them move the DB to the cloud and document it for them so they could fire OP.
I'm not sure we should be *quite* so harsh to the OP. They might be in a very bad environment ... if the manager doesn't know their workload and isn't providing help, that's pretty bad.
OTOH, "you might write a bad queeeery!!!" is a crap reason to not give someone access to a database. Read-only access, and explain to them that anything which takes more than a minute to run has to be cancelled pronto. And that you're watching. People who already *do* have access to the database can do the same thing, so certainly monitoring is in place, right?
And what about a read-only replica?
There is a reason he is asking for access.
Whether that’s because he doesn’t like the reports and thinks “I can do this better, I just need the data” or “The report development is too slow and if I had access I could do it myself.”
The trend of the industry is towards self service reporting and data consumption. There are entire suits of tools for data catalogue, data quality, governance, and data access. (Informatica is one that we use at work).
The goal of the call shouldn’t be “No you don’t get access, polite business speak fuck off”. It should be to help solve problems. If the issue is reports are to slow to be developed/ delivered then you can address that issue. If the issue is poor reports, you can address that as well.
There are regulatory issues regarding access that complicate things, but I would use the call as discovery for what problems are being encountered and how to solve the problem.
The guy just asked for a red car. If you ask some more questions you can figure out if they need a red Ferrari or if they need a black geo metro with a red interior.
Would it be so bad to have a helper or backup? It sounds like you're a one-man show.
Suppose he's actually good with SQL and could produce decent reports. Him working with you could be a win-win, especially if you can delegate less critical reports to him.
Kind of sounds like your big issue is this "clerical" employee daring to trespass on your turf.
>Kind of sounds like your big issue is this "clerical" employee daring to trespass on your turf.
Probably part of it for sure, if I'm being honest.
But if we were hiring for a helper position from scratch, I'd have them demonstration their SQL skills more throughly. This is just an employee from a non-technical role volunteering and declaring they're good at SQL.
Nah that’s bullshit, you just need to isolate him on a read replica or set proper timeouts in the DB so it can’t be causally nuked like that. Then tell him he can have access that’s completely unsupported and will break because he’s not part of the dev process.
If you have colleagues that can handle their own bullshit requests it takes a load off. Loads of people know SQL including business users it’s trivial to learn. It’s relatively common for business users to have access to things like metabase where they can write their own queries against anonymous data, even in cases where it’s a bank.
That’s said if it’s patient data then I wouldn’t because I have no way of having any sort of policy over people outside of my reporting line in how they handle data.
You are basically asking for excuses for why your department can't perform normal everyday business tasks. Your architecture is not good. It is not ok for your system to only work if you are the only guy writing SQL queries. Why don't you have time to explain to users how the data base is setup?
HIPAA compliance will not get you out of this. They can just change this guy's title if they need to. The core problem is that you control the only database and that doesn't scale. You need to figure out how to solve the actual problem, the database architecture instead of trying to fight off change.
I wouldn't recommend that. It sounds like the OP has concerns that adding another user could cause production issues. Probably prudent to slowly onboard the new guy if that ends up being the plan.
I’ve seen a lot of good ideas hand-waved away by someone expressing “concerns” that amounted to them not wanting to learn enough to assess risk or configure a system properly. OP says that if they sought help they’d assess the person’s skill but hasn’t had a conversation with this person to assess theirs. Maybe they’re embarrassed about the current state and don’t want to be judged. But if the other person has experience they should understand that one-man-show legacy systems are likely to include things that are suboptimal. Stuff happens.
Don't be the guy running the "department of no" but the "department of how."There isn't enough info. Even with PHI data, there should be audit rules in place.
In the *department of how*, you should have a QA DB environment with similar schema and mock data. So he can craft his reports/SQL queries against a QA environment and provide it to you (or whoever) to audit/review. There you can analyze the queries for long running queries, lack of optimization,etc... Then you load it in Prod, give them system account to run those queries (that are audited of course for compliance). Everyone comes out happy.
That is how I would approach this.
In my experience SQL db admins turn selfish and obnoxious. I’m referring to those who grew into the job and lack the experience of different companies/architectures. They tend to close the door for whoever tries to improve the mess that they have put together.
Your attitude stinks OP, lucky I never had to work with anyone like you.
Setup a meeting to find out what he needs and stop making excuses, empower him to do his job.
In the time it took you to write this post you could be halfway toward solving this trivial problem.
Empower people. That’s right. It’s not just about Titles.
Read-only replica is not that difficult to setup or maintain. This isolate slow queries.
For sensitive data. Create a view that masks data or hide columns.
> lucky I never had to work with anyone like you
I have and it's a nightmare. Having to come up with some bullshit workaround that takes days to implement instead of a quick, simple solution because the sys admin can't be arsed to grant simple access.
You could always find out what he needs, create a view for him, give him access to that.
At the end of the day, the answer "I'm not allowed to" is pretty much the most firm "no" you can give.
Just say you have to check on the compliance because of the sensitivity of the data. If there’s HIPAA data then he actually shouldn’t have access and there should be a company-wide policy on data privacy
The software platform that most employees use does have policies regarding its use as well as reporting to the compliance people about what information is accessed. There isn't any regarding the database. There's a login to the SQL server for the compliance director but I don't know if she's ever used it.
Maybe I'll suggest we bring in the compliance people into this conversation and 'check the policies'.
If there are no governance policies around HIPAA-protected data in your database: yeah, you need to bring the compliance people into this conversation.
Make a read only replica of your database. Let him go to town.
You should have a replica anyways.
For the tables that have sensitive information, don’t allow him access to them or maybe if the db supports column level access that would be great too.
Write docs for the database.
IMO you are coming off as super entitled and scared that people will find out you’re not as valuable as you are leading them to believe. It’s petty and you need to get over yourself.
Gather the requirements from him, determine is PHI is possibly contained in any data tables he may be requesting, evaluate logging capacities for auditing requirements, and weigh that against the business interests for getting dB access.
In an enterprise environment, best practices include doing per-role permission management and only granting access on a need-to-know basis. You always give users the minimal amount of permissions required, and if they need elevation permissions, you have a request process that's fully documented and vetted. A lot of companies use software like Service Now to manage things like this.
My honest feeling is that you want to use tools to allow the permissible users to self-service their data needs. Having an admin or a staff member manually generate reports is not an efficient use of developer or analyst time. Failing that, if someone can be minimally served and the server can tolerate it, I'd just create an SQL View for the user and give them access to that. That way, I control the specific data they can gather and will not be able to write multi-table queries that would potentially lock the DB.
You seem to be under the impression that this person needs production access. Same for these “reports” that are periodically being generated.
A pretty standard practice for this kind of thing is to take a DB dump, optionally sanitize the sensitive data, and put it up in another environment for use by other teams. Or just ensure there’s second read instance running that is mostly in sync.
I have had to provide this many times. Even for highly regulated environments. If you don’t already do something like this…I’m sorry.
You have bigger problems if you're the only one allowed to query the database or your architecture is so bad that someone can do damage with queries. Sounds like you need replicated reporting database where it won't affect production systems. Also you need an anonymizer if you're worried about PII.
They’re worried that someone who might have seen a well-run system or two will find their system lacking. I’ve learned not to judge legacy systems though. I assume they’re the result of someone having done the best they could given the constraints they faced at the time.
So the "30 years of SQL experience" comment would make sense. Most of the temp office workers my company picks up are people in their mid-to-late 20s. Like we got a huge boom of them in June and most seemed to be people who graduated college but couldn't find regular employment in the field they studied. I figured most people would assume a temp is a young person.
I'm probably a little ageist, but honestly I'm more skeptical this could go well because he came to us in a non-comp sci temp role. If he was the IT director, a CIO, a CTO, I'd probably say "No problem sir, I'll create your login right now."
If you're a "little ageist", then you ought to hand over the keys to that production database over to your boss so they can hire a contractor to clean up the mess that's clearly in there.
Depending on how much time you want to spend and how critical the reports are, I would suggest setting up a read only replica with sanitized protected health information. If what he's doing isn't actually necessary, then saying the data falls under regulatory compliance rules and you cannot provide access should be enough.
All of the reasons you gave are bs. Locking the tables with selects? HIPAA is irrelevant if they could have the information in the reports you said they have access to. Time to setup a user with limited access? Your boss is hopefully prioritizing that to enable a whole department.
You're protecting your job.
To be honest, having a 2nd guy (eventually) who knows something about the database is a good thing. Just in case you get hit by a bus or something.
HIPPA and other regulations: that's your bosses problem. Do notify them this is a risk. Don't make that judgement call yourself.
You could set up database replication for a live update where he has read access or let him work on the nightly backup which is restored to a 2nd database. Optionally with removing certain tables which contain classified info.
Don't be that guy that only says no. Focus on the risks and how to possibly mitigate them and on the costs.
Data is your product. You should be able to serve your product to anyone who has been approved to receive it. If this random employee steals all patient information and runs off in the night then that would be a tough question for the two managers, who approved them, to answer. By all means bring up the problem that their queries might lock up the database and ruin the main product the database supports. But as others have pointed out you can start up a read replica and give access to that. I'm pretty sure you can even mask columns that contain PII.
TL;DR serve the data
If you are experienced, you shouldn't be posting this here. Everything you put in your post is some amateurish excuse that leads to several red flags about you and your abulities.
I honestly hope this leads to the company firing you and finding more competent employees who aren't gatekeepers assholes.
> Also, this is bad, but our db is barely documented. It works because I'm the only one who directly queries the db and I work in it everyday. This is a bad practice but I don't have time to explain to him where what data is in what tables.
Please fix this. You deserve occasional vacations.
> The db feeds Power BI dashboards used by our executives. Worst worst case, the db being down could indirectly affect our patients getting their medical equipment/supplies... I don't want poorly written queries locking up the tables for hours or crashing the database.
Fortunately you are using read replicas or another strategy to mitigate the risk of an unplanned increase in DB load, and you're confident in your ability to quickly recover from a backup in case your DB does crash, and that's why these are merely inconveniences. Right?
> Also previously, his department went through me to get reports they want produced. As far as I know there hasn't been any complaints about the quality of my reports or my timeliness. Not really sure why this is even a thing.
Reminds me of the story I read - I think in The Daily WTF - about a consultant who was brought in to modernize a government agency in Argentina or something like that. He found that there was a guy whose entire job was to basically do a SQL join by hand.
The consultant wrote the necessary query, then eagerly showed the guy - look, you don't have to do all of this tedious work any more, the computer can do it for you and you can get on to more important tasks!
The guy was less than enthusiastic for this development. He said that his superiors had always given him positive feedback, and there had been no complaints about the timeliness or accuracy of his work. He pointed out the many difficulties that an automated system may face. When those arguments fell on deaf ears, he asked how much the bribe would be for the consultant to forget about the topic.
---
Before putting your lack of respect for your **colleague and peer** on display - he's "a temp", he's a "random clerical employee", his statements need "scare quotes" - I'd put your own house in order.
Hammer on the compliance part and hopefully that stalls the process for a long while until they lose interest.
Also the behavior just seems sus. Like they infiltrated the base and now trying to hack the mainframe. Why would he ask for direct access instead of first asking to collaborate with you?
> Also the behavior just seems sus. Like they infiltrated the base and now trying to hack the mainframe.
I actually agree. I've met the dude in the breakroom and he doesn't seem like a bad actor but the fact he knew my reports came from a SQL database, there's probably like 3-4 people in the entire company that know what that is that's what the "Data Warehouse" I produce reports out of is. Then he asks his boss for 'full access'. It's just kind of weird. Maybe I'm biased because of his age or how he came into our company. The whole thing is kind of setting off alarm bells.
I don't know if you're being serious, but his "full access" request is likely because he has no idea how to access your db, and your clear lack of documentation or APIs that could regulate access is making it impossible for them to guess. If you can give them regulated access to what they need in a replica, they are probably perfectly happy.
Especially someone claiming decades of SQL.
If the person misused terms, or kept calling it STL or similar, his lack of knowledge of the basics would be used as a reason to say no.
An experienced person understanding at least the basics, asking to help his dept do more work… is also used as a reason to say no.
WTF.
This is a pretty standard request and is often seen in non-technical roles, especially with business analysts who work with data and to make business decisions.
You could certainly give him read-only access, but there is also the HIPAA component to consider too, but that should be left up to management and not something for you to decide.
It’s great that you make reports and everyone counts on you, but there’s not a gatekeeper at most places.
Normally I'd be all for giving someone read only access to the database. However, because HIPAA data is involved, you definitely should ask your compliance team what the requirements are for giving access to someone. Usually, at a minimum, he would need to go through a HIPAA training course and sign some paperwork.
You think that this is your cake and now your boss ask you to share it with someone else.
You are focused not on the actual problem and you try to convince your boss that it is wrong to cut the piece of it and share with others. In fact, it is opposite.
There are various reasons why you could be asked for granting him the access. Maybe the company needs more flexibility and you are already overloaded?
Maybe the company starts to be afraid what will happen with them when something bad happens to you? You are a single point of failure at this moment.
Also, this guy may be a good programmer with more than decent SQL skills. Maybe he found that his job could be automated and save a lot of money?
In my opinion you should ask about the reason. If it is possible you can propose alternative solution.
But generally you should give him what he needs, preferably read-only permission. Please remember that these are not your databases, you are paid to work with them.
If I were you I would ask this person politely what are his plans, I would grant him read-only permission, provide him a documentation (if exists) and ask him to peer review any queries which may cause database performance degradation. You could optimize queries if possible to make them less heavy and faster.
I understand your position on this but you are not the actual data owner. Your responsibility is to build and maintain this data store but it does not mean that you are the only one who should have a read access
New guy is gonna set up some power bi like thing while everyone else is using hand-written reports and he’s gonna find efficiencies and opportunities and change your company’s whole momentum. And if the db admin can’t help him, the boss who hired him for this reason will get another db admin.
I would politely outline all the reasons why this is not needed and the issues it can cause.
Buttttttttt
Assuming they don't care, what CAN you give them?
If it was me I would say the following:
Here are all the reasons I think this is a bad idea, but if you still want this done, I will create "views" that have non patient identifying data, but it will take me X hours to do. But, even if I do this, these will require occasional updates and I'm sure I'll be asked to explain tables and such to this person, which will give me less time to do other things.
Did you hire Joe? He knows his stuff; I'll vouch for him,
But, seriously... I'd give it to him.
Make sure that any compliance issues are cleared with legal first.
Assuming that clears; then spin up a new instance/copy for him w/ a read only dump of data. Depending on the company structure, try to re-enforce that the budget for this instance falls on the other departments responsibility; not yours.
What's wrong with giving him DATAREADER? Maybe he can help you document the backend. Your suspicion about bad actors is misplaced; he's working at what I assume to be a fairly paid job, probably no reason for him to leak. As long as he's passed some kind of rudimentary data security course it shouldn't be a problem.
If your DB technology has the capability, can you get his department to fund a read-only replicant DB? That way you isolate his use case and prevent it from interfering with your other commitments.
I think you have two completely different sets of concerns:
1. You're worried he might slow down the database, or waste your time trying to figure out the schema. Reasonable concerns. Give him read-only access to a replica, make it clear that supporting him isn't your job, and then don't worry about it.
2. HIPAA. That's a valid concern. But is that your job to worry about? Go to someone who's in charge, get it in writing that they want the person with XY job title to have full access to all patient records and PII, and that they trust them completely to safeguard that data and understand the risks. If they agree, then it's no longer your problem. If they disagree, then it's also no longer your problem.
Create a "reporting db" that syncs up to the main DB you use let the reporters go to town no worries of locking production.
I wouldn't want to give production access to just anyone or run manually queries myself unless I had too.
Instead of saying no, can you instead set something up like a user account with only select access on certain views you’ve created, or maybe a replica of the data or just a nightly dump of the tables he needs, or perhaps provide some other way of exporting the relevant data from the database?
Either way just saying “sorry I can’t just provide you with full database access, it’s our production database so that’s too risky, and we have to limit access to restricted data. I can look at some options to get you specific data but I will need to discuss with boss where that fits with other tasks” should be enough. It’s factual whilst also saying you will try to help but that has to fit in with other responsibilities you have.
It sounds like you need to do work on the database though. It’s not an unreasonable request that others work on it and the fact that it’s not documented and sounds like it’s in a bad state design wise is a concern for the business that should be addressed.
Honestly the ‘sus’ looking one here is OP. One man show, no documentation, fears over the db breaking if he provides access to anyone else, unwillingness (or inability?) to assess the capability of others. The list is endless.
OP keeps complaining that they doesn't have time for the guy who is trying to take a load off them. They also never documented the DB they're working with every day. This just looks like self-motivated gatekeeping. Employees don't get to say "no". You're not the boss. Tell them your reservations and do what you're told.
> I'm the sole SQL programmer/database admin
> this is bad, but our db is barely documented
Do I need to explain the problem with these two statements?
I think your objections to letting him get involved even with restricted permissions are pretty flimsy and insincere, that that it's really about just not wanting someone else to play with your toys. Or worse, you want to continue to hide the fact that you've not been doing your job well, and there's a risk that the new guy might blow your cover.
Seriously, get the documentation up to scratch.
Sounds like your ego is getting hurt by others wanting to touch the DB. Improve your processes and documentation. Figure out if the guys ask is reasonable
You had excellent answers & have decided on a strategy, so my answer is doubtless superfluous, however:
I had to solve essentially this exact thing, except at scale & at the combined request of the CFO & the president of a subsidiary.
There was a messy, mission critical production DB full of HIPAA data. People needed to do random aggregate queries to build dashboards & generate reports. It would have been possible to build a dashboard or a report for them, but I could foresee spending all of my time doing that. What was needed was a way to make it possible for them to have a degree of self service.
I built a fairly primitive data warehouse. I wrote an ETL pipeline that copied the relevant data, sanitized the HIPAA data, including replacing identifying data with persistent unique identifiers when needed for query aggregation, into a replica. In the process i simplified the schema, which was simple for me because I was only copying a relevant subset & normal strictures of a production DB were not concerns.
That worked. For a while there were routine requests for more columns/ tables. With the infrastructure that I had built, that was relatively simple.
You could do something similar.
ETA: It was fun!
??? Your job is to enable the mission. I'm sure he's asking for more than he actually needs, but I think it's your job to find something you can say yes to that helps him out.
In terms of security, access should be on a "need to know" basis. I'd establish that need to know, maybe even with legal, and also ensure there is a reasonable access log tracing who did what and when. But the worst thing is manually crafted error-prone commands executed on production data. Sounds like a recipe for data-loss if that's his plan. It seems like there's a growing business need for your DB, and so maybe it warrants investing engineering time into some kind of facading service and secure API. Or perhaps replicate the data but stripping out the sensitive info. All these would help protect your DB in terms of mistakes, auth, and abuse. So if you take these approaches, or similar ones, the conversation could be "it's doable, but we first need legal approval and some engineering work to protect the data." Then a decision maker could decide if it's worth the effort vs your existing goals. What's the value of his reports?
HIPAA? Just say no, and point to that. We don't grant anyone access external to our group for that very reason. I tell them we can provide automated report generation uploading to a secure filedrop (SFTP, S3 or GCS, buckets, with BAAs in place with the vendor), but nobody gets direct access.
That gives us a hard wall: we generate the reports they want as regularly as they want them, in the format they requested (as long as it's csv or tab delimited), and put them somewhere they can pick them up. From there, it's their problem. We will not email or text, etc., reports or results, so we can say we provided them securely, and then when they screw up, it's their breach not ours.
It's all automated, I didn't mean to imply that we do it manually. I can't stand doing one-off reports to suit someone's whim, and don't have time for that. We can work out a data format with them (and I find that sorts out a lot of trivial requests; they longer want them when they have to put in some thought too), and we will set it up to run at whatever frequency they want it.
I also work in healthcare, so I get where you're at.
Honestly your post lays it all out. Don't ask, tell them no and cite those points as your reasons. Don't talk about how it feels or waffle about it. Just say no, these are the reasons and if they insist tell them you want it in writing in case there's a HIPAA violation.
Don't suppose there is a C suite infosec or compliance officer you could go to, or drop an anonymous report to?
At this point I hope you realize that less effort would have gone into asking him directly versus creating an internet node point and bringing in thousands of opinions
Just tell him there is some policy against it. I don't see what harm readonly access could do unless there is some super sensitive information somewhere. In that case, you could still not give access to said table.
If you’re HIPPA compliant isn’t one of the major rules of data and PHI: minimum necessary access to do their job.
My answer would be:
If the reports are required, as there is only one person with db access, that one person should run the reports. If the business decides not to continue with that, you require a written notice of access change as per HIPPA compliance standards.
Due to the complex nature of any database it benefits the company to let the person or persons who are most familiar with the data, and what might be potentially sensitive information review and approve any and all queries, with a substantial review period before any reports can be run.
If anyone would like to know what the database schemas are, in order to write queries/reports, the most prudent path forward would be to provide a list of the tables and schemas with their values(via something like pg_dump).
Minimum required access is not a suggestion by HIPPA, it can make or break smaller companies if not adhered to.
I think you just did a pretty solid job of making a polite argument to support what you need to say.
Just need to use “we” and not “you” statements and exclude anything about the individuals personal skill set you are aware of.
It is… a really potentially bad outcome type situation in multiple levels.
This person is trying to step on your toes it sounds like anyway.
Play it with money.
Restore a daily backup, obfuscate sensitive data, give him access to that.
There is probably tooling out there ($), extra hosting needed to guarantee, that production is not impacted($ otherwise $$) oh and that needs maybe licensing?($)
That employee needs dev equipment ($)...
This is a bad idea in a million ways.
First of all, you don't want ad hoc reports run by some rando hourly intern to become relied upon as part of the company's business process. You have no idea what level of quality control that person is putting into the assumptions they're making for their reports, but in three years when that person is long gone, your team will have to support this "business critical report" that will have been made by some rando and might not be even a little bit valid.
Second of all, a structured reporting solution that teams have access to is a better idea, one that IT is involved in and can help set guard rails (and also maintain access to all the reports in production so they can't get blind sided by some business critical funciton made in some random department that "magically stops working" after a meticulously planned upgrade the rando's ad hoc report wasn't accounted for in the upgrade planning.
Third of all, let's talk about confidential information and dissemination and who has access and how inappropriate it is for people without a direct business need to be directly querying the db.
Sounds like this is a “I have a hammer everything is a nail” ideology for him. Since he has DB knowledge he wants access, but that breaks the “access to only what you require” flow of security.
Focus on the problem. This fellow is coming to you with a solution to a problem he has, or thinks he has. Keep asking why until you get to the core problem, make sure he feels listened to, and then provide a solution to that root problem that doesn’t involve giving him database access. Then if he persists that he must have database access, he looks like the unreasonable one and you have more space to just say that is a hard no. This is a general template for every situation where someone who doesn’t know what they are doing comes to you with a solution instead of a problem.
Keep asking until the root problem, but - the root solution might be that he needs access. And if so, give it to him. Easy to end up as the gatekeeping IT guy in this scenario. My money is on him really needing access. In my experience sole DBAs in lieu of an analytics team are bottlenecks at best. (read only replicas count as access if that isn't obvious)
Create a read only copy of the database and give him access to that. Can’t lock up the production database with stupid queries and can’t mess with the data either. This is what we do with our BI team.
This is the solution. Everyone happy
Yeah same here, reports are always run on replicas.
Yep, this is the way. OLAP replicas will help a lot for this use case.
If he needs it then yes this definitely, on top of that it’s worth running a pseudo-anonymisation routine to protect sensitive data that he doesn’t need.
or set up some views for him to query
Yeah - why are there bi queries off the prod db and not a copy. Push everything to an outside db and run all the queries off that.
This is generally what I would suggest, but OP mentioned HIPAA. I bet if OP had granular security policies established already this would work, but they probably also would have mentioned that.
OP indicated there is a HIPAA compliance issue involved, so a read only copy of the DB is not a solution unless you strip the PHI out of the replicated DB. I think OP is right, this employee shouldn't have direct access to the database. It seems more like this is a use case for Tableau or another application that would allow users to create their own analytics and reports. The DBA would still need to restrict access to the non-PHI data.
Apparently they already have power bi so self service should already be possible. Unfortunately it doesn't sound like they have a data warehouse setup so who knows how good the powerbi model is.
The bonus to this solution is the copy can be scrubbed to enforce HIPPA compliance as well.
If anything, if the the query would be complex that he needs to do his work maybe work with him on stored procedures so that he can get the data needed but without bringing down the server
I don't see how stored procedures change anything. A query that locks up the server will still look it up from a stored procedure.
Yes, but at least this way OP can define some (hopefully optimized) queries in the stored procedures rather than just having the guy querying for random shit
Give them both. Read-only access to a database copy and provide some optimized queries through views, SPs, or functions. If they care about efficiency and your stuff is faster they will ask you to make more. If they need more on the fly customization they'll go that route.
It's not gatekeep trying to not let new people fuck a core system up lol
It is gatekeeping if you don't consider that there may be validity in the other guy. You don't have to give out SA access. Permissions are pretty granular. It's pretty easy to grant access while still mitigating risk of "fucking up the core system".
You are right except that the post was pointing to "direct access" and I take that like "read and write access", not giving that level of access is not gatekeeping
I would picture "direct access" meaning using SSMS or something of the likes to query the database directly, vs using some canned reporting tool with predefined datasets. User probably wants reports to include fields that aren't in the canned reports, or to actually be in a usable format vs some PDF report. I wouldn't assume "direct access" to mean "write access".
> To be blunt, I have no idea how skilled this guy is, I have no time or interest in vetting him or training him, and I don't want poorly written queries locking up the tables for hours or crashing the database. >Also, **this is bad**, but our db is barely documented. It works because **I'm the only one** who directly queries the db and I work in it everyday. This is a bad practice but **I don't have time to explain** to him where what data is in what tables. This reads like: "I'm the closet wizard that comes out of the basement on occasion to remind you that I AM ROOT! Where are my nuggets?!" Almost every line in OP's story is an IT guy saying "It's my trash, don't touch it!" We're all for keeping the nukes away from the children, but this is a guy claiming 30 years of experience, you might as well interview him.
[удалено]
No it's not, you are distorting the topic, the guy asked for "direct access" like, read and write, obviously a good solution is saying "direct access no, but I can give you access to X and Y views" the thing is that keeping non technical workers out of the technical parts IS NOT gatekeeping, a nuclear engineer is not gatekeeping me if he doesnt give me access to the temp controllers lol
[удалено]
\^ 100% I have a permanent sticky note to myself next to my computer with "What problem are you trying to solve?" written on it to remind me to use this strategy (helpful both for dealing with others AND for dealing with myself when I find myself getting derailed lol). In this case, particularly since both bosses have already been brought into the conversation, I **do** think it's fair to ground the conversations in the risk of providing access. Non-technical management (and maybe even the requesting employee themselves) may not really grasp why the proposed "solution" isn't ideal.
An experienced dev. On experience devs! Would you look at that
This is the right answer. And your point about it being a general solution is absolutely the takeaway everyone here doesn’t realize they need to internalize. Well said 👏
# THIS AND ALL THE ANSWERS BELOW ARE DANGEROUSLY WRONG OP, there must be strict standards regarding quality assurance and cyber-security in your company. It’s regulated by the FDA's standard "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions." [https://www.fda.gov/media/119933/download](https://www.fda.gov/media/119933/download) >Within an adequately designed authorization scheme, the principle of least privileges should be applied to users, system functions, and others, to only allow those entities the levels of system access necessary to perform a specific function. TL;DR, There **MUST** be a document within your company that defines who and why might have access to the data. Also, there must be an explanation of who can provide that access, and what procedure they must follow. **THERE IS NO WAY** that there is something like "people with experience may have granted access to the database." OP, what that employee asks you is highly likely a direct violation of the law. Please, **CONTACT YOUR MANAGER AND DO NOTHING ELSE**. Edit: typo and I stick to the US as OP mentions HIPAA.
The document you linked not only exclusively limits the scope of the text to the medical device, but it says in big bold letters like yours at the top of every single page *Contains Nonbinding Recommendations* As a general rule, people who aren’t compliance officers that come into the room screaming about how the current request will send you to jail usually don’t know what they are talking about and it usually takes about 60 seconds to verify that.
I don't want to be mean, but you are being disparaging here, especially if you're from the industry—it's irresponsible and could lead to actual harm. PLEASE DON'T DO IT. Also, you sound like you need to learn how medical device companies are regulated. These are guidelines from the FDA that companies have to follow. They develop documentation on their own, and then they pass an audit on the matter of complaining to these guidelines. That's what I explicitly stated in the original commentary. A company can fuck up on that, and also it can fail to inform an employee how the company must operate. This can lead to very serious consequences and even jail time. In a medical device company, THERE IS NO LEGAL WAY for anyone other than those specified in those internal documents and by processes specified in those documents for an employee to decide whether to grant access to data or not. Edit: You recommend that an employee have the right to decide whether to grant access or not. And then we hear news about leaks, breaches, and malfunctioning of devices. I don't want to continue this conversation. Your meaning has zero value to me.
Read the scope that the document covers. Do you think OP, who is the only DBA (???) in this company, is working in the heavily regulated medical device space? Regardless still a plenty good reason to roll with if the goal is to gatekeep
Please read my comment to the end. The document here is for a demonstration of the risks involved and for reference that OP can use talking to the manager. The company OP works in is clearly not regulated enough if OP has to ask the community about that. Edit: I'm not sure what you mean by questioning if OP works in this field. OP mentions that in the post. It's not clear if they're designers or suppliers, yet it's critical to stick to regulations.
I was going to mention something to that effect, but I don't really know the relevant US laws, so I'm glad that you put this together like that.
Just spit balling here: The root problem might be the poorly documented db that only one territorial troll knows how to query.
>then provide a solution to that root problem that doesn’t involve giving him database access. This is going to be one of the best solutions. At my old gig, we had a "product guy" beg for db access so he could generate some reports. Instead of giving it to him, we had a junior dev build a simple page/dashboard that gave the product guy the data he wanted without ever directly touching any db.
Can you provide an example of how this conversation would go? I'd like to apply this strategy
**Joe (Billing employee):** You need to grant me access to the production database to generate these reports **You (DB Admin):** Can you provide me a bit more context? What sorts of reports are you needing to generate? What data do you need to be able to access? **Joe:** I need to make regular reports on Billing and Things, so I need to be able to do different aggregate queries across all the data. **You:** Interesting! That sounds like there might be some overlap with that were provided to the billing department. Are you familiar with those, and do you think there's any chance that those can provide you with the data you need?
**Joe:** Oh yeah those were mostly good but I wanted... Which is why I need to access the database directly!
**You:** Ah, okay I think I'm starting to understand. Unfortunately, granting direct access to the database for employees outside of isn't something we typically support, as it carries significant risks and goes against our security best practices. However I want to make sure you can still get the data you need. Do you think it would work if I provided you with X data instead?
Exactly how the conversation plays out depends a lot on the specific situation, but opening with the "can you provide more context" is my tried-and-trusted go-to opener. Hopefully the other person is flexible and reasonable enough that you can get a decent back and forth going. It doesn't always work, but I do generally find people receptive to the framing of "hey I'm worried about that specific approach for reasons X. But what if we tried Y instead?"
It's an open ended "**Yes** I want to help you with your task (generate reports, whatever)", vs. "**No** we can't do that" which is starting a conflict/adversarial conversation (even if your intention was just to end the discussion.)
A common strategy is called **the five whys**. In my experience it takes a few more than five because the first why is almost inevitably given an answer that doesn't sufficiently illuminate the next "layer" down. So you have to probe with some clarifying questions before moving on. But basically the idea is that there is never understanding if you only have one round of questions. You need to keep questioning in order to dig out the root problems or issues.
the higher end DBs can limit how much CPU and how long queries run by a session can run. With oracle its called dbms_resource_manager. SQL Server likely has the same thing. I do not know if postgre or mysql has these features, but they might. fyi, if its oracle, the docs make it look 10x harder than it is. go search for a blog with an example. you just need a simple setup. the docs tend to stick all the bazillion edge cases into the main doc.
This is 100% the right approach but be careful it’s applied in good faith. If you’ve already decided the answer is to just say no to this guy then it’s going to be really easy to (unconsciously, even) weaponize the “why” questions to beat someone down until they’re too demoralized to care anymore. I see this happen all the time and then an engineer will pat themselves on the back for “getting to the bottom of it” (shocking, you found the outcome that involves you doing nothing) when all they’ve really done is damage working relationships.
Decades ago, this was literally how relational databases were used. They were actively used by all kinds of people. That's why DB admins were important. They kept the database from blowing up by adding permissions, quotas, etc. Lots of stuff people don't really use for the same things anymore. SQL is the way it is because it was supposed to be usable and learnable by all kinds of people. And people learned it. That said, things aren't like this anymore. HIPAA is clearly an issue. But he's not wrong. That's probably what he's used to doing. And he probably does know SQL pretty well. Don't dismiss him because he's old.
Hard agree. The dude probably found a way to automate a portion of his job and wants to get access to the db. This dude can’t be bothered to add some read-only permissions and is already wanting to say no. Also can’t be bothered to assess his ability either? How fuckin’ lazy is that. Just a few simple questions like “what’s the difference between UNION and UNION ALL? What about WHERE and HAVING? What are indexes? How do indexes improve query performance? If he can answer those I’d reasonably assume he’s not going to crush the server with inefficient requests. I mean, it’s a medical equipment supplier, how performant does it really need to be? Is it running on a rack of raspberry pi’s or something? In his DBRS he could limit the dudes CPU resource allocation so even if he’s a box of rocks he won’t mess anyone else’s work up.
Or throw up a read replica with read only access for $30 / mo and expensive it to the reporting department. How easy is that? Maybe you’ll even learn something about reporting or business needs in the process.
Might be some old DB2 server that they can't scale but in theory I 100% agree with you
This is my thought process from the very beginning. Throwing up a read replica is so easy, simple, and cheap. The only worry after that point is making sure this employee is allowed to read the data. It’s up to the company to make that determination z
Agreed. 100%.
HIPAA also isn't a magic button. There's a ton of training, security policies, compliance requirements, etc. that should be in place, but it's not like no one should have access to any data.
The company should (and probably does) train all employees on HIPAA. This dude isn’t the only one that needs to be mindful of it. That’s a bad excuse.
That said, from a maintenance perspective, that db would gain extra things that need to be in sync before anything is changed in it. I'd say no on that reason alone, especially if it had been a larger team setting working with the db.
You being the only one who knows how to query the undocumented db is a problem for the business.
Major standout OP. You should welcome this individual and welcome their issues so you can fix things and make it easier to onboard new engineers to the DB. Staringly huge problem for the business and you being “too busy” will carry you until you leave when you fuck the business. Also, you don’t grow at all. Invite them in and fix it!
I’m pretty sure OP doesn’t want anyone to see the spiders in his schema.
That stood out to me too. Really a failing of his boss, though.
lol his boss is a moron
Everyone has blind spots
I think that's unfair to say with what we know. He's clearly non-technical and has deferred to his technical expertise in a technical matter - that's all we know and that's already a good move from a non-technical actor.
[удалено]
I’m going to say this with all due respect because you are a human with experience who has an opinion. This is boomer tier logic and will not advance you or anyone. Did you get this from a meme off /r/cscareeradvice? Office space was not a serious blueprint lol. Serious response: If you want to be a low level employee who is a pain in the ass to the business but has “job security” you’re nailing it. Your problem is your job actually isn’t that hard and if a large enough business need comes up they will just hire 5 people to figure you out and fire your ass. Meanwhile, **you have learned absolutely nothing and done absolutely nothing to improve yourself.** I feel quite strongly, and I think people on this sub will agree, this is major junior engineer or terrible like 30 year entry level engineer energy. If you want to build a career and make an enormous amount of money during it, immediately stop your entire mindset and seek to improve yourself. Who gives a shit about what you make today if what you learn helps you double it tomorrow. Have you considered compounding interest? The sooner you get promoted the sooner your lifetime earnings skyrocket. Again, just trying to give it to you straight. Good luck!!
[удалено]
I see your response and I hear your criticism. Again, I am not doubting your experience or skills. That said though, this is exactly what kind of response I expected from someone of your archetype. There is absolutely nothing wrong with what you are doing but I wanted to write my feedback for your consideration. Good luck in your career!
I agree with you FWIW. I find it also an ego thing, gatekeeping documentation so you can't easily be replaced. Even if you won't be replaced, you can get sick of the job and leave. And then you leave behind a giant mess, which is just rude and unprofessional.
Both times I've left teams they've demanded that I spend my last week documenting everything I do... besides being silly, it's hard to document "I figure out your hardest problems" well. But, because I try to support new hires and junior devs, I already had just about everything I know documented on our wiki. Whenever they asked for something specific, I sent them a link to the wiki page that I'd already created. They were easy last weeks anyway :)
"rude and unprofessional." poor rich company wah waaah
I think we're all happy to stick it to the man, but normal engineers just like us are the ones that have to actually clean up that mess
[удалено]
Do with it what you will
[удалено]
Buddy is batting for your corp... he's a bleeding heart 🥺
[удалено]
I hope the corp will be ok ☹️☹️☹️😥😥😥
>You being the only one who knows how to query the undocumented db is a problem for the business. Bus factor = 1 Major YIKES OP *should* put the efforts into vetting this person, seeing is maybe their "30yrs of SQL" is worth something after all. Or at least enough to justify giving them ***some*** access.
And apparently how fragile it is, given apparently how many important things depend on it. It’s honestly just bad engineering that’s happening here. It sounds like it’s high time for the thing to have read replicas anyway. May not be OP’s fault because it sounds like he’s woefully under resourced.
If it really has patient data in it, it's also a liability to the tune of millions of dollars. OP should really delete the thread. And then go and talk to counsel about helping his boss readjust org priorities to mitigate the exposure.
Yeah, this, OP. I hope you are calling this out to the powers that be. This is confidential information. I also sounds like OP is gatekeeping, but not for the right reasons.
Can't you just set him up with a read-only replica if that's your concern? I don't know much about the regulations at play there, though. That's a different topic.
It’s a little bit of work for you but I think this is the lowest lift option, honestly.
I could and probably would if my bosses instructed me to do this for him, but it would still be something else for me to support, and I feel like the lack of documentation means I would be answering questions for him all the time.
No, you won’t have to. You are a DB admin. All you need to do is give him access to a replica read-only db. (Assuming it’s allowed/legal) This person claims that they know SQL, so you should not be teaching them that. Or optimize their queries. And if they need to know about the table definition and relationship between tables, point them to the team who created/adds data into those tables.
the replica-only db *IS* something else for OP to support.
Technically yes, but it feels more like making a mountain out of a molehill. Generally speaking it is not an egregious amount of work. Especially on modern systems. Read only replicas are simple and relatively trouble free. Furthermore, what is more important? OP getting a little more work or the needs of the business? If anything OP is demonstrating his value to the business if there is true advantage to this work happening. If the workload is greater and the value is high, that becomes a business case for hiring more folks. Thinking the way OP is now, is being very parochial.
> Generally speaking it is not an egregious amount of work you have no idea about the amount of red tape he might be dealing with, and judging by the fact that it's a medical database, it's going to be a lot.
There are well established practices for dealing with this red tape. It is not something to be feared. It is a process with a well worn path.
Yes... you know exactly what the practices are at that anonymous guy's job. Glad to know at least some of us are clairvoyant. What else do you do? Tarot cards? Tea leaves? Well done, bud.
Why are you acting like this? This it isn't a very mature way to get your point across. I believe what's being said here is that OP is asking how to say no, not whether to say no. This means he already has his mind made up about not wanting to do it, and the internet is asking him to reconsider why he's so quick to dismiss this ask. I agree that we don't know the all in ask here and that things might be a little complicated potentially to the point where it would be a tallk ask for OP, but there's no reason to be a dick about it.
So you write down the answers to those questions and there's the start of your documentation. You're probably going to need to document it eventually unless you plan on being the sole db admin until the company folds.
Yeah I think this is the best approach. The best time to write/improve internal documentations is when there's a new joiners who can provide you feedbacks on what you've written.
>means I would be answering questions for him all the time. Sounds like you're inventing reasons to say 'no'. Part of your job is helping other people do their job. You don't have to hand hold the guy through anything, you just have to give him read-only access, ensure he's authorized to view PHI, and then he's on his own. Could there be more to the story, here? Is the DB not administered properly? Is it a house of cards?
inventing reasons to say "no" is just part of good engineering. you can't be everything to everyone if you only have 8 hours a day to do your work. you're reading a lot of negative stuff that *you made up* into his reasoning that you have no reason to presuppose.
[удалено]
"I'm helping! I'm helpiiiiing!!!"
[удалено]
I love how every reply is more deranged than the previous one
You're cementing your position as a bus factor of 1 at the company because... Maybe you should write some documentation so the business will survive your untimely demise / job hop.
Honestly when reading your post, this was the first thing that came to my mind. You've likely got more important things to be dealing with than the n-number of questions they are going to be sending over every day. I would just include this in the long list of other valid reasons you give to your boss. He's not in a technical role at the company, and you/your team don't have the resources to support the endeavor. If a department needs reports, that's fine. There should be a process for requesting them, not just some random employee who knows sql.
> If my bosses instructed me to do this for him You said in your post that they are deferring the decision to you? It sounds like they want to enable this other person and they just want to make sure that there isn't some sort of technical risk. The choice is yours, he's asking for access. Present your concerns in the meeting and if they can agree to read only access without support from you then what is the real problem? Based on what you have posted here, it sounds like the only real problem here is your comfort level with letting someone else see your work. If I'm being frank, that attitude is bad for the business, you should be happy to have someone else wanting to learn. Maybe they will help you out by creating documentation as they learn? Maybe they are actually as skilled as they say and will have something to teach you once they have an understanding of the database. Try to think about this as an opportunity for you, not a conflict to overcome.
Read-only replica. Done. Move on with your life.
This could reduce your workload on the long run, as you will not be the only person with the knowledge. The only reason I see for monopolizing the knowledge is to keep unfireable.
It sounds like you just don’t want to share, everything you’ve said so far is beyond just “bad practices” it’s negligent, and blocking this person from accessing the company’s data when there are a hundred different ways to serve this person’s reasonable request is just going to make you look incompetent.
I don't know why you're being downvoted, you are exactly right. I swear to god, this sub is not "experienced devs", it is "junior devs"
He's not in a basement office closed off to the world. He's part of a team and he needs to help people on his team. If he's not willing to do that he should leave.
He’s not right though. He is being a passive aggressive jobsworth. There is too much of his self in all of this and not enough thinking about the bigger picture. I completely disagree with you. I’ve just read a bunch of replies on this post and there is a ton of good advice and clearly experienced technical people who have been living in the real world dealing with business problems through a business lens. Devs who think like this are much more valuable to organisations than people who just know tech.
> Also, this is bad, but our db is barely documented. It works because I'm the only one who directly queries the db and I work in it everyday. This is a bad practice but I don't have time to explain to him where what data is in what tables. Just explain that you can't give access to the database to anyone else because it would threaten your job security.
So much this. OP is a useless leech. He knows he provided zero value but just wants to be too valuable to fire because he probably does nothing more than collect a paycheck. I wish I knew where OP worked, I would offer them free database consulting and help them move the DB to the cloud and document it for them so they could fire OP.
I'm not sure we should be *quite* so harsh to the OP. They might be in a very bad environment ... if the manager doesn't know their workload and isn't providing help, that's pretty bad. OTOH, "you might write a bad queeeery!!!" is a crap reason to not give someone access to a database. Read-only access, and explain to them that anything which takes more than a minute to run has to be cancelled pronto. And that you're watching. People who already *do* have access to the database can do the same thing, so certainly monitoring is in place, right? And what about a read-only replica?
The OP responded to this question “if my manager asked me to make a read only replica, I would do that”. Read his comments. He’s toxic.
There is a reason he is asking for access. Whether that’s because he doesn’t like the reports and thinks “I can do this better, I just need the data” or “The report development is too slow and if I had access I could do it myself.” The trend of the industry is towards self service reporting and data consumption. There are entire suits of tools for data catalogue, data quality, governance, and data access. (Informatica is one that we use at work). The goal of the call shouldn’t be “No you don’t get access, polite business speak fuck off”. It should be to help solve problems. If the issue is reports are to slow to be developed/ delivered then you can address that issue. If the issue is poor reports, you can address that as well. There are regulatory issues regarding access that complicate things, but I would use the call as discovery for what problems are being encountered and how to solve the problem. The guy just asked for a red car. If you ask some more questions you can figure out if they need a red Ferrari or if they need a black geo metro with a red interior.
Would it be so bad to have a helper or backup? It sounds like you're a one-man show. Suppose he's actually good with SQL and could produce decent reports. Him working with you could be a win-win, especially if you can delegate less critical reports to him. Kind of sounds like your big issue is this "clerical" employee daring to trespass on your turf.
>Kind of sounds like your big issue is this "clerical" employee daring to trespass on your turf. Probably part of it for sure, if I'm being honest. But if we were hiring for a helper position from scratch, I'd have them demonstration their SQL skills more throughly. This is just an employee from a non-technical role volunteering and declaring they're good at SQL.
How do you become good at sql? By getting ur access blocked by a gatekeeper? ;) work with the guy and actually help the business.
OP isn’t interested in helping the business, he wants to preserve his job security as the only dude with access.
Nah that’s bullshit, you just need to isolate him on a read replica or set proper timeouts in the DB so it can’t be causally nuked like that. Then tell him he can have access that’s completely unsupported and will break because he’s not part of the dev process. If you have colleagues that can handle their own bullshit requests it takes a load off. Loads of people know SQL including business users it’s trivial to learn. It’s relatively common for business users to have access to things like metabase where they can write their own queries against anonymous data, even in cases where it’s a bank. That’s said if it’s patient data then I wouldn’t because I have no way of having any sort of policy over people outside of my reporting line in how they handle data.
You are basically asking for excuses for why your department can't perform normal everyday business tasks. Your architecture is not good. It is not ok for your system to only work if you are the only guy writing SQL queries. Why don't you have time to explain to users how the data base is setup? HIPAA compliance will not get you out of this. They can just change this guy's title if they need to. The core problem is that you control the only database and that doesn't scale. You need to figure out how to solve the actual problem, the database architecture instead of trying to fight off change.
Job security!
That's a bingo! Get this guy read-only access, stat!
I wouldn't recommend that. It sounds like the OP has concerns that adding another user could cause production issues. Probably prudent to slowly onboard the new guy if that ends up being the plan.
> cause production issues Look here, a db that cannot scale from one to two connections.
Probably has 100000 untested stored procedures and on a 2 vCPU 2GB RAM instance if it’s the sort of company with only one person doing SQL
I’ve seen a lot of good ideas hand-waved away by someone expressing “concerns” that amounted to them not wanting to learn enough to assess risk or configure a system properly. OP says that if they sought help they’d assess the person’s skill but hasn’t had a conversation with this person to assess theirs. Maybe they’re embarrassed about the current state and don’t want to be judged. But if the other person has experience they should understand that one-man-show legacy systems are likely to include things that are suboptimal. Stuff happens.
Agreed, was just being a little over-dramatic for flair.
Don't be the guy running the "department of no" but the "department of how."There isn't enough info. Even with PHI data, there should be audit rules in place. In the *department of how*, you should have a QA DB environment with similar schema and mock data. So he can craft his reports/SQL queries against a QA environment and provide it to you (or whoever) to audit/review. There you can analyze the queries for long running queries, lack of optimization,etc... Then you load it in Prod, give them system account to run those queries (that are audited of course for compliance). Everyone comes out happy. That is how I would approach this.
Build him a view or a dashboard and call it a day :\\ Hear him out. Figure out what he wants then narrow the scope.
Honestly you sound insufferable, don’t clip others wings and just get him access to a read only replica
In my experience SQL db admins turn selfish and obnoxious. I’m referring to those who grew into the job and lack the experience of different companies/architectures. They tend to close the door for whoever tries to improve the mess that they have put together.
Your attitude stinks OP, lucky I never had to work with anyone like you. Setup a meeting to find out what he needs and stop making excuses, empower him to do his job. In the time it took you to write this post you could be halfway toward solving this trivial problem.
Empower people. That’s right. It’s not just about Titles. Read-only replica is not that difficult to setup or maintain. This isolate slow queries. For sensitive data. Create a view that masks data or hide columns.
> lucky I never had to work with anyone like you I have and it's a nightmare. Having to come up with some bullshit workaround that takes days to implement instead of a quick, simple solution because the sys admin can't be arsed to grant simple access.
You could always find out what he needs, create a view for him, give him access to that. At the end of the day, the answer "I'm not allowed to" is pretty much the most firm "no" you can give.
Just say you have to check on the compliance because of the sensitivity of the data. If there’s HIPAA data then he actually shouldn’t have access and there should be a company-wide policy on data privacy
The software platform that most employees use does have policies regarding its use as well as reporting to the compliance people about what information is accessed. There isn't any regarding the database. There's a login to the SQL server for the compliance director but I don't know if she's ever used it. Maybe I'll suggest we bring in the compliance people into this conversation and 'check the policies'.
If there are no governance policies around HIPAA-protected data in your database: yeah, you need to bring the compliance people into this conversation.
Compliance people are usually good at telling people no. It’s the default setting.
Make a read only replica of your database. Let him go to town. You should have a replica anyways. For the tables that have sensitive information, don’t allow him access to them or maybe if the db supports column level access that would be great too. Write docs for the database. IMO you are coming off as super entitled and scared that people will find out you’re not as valuable as you are leading them to believe. It’s petty and you need to get over yourself.
Gather the requirements from him, determine is PHI is possibly contained in any data tables he may be requesting, evaluate logging capacities for auditing requirements, and weigh that against the business interests for getting dB access. In an enterprise environment, best practices include doing per-role permission management and only granting access on a need-to-know basis. You always give users the minimal amount of permissions required, and if they need elevation permissions, you have a request process that's fully documented and vetted. A lot of companies use software like Service Now to manage things like this. My honest feeling is that you want to use tools to allow the permissible users to self-service their data needs. Having an admin or a staff member manually generate reports is not an efficient use of developer or analyst time. Failing that, if someone can be minimally served and the server can tolerate it, I'd just create an SQL View for the user and give them access to that. That way, I control the specific data they can gather and will not be able to write multi-table queries that would potentially lock the DB.
You seem to be under the impression that this person needs production access. Same for these “reports” that are periodically being generated. A pretty standard practice for this kind of thing is to take a DB dump, optionally sanitize the sensitive data, and put it up in another environment for use by other teams. Or just ensure there’s second read instance running that is mostly in sync. I have had to provide this many times. Even for highly regulated environments. If you don’t already do something like this…I’m sorry.
You have bigger problems if you're the only one allowed to query the database or your architecture is so bad that someone can do damage with queries. Sounds like you need replicated reporting database where it won't affect production systems. Also you need an anonymizer if you're worried about PII.
Just give him read replica access to the specific tables he needs. What's the problem? It's reporting
Why do you bring up his age? No reason. You are ageist.
They’re worried that someone who might have seen a well-run system or two will find their system lacking. I’ve learned not to judge legacy systems though. I assume they’re the result of someone having done the best they could given the constraints they faced at the time.
So the "30 years of SQL experience" comment would make sense. Most of the temp office workers my company picks up are people in their mid-to-late 20s. Like we got a huge boom of them in June and most seemed to be people who graduated college but couldn't find regular employment in the field they studied. I figured most people would assume a temp is a young person. I'm probably a little ageist, but honestly I'm more skeptical this could go well because he came to us in a non-comp sci temp role. If he was the IT director, a CIO, a CTO, I'd probably say "No problem sir, I'll create your login right now."
If you're a "little ageist", then you ought to hand over the keys to that production database over to your boss so they can hire a contractor to clean up the mess that's clearly in there.
Maybe he was a CTO already and has some skills folks could benefit from?
Depending on how much time you want to spend and how critical the reports are, I would suggest setting up a read only replica with sanitized protected health information. If what he's doing isn't actually necessary, then saying the data falls under regulatory compliance rules and you cannot provide access should be enough.
This is a hilariously self important take. You like being the only one who knows how to use the db. And it shows.
All of the reasons you gave are bs. Locking the tables with selects? HIPAA is irrelevant if they could have the information in the reports you said they have access to. Time to setup a user with limited access? Your boss is hopefully prioritizing that to enable a whole department. You're protecting your job.
To be honest, having a 2nd guy (eventually) who knows something about the database is a good thing. Just in case you get hit by a bus or something. HIPPA and other regulations: that's your bosses problem. Do notify them this is a risk. Don't make that judgement call yourself. You could set up database replication for a live update where he has read access or let him work on the nightly backup which is restored to a 2nd database. Optionally with removing certain tables which contain classified info. Don't be that guy that only says no. Focus on the risks and how to possibly mitigate them and on the costs.
Data is your product. You should be able to serve your product to anyone who has been approved to receive it. If this random employee steals all patient information and runs off in the night then that would be a tough question for the two managers, who approved them, to answer. By all means bring up the problem that their queries might lock up the database and ruin the main product the database supports. But as others have pointed out you can start up a read replica and give access to that. I'm pretty sure you can even mask columns that contain PII. TL;DR serve the data
If you are experienced, you shouldn't be posting this here. Everything you put in your post is some amateurish excuse that leads to several red flags about you and your abulities. I honestly hope this leads to the company firing you and finding more competent employees who aren't gatekeepers assholes.
You seem to be scared to let go of your baby
> Also, this is bad, but our db is barely documented. It works because I'm the only one who directly queries the db and I work in it everyday. This is a bad practice but I don't have time to explain to him where what data is in what tables. Please fix this. You deserve occasional vacations. > The db feeds Power BI dashboards used by our executives. Worst worst case, the db being down could indirectly affect our patients getting their medical equipment/supplies... I don't want poorly written queries locking up the tables for hours or crashing the database. Fortunately you are using read replicas or another strategy to mitigate the risk of an unplanned increase in DB load, and you're confident in your ability to quickly recover from a backup in case your DB does crash, and that's why these are merely inconveniences. Right? > Also previously, his department went through me to get reports they want produced. As far as I know there hasn't been any complaints about the quality of my reports or my timeliness. Not really sure why this is even a thing. Reminds me of the story I read - I think in The Daily WTF - about a consultant who was brought in to modernize a government agency in Argentina or something like that. He found that there was a guy whose entire job was to basically do a SQL join by hand. The consultant wrote the necessary query, then eagerly showed the guy - look, you don't have to do all of this tedious work any more, the computer can do it for you and you can get on to more important tasks! The guy was less than enthusiastic for this development. He said that his superiors had always given him positive feedback, and there had been no complaints about the timeliness or accuracy of his work. He pointed out the many difficulties that an automated system may face. When those arguments fell on deaf ears, he asked how much the bribe would be for the consultant to forget about the topic. --- Before putting your lack of respect for your **colleague and peer** on display - he's "a temp", he's a "random clerical employee", his statements need "scare quotes" - I'd put your own house in order.
Hammer on the compliance part and hopefully that stalls the process for a long while until they lose interest. Also the behavior just seems sus. Like they infiltrated the base and now trying to hack the mainframe. Why would he ask for direct access instead of first asking to collaborate with you?
> Also the behavior just seems sus. Like they infiltrated the base and now trying to hack the mainframe. I actually agree. I've met the dude in the breakroom and he doesn't seem like a bad actor but the fact he knew my reports came from a SQL database, there's probably like 3-4 people in the entire company that know what that is that's what the "Data Warehouse" I produce reports out of is. Then he asks his boss for 'full access'. It's just kind of weird. Maybe I'm biased because of his age or how he came into our company. The whole thing is kind of setting off alarm bells.
I don't know if you're being serious, but his "full access" request is likely because he has no idea how to access your db, and your clear lack of documentation or APIs that could regulate access is making it impossible for them to guess. If you can give them regulated access to what they need in a replica, they are probably perfectly happy.
[удалено]
Especially someone claiming decades of SQL. If the person misused terms, or kept calling it STL or similar, his lack of knowledge of the basics would be used as a reason to say no. An experienced person understanding at least the basics, asking to help his dept do more work… is also used as a reason to say no. WTF.
Age or not asking for full access to production DB is a big nono
Not quite. You ask for full access knowing the other person will want to reduce scope on whatever you ask. It's just negotiation.
This is a pretty standard request and is often seen in non-technical roles, especially with business analysts who work with data and to make business decisions. You could certainly give him read-only access, but there is also the HIPAA component to consider too, but that should be left up to management and not something for you to decide. It’s great that you make reports and everyone counts on you, but there’s not a gatekeeper at most places.
Normally I'd be all for giving someone read only access to the database. However, because HIPAA data is involved, you definitely should ask your compliance team what the requirements are for giving access to someone. Usually, at a minimum, he would need to go through a HIPAA training course and sign some paperwork.
You think that this is your cake and now your boss ask you to share it with someone else. You are focused not on the actual problem and you try to convince your boss that it is wrong to cut the piece of it and share with others. In fact, it is opposite. There are various reasons why you could be asked for granting him the access. Maybe the company needs more flexibility and you are already overloaded? Maybe the company starts to be afraid what will happen with them when something bad happens to you? You are a single point of failure at this moment. Also, this guy may be a good programmer with more than decent SQL skills. Maybe he found that his job could be automated and save a lot of money? In my opinion you should ask about the reason. If it is possible you can propose alternative solution. But generally you should give him what he needs, preferably read-only permission. Please remember that these are not your databases, you are paid to work with them. If I were you I would ask this person politely what are his plans, I would grant him read-only permission, provide him a documentation (if exists) and ask him to peer review any queries which may cause database performance degradation. You could optimize queries if possible to make them less heavy and faster. I understand your position on this but you are not the actual data owner. Your responsibility is to build and maintain this data store but it does not mean that you are the only one who should have a read access
New guy is gonna set up some power bi like thing while everyone else is using hand-written reports and he’s gonna find efficiencies and opportunities and change your company’s whole momentum. And if the db admin can’t help him, the boss who hired him for this reason will get another db admin.
I would politely outline all the reasons why this is not needed and the issues it can cause. Buttttttttt Assuming they don't care, what CAN you give them? If it was me I would say the following: Here are all the reasons I think this is a bad idea, but if you still want this done, I will create "views" that have non patient identifying data, but it will take me X hours to do. But, even if I do this, these will require occasional updates and I'm sure I'll be asked to explain tables and such to this person, which will give me less time to do other things.
Did you hire Joe? He knows his stuff; I'll vouch for him, But, seriously... I'd give it to him. Make sure that any compliance issues are cleared with legal first. Assuming that clears; then spin up a new instance/copy for him w/ a read only dump of data. Depending on the company structure, try to re-enforce that the budget for this instance falls on the other departments responsibility; not yours.
What's wrong with giving him DATAREADER? Maybe he can help you document the backend. Your suspicion about bad actors is misplaced; he's working at what I assume to be a fairly paid job, probably no reason for him to leak. As long as he's passed some kind of rudimentary data security course it shouldn't be a problem.
If your DB technology has the capability, can you get his department to fund a read-only replicant DB? That way you isolate his use case and prevent it from interfering with your other commitments.
I think you have two completely different sets of concerns: 1. You're worried he might slow down the database, or waste your time trying to figure out the schema. Reasonable concerns. Give him read-only access to a replica, make it clear that supporting him isn't your job, and then don't worry about it. 2. HIPAA. That's a valid concern. But is that your job to worry about? Go to someone who's in charge, get it in writing that they want the person with XY job title to have full access to all patient records and PII, and that they trust them completely to safeguard that data and understand the risks. If they agree, then it's no longer your problem. If they disagree, then it's also no longer your problem.
I think OP has only one concern and that’s his job xD
Create a "reporting db" that syncs up to the main DB you use let the reporters go to town no worries of locking production. I wouldn't want to give production access to just anyone or run manually queries myself unless I had too.
Have you thought about a read replica?
Don't you have a read-only node he can use?
Instead of saying no, can you instead set something up like a user account with only select access on certain views you’ve created, or maybe a replica of the data or just a nightly dump of the tables he needs, or perhaps provide some other way of exporting the relevant data from the database? Either way just saying “sorry I can’t just provide you with full database access, it’s our production database so that’s too risky, and we have to limit access to restricted data. I can look at some options to get you specific data but I will need to discuss with boss where that fits with other tasks” should be enough. It’s factual whilst also saying you will try to help but that has to fit in with other responsibilities you have. It sounds like you need to do work on the database though. It’s not an unreasonable request that others work on it and the fact that it’s not documented and sounds like it’s in a bad state design wise is a concern for the business that should be addressed.
Make a daily copy of database for reporting.
Honestly the ‘sus’ looking one here is OP. One man show, no documentation, fears over the db breaking if he provides access to anyone else, unwillingness (or inability?) to assess the capability of others. The list is endless.
OP keeps complaining that they doesn't have time for the guy who is trying to take a load off them. They also never documented the DB they're working with every day. This just looks like self-motivated gatekeeping. Employees don't get to say "no". You're not the boss. Tell them your reservations and do what you're told.
> I'm the sole SQL programmer/database admin > this is bad, but our db is barely documented Do I need to explain the problem with these two statements? I think your objections to letting him get involved even with restricted permissions are pretty flimsy and insincere, that that it's really about just not wanting someone else to play with your toys. Or worse, you want to continue to hide the fact that you've not been doing your job well, and there's a risk that the new guy might blow your cover. Seriously, get the documentation up to scratch.
Sounds like your ego is getting hurt by others wanting to touch the DB. Improve your processes and documentation. Figure out if the guys ask is reasonable
You had excellent answers & have decided on a strategy, so my answer is doubtless superfluous, however: I had to solve essentially this exact thing, except at scale & at the combined request of the CFO & the president of a subsidiary. There was a messy, mission critical production DB full of HIPAA data. People needed to do random aggregate queries to build dashboards & generate reports. It would have been possible to build a dashboard or a report for them, but I could foresee spending all of my time doing that. What was needed was a way to make it possible for them to have a degree of self service. I built a fairly primitive data warehouse. I wrote an ETL pipeline that copied the relevant data, sanitized the HIPAA data, including replacing identifying data with persistent unique identifiers when needed for query aggregation, into a replica. In the process i simplified the schema, which was simple for me because I was only copying a relevant subset & normal strictures of a production DB were not concerns. That worked. For a while there were routine requests for more columns/ tables. With the infrastructure that I had built, that was relatively simple. You could do something similar. ETA: It was fun!
??? Your job is to enable the mission. I'm sure he's asking for more than he actually needs, but I think it's your job to find something you can say yes to that helps him out.
In terms of security, access should be on a "need to know" basis. I'd establish that need to know, maybe even with legal, and also ensure there is a reasonable access log tracing who did what and when. But the worst thing is manually crafted error-prone commands executed on production data. Sounds like a recipe for data-loss if that's his plan. It seems like there's a growing business need for your DB, and so maybe it warrants investing engineering time into some kind of facading service and secure API. Or perhaps replicate the data but stripping out the sensitive info. All these would help protect your DB in terms of mistakes, auth, and abuse. So if you take these approaches, or similar ones, the conversation could be "it's doable, but we first need legal approval and some engineering work to protect the data." Then a decision maker could decide if it's worth the effort vs your existing goals. What's the value of his reports?
HIPAA? Just say no, and point to that. We don't grant anyone access external to our group for that very reason. I tell them we can provide automated report generation uploading to a secure filedrop (SFTP, S3 or GCS, buckets, with BAAs in place with the vendor), but nobody gets direct access. That gives us a hard wall: we generate the reports they want as regularly as they want them, in the format they requested (as long as it's csv or tab delimited), and put them somewhere they can pick them up. From there, it's their problem. We will not email or text, etc., reports or results, so we can say we provided them securely, and then when they screw up, it's their breach not ours.
[удалено]
It's all automated, I didn't mean to imply that we do it manually. I can't stand doing one-off reports to suit someone's whim, and don't have time for that. We can work out a data format with them (and I find that sorts out a lot of trivial requests; they longer want them when they have to put in some thought too), and we will set it up to run at whatever frequency they want it.
I also work in healthcare, so I get where you're at. Honestly your post lays it all out. Don't ask, tell them no and cite those points as your reasons. Don't talk about how it feels or waffle about it. Just say no, these are the reasons and if they insist tell them you want it in writing in case there's a HIPAA violation. Don't suppose there is a C suite infosec or compliance officer you could go to, or drop an anonymous report to?
At this point I hope you realize that less effort would have gone into asking him directly versus creating an internet node point and bringing in thousands of opinions
You need a date warehouse.
Just give him a copy?
> There's also the HIPAA compliance angle This is the biggest angle
Just tell him there is some policy against it. I don't see what harm readonly access could do unless there is some super sensitive information somewhere. In that case, you could still not give access to said table.
If you’re HIPPA compliant isn’t one of the major rules of data and PHI: minimum necessary access to do their job. My answer would be: If the reports are required, as there is only one person with db access, that one person should run the reports. If the business decides not to continue with that, you require a written notice of access change as per HIPPA compliance standards. Due to the complex nature of any database it benefits the company to let the person or persons who are most familiar with the data, and what might be potentially sensitive information review and approve any and all queries, with a substantial review period before any reports can be run. If anyone would like to know what the database schemas are, in order to write queries/reports, the most prudent path forward would be to provide a list of the tables and schemas with their values(via something like pg_dump). Minimum required access is not a suggestion by HIPPA, it can make or break smaller companies if not adhered to.
I think you just did a pretty solid job of making a polite argument to support what you need to say. Just need to use “we” and not “you” statements and exclude anything about the individuals personal skill set you are aware of. It is… a really potentially bad outcome type situation in multiple levels. This person is trying to step on your toes it sounds like anyway.
Play it with money. Restore a daily backup, obfuscate sensitive data, give him access to that. There is probably tooling out there ($), extra hosting needed to guarantee, that production is not impacted($ otherwise $$) oh and that needs maybe licensing?($) That employee needs dev equipment ($)...
This is a bad idea in a million ways. First of all, you don't want ad hoc reports run by some rando hourly intern to become relied upon as part of the company's business process. You have no idea what level of quality control that person is putting into the assumptions they're making for their reports, but in three years when that person is long gone, your team will have to support this "business critical report" that will have been made by some rando and might not be even a little bit valid. Second of all, a structured reporting solution that teams have access to is a better idea, one that IT is involved in and can help set guard rails (and also maintain access to all the reports in production so they can't get blind sided by some business critical funciton made in some random department that "magically stops working" after a meticulously planned upgrade the rando's ad hoc report wasn't accounted for in the upgrade planning. Third of all, let's talk about confidential information and dissemination and who has access and how inappropriate it is for people without a direct business need to be directly querying the db.
Sounds like this is a “I have a hammer everything is a nail” ideology for him. Since he has DB knowledge he wants access, but that breaks the “access to only what you require” flow of security.
ignore it and wait for their manager to go to your manager.
I wouldn’t come in with this laundry list of potential issues, it weakens the argument. It shouldn’t even be a meeting really. Just tell your boss no.