At my company I recently joined, there is one main person who understands the database schema. There are many tables and many fields, and it is not at all intuitive what many of these mean. Therefore, when somebody needs to make any sort of not-common query in the databases, we ask this person.

I am supposed to have something done today that involves getting a result from the database that I don't know how to get (I am a software developer, and I know SQL and can figure out other query languages, and I have access to the database, but I and others beside him just don't understand the schema and how the fields are used). On Friday, the database person was busy, yesterday he took the day off, and today he still hasn't responded to my Slack messages.

What do I do, and how do I prevent these sorts of situations in the future? This is my first full-time job, and so far it is often the case that my work depends on other people, and it has hard get these dependencies resolves, despite contacting them in advance. Plus, it feels frustrating because I don't think many of these dependencies should exist in the first place! Why not just have a one-page document that describes the unknown and confusing parts of the database? I would build this document myself, if I could actually get a long meeting with the database person scheduled.

  • 1
    Can you simulate just the data and continue that you are working on until he comes/answers back?
    – Sandra K
    Feb 20, 2018 at 17:17
  • 5
    There is a term for this type of thing in the software industry: a bottleneck or a Single Point of Failure. These can be potentially disastrous and should be brought up to management ASAP.
    – user48276
    Feb 20, 2018 at 17:59
  • 4
    Walk over to the person and ask your question.
    – Donald
    Feb 20, 2018 at 18:12
  • 2
    Maybe it's time to dig in to figuring out on your own how it works. Feb 20, 2018 at 19:57

3 Answers 3


What do I do, and how do I prevent these sorts of situations in the future?

Seems that your company suffers from knowledge compartmentalization (much like in the Tower of Babel). The real solution to prevent this in future instances is to break that compartmentalization, and make that information public knowledge: document your schemas, agree on notation for your table and column names, have periodic meetings to update everybody, etc..

Now, for your current critical task, instead of writing him on Slack I suggest you pick up the phone and call him. This way you will get a much quicker response.

Worst case, if you can't reach that person at all, then complete as much as you can from the assignment, so when that person comes back you can just fill the missing parts. Also, as someone suggested in comments, you could try using placeholders or simulate your data while that person returns.

Why not just have a one-page document that describes the unknown and confusing parts of the database?

This sounds like a great idea. This also suggests that your current company doesn't have that already documented, so it would be a good idea to start making such document.

If you want to write it yourself go for it, although as per what you describe you probably will need that person to assist you in creating such document. You can do it in a long meeting as you suggest, or well on more, shorter meetings so you don't demand much of his time.

I also suggest you check with your manager about the possibility of making that what you propose before proceeding, although you could start making it on your own so you can work more efficiently while this change is approved.


First, what is your excuse for not digging in and learning the database? I have worked with many complex undocumented databases (that had no one available to explain them) and have been able to figure out the structure and relationships in less than a week. If the person is not available, then you dig in a try and when he becomes available, you show him what you have and get him to show you what else you might need and then you document that.


OK one main person understands the database. That does not mean writing ad hoc queries is in their job description. You should ask your boss what resource(s) are available to you to assist with ad hoc queries. You can suggest to your boss if you had some documentation you could write (most of) the queries you need.

I was consulting on site to fix some performance issues and people came to me to write queries and it got to be a lot of my time. I asked my business contact and they told me I was not contracted to write queries unless they are directly related to fix the performance issues.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .