Forgot your password?
typodupeerror
Databases Programming Software IT

Keeping Customer From Accessing My Database? 567

Posted by kdawson
from the my-precioussss dept.
cyteen02 writes "We run a data processing and tracking system for a customer in the UK. We provide a simple Web site where the customer can display the tracking data held in our Oracle database. From these screens they can query based on a combination of 15 different data fields, so it's pretty flexible. We also provide a csv report overnight of the previous day's data processing, which they can load into their own SQL Server database and produce whatever reports they want. Occasionally they also want one-off specific detailed reports, so we write the SQL for that and send them the results in an Excel format spreadsheet. This all ticks along happily. However they have now asked for direct read-only access to our Oracle database, to be able to run ad-hoc queries without consulting us. As a DBA, my heart sinks at the thought of amateurs pawing through my database. Unfortunately, 'because you are stupid' is not considered a valid business reason to reject their request. So can any Slashdotters assist me in building my case to restrict access? Have you experienced a similar situation? Have you had to support this sort of end user access? How would you advice me to keep my customer away from my precious tables?"
This discussion has been archived. No new comments can be posted.

Keeping Customer From Accessing My Database?

Comments Filter:
  • by suso (153703) * on Friday May 16, 2008 @01:36PM (#23436556) Homepage Journal
    Just say no and hope that it sticks. Seriously. I find that so many people in the workforce noadays don't know how to say that simple word. No.

    Sometimes its hard to make a case for it if management at your company thinks that you are being unreasonable. However if you are a reasonable person and skilled in your profession, management should trust you to do your job. I'm of the opinion that if management can't trust employees in their area of expertise and to give good advice, then it is not a good place to work. My first tech job became this way, the new management that came along had a distrust of us and it made everything sour. Anyways, that's getting away from your question.

    But being a sysadmin, I think you have to stand up for your opinion when the time is right to do so. People who aren't in the know always have requests like this to grant more access, make things easier, keep the customer's demands first. Its your job to draw a line in the sand that says you can't go past that point. Some people don't like that, but honestly it doesn't matter. Rules are there for a reason. They are guides to providing good service for all customers, not just one.
  • Reporting Database (Score:5, Insightful)

    by WreckDiver (685191) on Friday May 16, 2008 @01:38PM (#23436584)
    The last thing you want is users writing ad-hoc queries against your live data. Replicate the data to a reporting database and let them abuse that.
  • Why? (Score:5, Insightful)

    by iElucidate (67873) on Friday May 16, 2008 @01:40PM (#23436610) Homepage
    You don't want them "pawing" through your database, but you don't give any reasons why that is a bad idea. If you can't come up with any, you're not going to get very far in your argument. If it is a read-only view of only the data they should be able to see, what is the harm?

    No, seriously. Answer that question, and you have a basis for your argument. If you don't have an answer besides "it makes me feel dirty," you've lost.
  • by etymxris (121288) on Friday May 16, 2008 @01:41PM (#23436618)
    How are they going to mess up your database with read-only access? They could run intensive queries, I guess. But unless you've got million+ row tables that are being accessed concurrently by tens of clients, this shouldn't be much of a problem.

    Anyway, just enable logging and look through what they've been doing in case it's anything stupid. I used to work for a large insurance firm and we'd get a call minutes after doing against the database we shouldn't.
  • by netsavior (627338) on Friday May 16, 2008 @01:41PM (#23436638)
    For the love of science do not give them access to your production database, they WILL screw it up, even with just read access.
    Here is the psudocode from their SQL:
    Select * from everything join everything where non-indexed column like '%'

    you need to make them a COPY of the data that they are allowed to access on a seperate database (preferably a seperate server). Most reasonable replication suites allow you to do things like this.
  • by RCTrucker7 (1049252) on Friday May 16, 2008 @01:42PM (#23436670)
    How about just a simple "No." The database, while containing data pertitnent to your customer, is still your\your companies property. Simply tell them that access to that level, or in fact any level beyond what is alreayd granted to them as a customer, is for you and\or your employees only. Just because he's a customer, doesn't grant him unfettered access to your company or it's property, whether that property is physical or electronic.
  • by Giant Electronic Bra (1229876) on Friday May 16, 2008 @01:43PM (#23436672)
    Mirror the database to a 2nd server and provide them read access to that. It has several advantages.

    1) You don't have to worry about them causing problems in the production database.

    2) You can optimize the replica for read access. A read only database can generally perform MANY times better than one that has to be optimized to support read/write and especially if it is highly transactional.

    Granted, it costs you a bit in hardware and setup time, etc. But if you're really nervous about it, then it should do the trick. Given the limited load on the replica and its read only nature it should be able to live on limited hardware, like maybe an older server that you have hanging around. Plus you don't have to worry about reliability either. If the thing blows up no data is lost.
  • Why not? (Score:3, Insightful)

    by Hankapobe (1290722) on Friday May 16, 2008 @01:43PM (#23436682)
    However they have now asked for direct read-only access to our Oracle database, to be able to run ad-hoc queries without consulting us.

    Why not set up an account that has read only access? Why not create a view of the table that shows only the columns they need? It'll be good customer service and relations. Just remember, your company can be replaced and if you don't give them the service they want they'll get it somewhere else.

  • just now when said like that.
    I am not sure why a DBA doesn't know this, but just create read only views

    Seriously - are you really a DBA, or just someone that got stuck DBAing? This situation is dealt with at every place I have ever worked, without exception.

    You could also create a Cube. This might be 24 hours old, but I don't know who many transactions we are talking about here.

    Be sure you can track all logins, and log what they do.

    They are not your tables, get that out of your mind. They are the companies. All you can do is write a report explaining the risks to management, and be sure the users know they are liable when they make a mistake. Then set up views.

    Yes, if they screw up you will be the one to fix it, that's your job. At least you can wave off any fault.

  • by teknopurge (199509) on Friday May 16, 2008 @01:45PM (#23436746) Homepage
    You are supporting them, so make it happen.

    Yes, bad queries can run amuck, which is why you give them access to a slaved reporting instance of the DB.

    Your tables are not precious, and they're not even yours, they are your customers. Let them run their queries on the reporting database, never the production DB.

    Regards,
  • Don't do it (Score:4, Insightful)

    by dstates (629350) on Friday May 16, 2008 @01:46PM (#23436768) Homepage
    Agree, just say NO. If they absolutely insist, replicate the tables that they need to see to a second server.

    BTW have they offered to pay for all of the consulting time that they are going to request in understanding your schema and formulating their queries? Has management planned on the increase in personnel that your team is going to need to respond to these requests?

    Finally, if you expose the schema to outside users, you are effectively making this your API. If you want to change your schema in the future, you are going to be breaking all of the legacy queries that you customers have written.
  • by jackharrer (972403) on Friday May 16, 2008 @01:46PM (#23436772)
    Better - show that they would be able to access other customers data and shout "Data Protection Act" as often as possible during demonstration. They'll understand...
  • by TheRealMindChild (743925) on Friday May 16, 2008 @01:47PM (#23436792) Homepage Journal
    I will agree with this, but add one more note. You are selling them INFORMATION that you compile from YOUR data... you are not selling the data itself. I have had this conversations with clients many times.
  • by CharlieHedlin (102121) on Friday May 16, 2008 @01:47PM (#23436802)
    Read Only access can still create locks. I haven't worked with Oracle enough (I assume it is MUCH better), but a simple read query can bring our MS Sql database to a grinding halt if it touches tables that are actively updated.
  • by ctdownunder (816383) on Friday May 16, 2008 @01:48PM (#23436804)
    Sounds like the data actually belongs to your customer.

    And apart from the replication to another server as mentioned, it sounds like you are being a tad childish. For example: "This is my ball, and I'm going home with it..."
  • "I don't like them pawing through my database" makes me think that you're embarrassed by the database structure, and don't want people to see how screwed up it is. If that's the reason, then maybe it's time to fix things.

    If it's just some weird possessiveness thing, then get over it. It's not your data. It belongs to your company. It's their servers, their programs and their data. If they want to give access, it's their decision, not yours.

    Otherwise, a good reason not to allow direct access is performance. Amateurs doing queries against the "real" database can kill the server if they're not doing it correctly. My recommendation is to provision an entirely separate database server with a regularly-updated version of the data (perhaps even a "fixed" version if my first point is in play) and let them go wild on that.

  • Don't be a jerk (Score:2, Insightful)

    by Just Some Guy (3352) <kirk+slashdot@strauser.com> on Friday May 16, 2008 @01:49PM (#23436834) Homepage Journal

    As a DBA, my heart sinks at the thought of amateurs pawing through my database. Unfortunately, 'because you are stupid' is not considered a valid business reason to reject their request. So can any Slashdotters assist me in building my case to restrict access? Have you experienced a similar situation? Have you had to support this sort of end user access? How would you advice me to keep my customer away from my precious tables?

    Let me translate that into non-Oracle DBA terms:

    "Whine! Whine! Whine! I hold the key! Me! This is magic! Whine!"

    Another translation into Customerese:

    "It's my data AND I WANT TO SEE IT, NOW!"

    Seriously, what non-ego-driven reason do you possibly have from not allowing your customers to access their property, aka "their data"?

  • by Anonymous Coward on Friday May 16, 2008 @01:50PM (#23436864)
    No need to lie. Giving direct access to the information *sets the company up* for such a violation to occur in the future when new tables/columns are added.

    As a DBA, you should express this concern to management IN WRITING as soon as possible, for two reasons:

    1. It's your professional responsibility.

    2. It's your career; cover your ass!
  • by Mike1024 (184871) on Friday May 16, 2008 @01:51PM (#23436880)

    However they have now asked for direct read-only access to our Oracle database, [...] my heart sinks at the thought of amateurs pawing through my database. Unfortunately, 'because you are stupid' is not considered a valid business reason to reject their request. So can any Slashdotters assist me in building my case to restrict access?
    Not to state the obvious, but perhaps your justification for refusing access could be based on your reasons for refusing access?

    If the only reason to refuse them access is that you "don't like the idea", you should come up with a proper reason you feel that way, and if you can't, you should change your opinion - or risk gaining a reputation as an arrogant, arbitrary obstructionist.
  • by borkus (179118) on Friday May 16, 2008 @01:51PM (#23436882) Homepage
    ...that they're willing to pay for.

    Pretty clearly, running ad-hoc decision support queries against a transactional database is going to add an undetermined amount of load on that system. So your customer has a few options -

    1. Upgrade your systems to support more load. Obviously, they want to still do their data processing in addition to any queries. If they're willing to cover the costs of the upgrade to insure the current level of service, then there shouldn't be a problem.

    2. If the data doesn't have to be real time (within a few seconds), you should be able to replicate the data on a separate box for ad-hoc queries while active processing is done on the main database. Again, they need to foot the bill for this replicated server, but it may not need to be as beefy as the production box (depends a great deal on your scale/size).

    3. Find a 3rd party to host the data for the customer and have the customer pay the 3rd party directly. Obviously, there may be some development and support cost of maintaining the data feed, but that way the customer understands the actual cost of that capability.

    Now, I don't know the competitive and political environment that you're in. Are there competitors that may have a similar product to yours that allow live queries? Sometimes requests like this are simply to provde justification for a switch.
  • by 93 Escort Wagon (326346) on Friday May 16, 2008 @01:52PM (#23436908)
    Explain to the higher-ups, in detail, how this customer request can (and will) impact your other customers. Then tell them the solution is to replicate the database onto another server, which will be the one the customer will be given access to (as others have said). But make sure the customer foots the bill for purchasing and running that new server.
  • by mcrbids (148650) on Friday May 16, 2008 @01:52PM (#23436918) Journal

    Granted, it costs you a bit in hardware and setup time, etc. But if you're really nervous about it, then it should do the trick. Given the limited load on the replica and its read only nature it should be able to live on limited hardware, like maybe an older server that you have hanging around. Plus you don't have to worry about reliability either. If the thing blows up no data is lost.


    Cost? What cost? Oh, you mean the profit that you'll make from charging the end user for time and "overhead" in setting up the replication?

    That's only a cost to the requesting end user! It's all profit for you!
  • by jedidiah (1196) on Friday May 16, 2008 @01:53PM (#23436948) Homepage
    No. You simply don't understand the problems here.
  • I'm a DBA (Score:2, Insightful)

    by misterjava66 (1265146) on Friday May 16, 2008 @01:54PM (#23436980)
    I'm a DBA
    You should not report off of a production Database.
    Obviously, you will need to have a feed that looks like a report to the reporting DB but this is NOT a report, it is a feed.
    Reporting will harm performance and reliability of the performance of the production db.
    Also, reporting off of a simple copy of the production db is generally undesirable, generally you want to have a warehouse/flattenning/sumarization of some kind for reporting.
    That's the stock reasons to keep this stuff seperated, its done me well for 20 years.
    :-)
  • by x00101010x (631764) on Friday May 16, 2008 @01:58PM (#23437070) Homepage
    You could scare management by explaining to them that allowing direct access will disclose your database schema to the customer which will allow them to reverse engineer some of your service's design and possibly allow them to make their own (eliminating their need to continue working with your company).
  • Just say no and hope that it sticks. Seriously. I find that so many people in the workforce noadays don't know how to say that simple word. No.

    Hey, I have a consulting firm that would be willing to work with the client to ensure they have that database access. :-)

    What we could do is give them the query access via their own public synonym space, and build it into our SLA that we are not responsible for downtime due to their querying. We would also bundle some support costs into the agreement.
  • Re:Don't be a jerk (Score:0, Insightful)

    by kamosa (1162601) on Friday May 16, 2008 @01:59PM (#23437098)
    Seriously, this is the truth. DBA's can be the most pompus silo builders in any organization. The only weak arguement the lot of people on this thread can come up with is "bad cross joins"... Really? That's it. If so, send them to a querry construction class, stop whining and give them access. Here is a hint for free, not everyone besides you is stupid.

    On a side note: Perhaps you should look at why your "service" is so lacking that the customer is asking out of it. After all, if you were giving them exactly what they wanted, they wouldn't be asking to go around your "wonerderful" service.
  • by hrieke (126185) on Friday May 16, 2008 @01:59PM (#23437102) Homepage
    When your customers can write their own queries, what's stopping one of them from
    1. Copying the entire database for their own? CCBA anyone?
    2. Query about their competitors who also use your services.
    3. Give your competitors access to your full system. You'd be a fool not to think that one of your customers hasn't given access to your systems to one of your competitors sales people. Now image if the whole system is open.

  • by Anonymous Coward on Friday May 16, 2008 @02:02PM (#23437148)
    You are correct. Oracle is MUCH better than MS SQL.
  • by Giant Electronic Bra (1229876) on Friday May 16, 2008 @02:08PM (#23437288)
    That's customer service! lol. Think about it, the data is probably required for the customer's business process. So saying 'no' is tantamount to 'you can't run your business', and the customer will become an ex-customer just like that.

    There are perfectly good technical solutions to the problem. As a DBA I would just point out to management what the issues are and suggest the obvious solution (data replication). If management really wants to tell the customer to take a hike, then that is up to them. But at the very least you the DBA don't end up being the nay sayer.
  • by BitZtream (692029) on Friday May 16, 2008 @02:10PM (#23437320)
    With Oracle, all you would demo is that you aren't a very good oracle DBA.

    Oracle has plenty of security and control mechanisms to ensure that a user can't starve the system of resources if you know how to use them.
  • Say Yes. (Score:5, Insightful)

    by Angostura (703910) on Friday May 16, 2008 @02:11PM (#23437358)
    "Absolutely, we would be delighted to provide you with this high-value ad-hoc access system. In order to protect our valuable operational infrastructure this will require the installation of a separate datawarehouse. Provisioning this system will cost $X, the monthly charge for maintenance of the system, the population of the datawarehouse and the provision of secure access will cost $Y"

    The advantage of this approach:

    1. It makes you look helpful and willing to accomodate your customers
    2. It makes it clear what some of the issues are
    3. If you set the values of $X and $Y at the correct values you can generate significant additional revenue for your business
    4. If you set the values of $X and $Y just a little higher, the answer equates to "No".

    Win-Win.
  • by uberdilligaff (988232) on Friday May 16, 2008 @02:14PM (#23437440)
    We don't allow any end-user accounts of any kind on our primary database servers for a number of reasons, but one of the important ones is that a significant number of vulnerabilities that have surfaced for Oracle involve privilege escalation. Many require that a user have the ability to log in to the database before they can exploit the vulnerability. Keeping the unwashed masses out of your database is a good idea, if you'd like it to remain your database.
  • Re:Just say no (Score:3, Insightful)

    by gblues (90260) on Friday May 16, 2008 @02:15PM (#23437456)
    Since when did there have to actually be other clients' data in the database to use that as an excuse?
  • How To Do It (Score:5, Insightful)

    by porkface (562081) on Friday May 16, 2008 @02:16PM (#23437496) Journal
    The business rule here is:

    "This is a complex Oracle database, and yes, even read-only access can cause major problems. These problems are prevented by accessing the data through the approved application.

    If you would like full query access, you will need to provide an Oracle-trained staff member to perform that work. And even then, all warranties on the system are off.

    Our preferred solution to your business requirements in this case is for you to submit queries for approval and/or integration into the front-end application. If there are strict deadlines involved, please let us know and we can try to accommodate those.

    Please understand this isn't an issue of control, but simply of us trying to maintain a high level of quality of service. It may seem like read-only access is safe, but it is not. If you would like further clarification of this reasoning, please contact us and we would be happy to arrange a presentation."

    If they want a presentation, you show them how poor queries can crash the database or cause unacceptable performance problems and misunderstood results.
  • Re:Why? (Score:5, Insightful)

    by vanyel (28049) * on Friday May 16, 2008 @02:18PM (#23437522) Journal
    It may very well be that the original question was a well intentioned response to a gut feel about the resource usage issues, but it comes across as a BOFH "it's mine and you just stay away!", like the "gut feel response" is "NO! now what was the question?". I much prefer "I can, but this is what will happen", or in this case, "A customer wants read only access to a database; I'm nervous about this, but not sure what actual harm they could cause" as opposed to "I don't want to give them access, give me some reasons why I can say no". There is a big difference between the two.
  • by osu-neko (2604) on Friday May 16, 2008 @02:21PM (#23437574)

    That's customer service! lol. Think about it, the data is probably required for the customer's business process. So saying 'no' is tantamount to 'you can't run your business', and the customer will become an ex-customer just like that.

    Um, no. Actually think about it. The customer is already in business and has been for some time without being able to do this. It is therefore an immediately obvious fact that it is not required for the customer's business process.

  • by Nom du Keyboard (633989) on Friday May 16, 2008 @02:24PM (#23437630)
    I see it as a question of just who's data is this?

    Is it the customer's data (and how do you plan to keep one customer out of another competitor's data of they both have this access?) in the first place and you're just storing it for them? If so, then there's a strong case that they should be allowed access to their own data.

    Or is it your company's data that you provide to them on request? In that case they have no rights to anything beyond what you're already providing to them.

  • by an.echte.trilingue (1063180) on Friday May 16, 2008 @02:25PM (#23437646) Homepage
    How you phrase it is everything. "No" will never stick, especially if the customer can easily migrate elsewhere. As a computer guy/dept, management/the customer sees you as somebody who just makes the mysterious boxes do what they want, no matter how asinine you know that request to be. Once you start throwing barriers between the manager/customer and what he thinks he wants, you will soon be replaced by somebody who who doesn't.

    The key is to try to steer the customer to another direction. Often they want silly things like this because they don't know the alternatives. Engage the customer and find out what they are doing, and toss out a better solution. In the end, you will both be happier.

    If you do end up having to give them RO access, I would be sure to write some method into their user interface that restricts wildcards. You don't want somebody doing the oracle equivalent of
    echo "select * from huge_table" | cat > querry.sql; mysql -u user -p huge_db < querry.sql | grep value

    Sounds silly but I saw a colleague write a script that did something about like that.
  • by BitZtream (692029) on Friday May 16, 2008 @02:27PM (#23437682)
    Oracle is more than capable of dealing with this situation.

    You use a combination of views custom to their needs and access restrictions on tables to ensure they only see their data.

    You don't grant them any permission to write to any table or view.

    You configure their user so it can't starve the system of resources so they can't disrupt everyone else that uses the system.

    Oracle is made for this sort of thing. If you were talking about MySQL or PostgreSQL, it'd be a little different as they aren't nearly as mature.

    Being able to configure Oracle to do this stuff is why you get to be called a 'DBA', since you know, DBAs administer DBs.

    Now ... figure out the real reasons you don't want them to have access to the database and make your case based around that, if you have one. Don't try to BS your way out of it with a 'its insecure' or 'its dangerous' excuse, cause in those cases the fault lies in you, and they may very well have a DBA that can point that out. If you want to use those excuses, you shouldn't have used an enterprise class RDBMS that has been capable of dealing with these requests for years.

    Theres a reason Oracle costs a fortune and people still use it over open source alternatives, its MADE for these sort of problems.

    If you don't want them wasting your CPU power for their queries, thats a fine reason. What are they willing to pay to get special access to the data? Its going to cost you time and energy to create a user for the database that has proper permissions, they definately need to pay for that.
  • by sirket (60694) on Friday May 16, 2008 @02:30PM (#23437728)
    Did you even bother to read the original post? The person said their client wanted read-only access. The problem isn't the client messing up data- it's the client bringing the server to its knees with an abysmally inefficient query. Oracle has some features to limit the damage a user could do- but the only truly safe option is a read-only replica.

    The person also wrote that the customer did not want 24 hour old data (you really didn't bother to read the post did you?) so your cube is a useless idea.

    If you think it's a good idea to give clients direct access to your production database then please send me over your resume so I can make sure it goes on our "Never, ever hire this person" board.
  • by Anonymous Coward on Friday May 16, 2008 @02:31PM (#23437762)
    Um, no. Actually think about it. What you're saying is not factually correct - business can change.

    In any case, it is irrelevant whether the data is actually required for the customer's business process. The GP's point is valid because it is what the customer believes that matters.

    Besides, this is an opportunity to make more money from this customer. Why would you say no?

  • This is definitely something that should be stressed. What I provide my customers is a front end with standard queries, PLUS the ability to trigger a backup (either daily snapshot or cumulative snapshot... which takes some time to transfer; our databases are generally around 2-8GB of data) of the database that they can then access and manipulate to their heart's content. At no point do they gain access to live data, but they can take snapshots whenever they want.

    I have been toying with the idea of a shadow database that they can have live access to but which is only updated, never queried, by the main system. This is another possibility for your customer, and provides fresh income for you and your team as you develop this "new product".
  • by Anonymous Coward on Friday May 16, 2008 @02:34PM (#23437802)
    If the database is very interesting than you are putting your self a risk by giving unrestricted access to the database. A client could easily download the entire database and make their own. This creates the risk of duplicate data as well as giving the database to potential competitors if a client was to defect.
  • by romango (632756) on Friday May 16, 2008 @02:36PM (#23437844)
    If the customer does not understand the structure of the data, they can get bad answers that are disastrous. What if the data has the same amount under several categories and the customer decides to add all the categories together to get a total and then makes a business decision based on that answer? I've seen it happen!
  • by Score Whore (32328) on Friday May 16, 2008 @02:37PM (#23437862)
    If the information is what it sounds like, it's information about the customer's activity. There'd be a very difficult argument that you own that data instead of the customer owning it. If the customer did zero data entry, no batch loading, EDI, programmatic inserts and updates, or other data loads into the database would there be anything for this guy to provide his customer? Sounds like he's providing a IT support service not a data source.

    Unless there was a negotiation up front with specific line items to be delivered (certain types of off-line reports, certain types of web enabled reports, etc.) then just butch up and give them what they want. If you don't you're going to lose your customer. If you're a dick about it, you're going to lose your customer and get bad word of mouth.

    Think of it this way: if you believe you should have control of and access to your medical files, credit reports, and bank records; then this customer should have the same with their data. Just make sure they can only see their data.
  • by phallstrom (69697) on Friday May 16, 2008 @02:39PM (#23437908)
    Additionally, your customer will now begin to rely on your schema and when you decide to change it they will be upset. In OO terms you just gave them access to all your private methods :(

    This happened to me. No choice in the matter. And when it came time to build version 2 and make some internal changes we couldn't because the customers had grown accustomed to the schema being a certain way.

  • by pondlife (56385) on Friday May 16, 2008 @02:44PM (#23437974)
    It sounds like you need to look into a reporting tool: Business Objects, MS Reporting Services, whatever. Copy/replicate the data to a separate server to keep the users away from production, and then let them do what they like on there.

    There are good reporting tools that be web-based, write the SQL for them, detect and prevent cross joins, handle logical security (client X can't see client's Y data etc.), use intelligent caching, export to Excel/CSV/PDF etc.

    It may not be the easiest or cheapest thing to set up, but on the other hand it will probably be a lot more reliable and smarter than anything you can hack together yourself. And since you're providing an additional service to your customers, you can bill them for it.

    --pondlife
  • by DRAGONWEEZEL (125809) on Friday May 16, 2008 @02:49PM (#23438056) Homepage
    It's your job to inform your manager whether or not it's a good or a bad Idea to do whatever new someone wants to do w/in your sphere of influence.

    Also while some advocate "just say no." It doesn't work for drugs, and it won't do squat for a client. Especially a mildly informed client that thinks (but thinks they "KNOW") damn near anything in software can be achieved w/ some effort. (IMHO it can) If you take that route, at least show them how it would be less economical.

    For instance, a client just last night wanted 75G of data recovered to be burned to DVD. I wasn't going to go buy a column of dvds, and swap disks all night, while trying to divide it up all pretty. so I said no problem, 4 hrs at 75$/hr, or you can go buy an external drive at costco for 150$ and I'll do this for 1 hr @ $75/hr saving you $75 dollars.
    It wasn't too long before he said "I'll drop the external drive off on Monday."

    There's tons of reasons to do something or not, but if you send it out to Management in these terms, you'll have the best response.
    1. Economics
    2. Your Liability
    3. Decreased (or for a positive, Increased) RVU (more time taken to do less work)
    4. Their Liabilty
    5. Their increased/decreased RVU
    6. Solve the problem, and make sure you make money off of it. Tell your boss that they should front the cost for a project for you to build a shadow server for them to work on. Think how much it'd cost to set it up, make it functional, then support it for 5 years. Write it out as a $ figure, and propose it. Become your own vender, sit the server at clients site, hope their bandwidth costs for shadowing the data is not too high, and reap in the $

  • by Prof.Phreak (584152) on Friday May 16, 2008 @02:52PM (#23438106) Homepage

    Saying ``no'' for business reasons is great; saying ``no'' because there's no good way to handle it technically is a -bad- reason.

    From my experience, sysadmins who overuse the `no' response are a buncha pricks who can't do anything (you know something is wrong when seemingly simple requests meet a ``no'' response or take days to complete [something that would take you a minute with command line access to the server]---big corps are full of such folks).

    As for one possible solution: with read only access, they can't mess things up; most seasoned db admins can ensure that Oracle handles things gracefully---even from stupid read-only users.

    Another solution may be to setup a mirror box, and let'em have at it. Mirror the data every day or so. If they screw it up -somehow-, everything will be reset in 24 hours anyway.

  • by stoolpigeon (454276) * <bittercode@gmail> on Friday May 16, 2008 @02:54PM (#23438138) Homepage Journal
    I think the big deal here is how they connect. Most databases I manage are not being accessed directly by anyone but me and the other dba team members. And we aren't mucking about with data.
     
    Users are reaching the database through applications across many layers of security.
     
    So my concern with the question hear would not be some ignorant user bringing down my system with a wayward query. Good database management will make that pretty much impossible. My concern would be - how do they gain this connectivity and how secure is that connection both ways?
  • by cayenne8 (626475) on Friday May 16, 2008 @03:08PM (#23438348) Homepage Journal
    "Better - show that they would be able to access other customers data and shout "Data Protection Act" as often as possible during demonstration. They'll understand..."

    I don't see what the problem is....just set up a role with select privs. only on that customer's table(s). If you have all the customers' data mixed in the same tables, then create a view on their data and grant select only on that. Or...maybe look into Oracle's granular level permissions you can set up?

  • by dannannan (470647) on Friday May 16, 2008 @03:09PM (#23438358)
    This is a classic example of what someone wants vs. what they are asking for.

    What they don't want is this:

    Someday, probably a Monday, you will get a page. The production website is timing out and they've traced it to the database. A look at the Oracle dashboard indicates that several "ad hoc" queries have been running for the past 4 hours, have blown the cache, and are churning up 99% of the read I/O on the database. You kill the queries. Some customer's ad hoc reports fail, they want to know why and they're especially irritated because they've been waiting 4 hours for the result. The other customers are upset that the main website is unavailable.

    What they do want is a sandbox to play in.

    The production database server is not a sandbox. It's a system of schema and queries there are all designed and QA'ed to meet an SLA. A certain amount of cache is required; a certain amount of logical I/O is possible; queries do their work within those boundaries. The tp99 is under 100ms because it was designed that way. And the schema is not even convenient for reporting. Maybe it happens to be convenient today, but that is a coincidence and things will soon change.

    Everyone would be much happier if the sandbox operation could be managed separately. OTOH, improvements to the reporting schema could be made without requiring a dev+QA iteration on the production website.

    Whatever you do, don't agree to support this feature without getting sign off on the additional hardware and software you need to run that sandbox. If you can't get that, get sign off on a new, weakened SLA for the main production application that will be impacted.
  • by KevMar (471257) on Friday May 16, 2008 @03:12PM (#23438412) Homepage Journal
    You honestly dont have the recources to provide that type of access. Tell them that the database was not structured in a way to keep customer data seperate. You would have to add staffing to manage the security and the seperation of the data. You also know what queries are demanding on the server, so you run them at a time that is low impact to the customers.

    You also dont have a license to grant them access to the schema. If they query the database directly, any back end changes would break the reports they run.

    You dont want to open that kind of access up to your database/network. It makes the entire structure that much less secure.

    And like everyone else said, just tell them no. You already know why you don't want them in. You also understand how the tables relate. It is very easy for someone to wrtie the wrong report because of an important relationship or flag that was forgotten.
  • by Bill Dog (726542) on Friday May 16, 2008 @03:14PM (#23438438) Journal
    If the information is what it sounds like, it's information about the customer's activity. There'd be a very difficult argument that you own that data instead of the customer owning it.

    Who's collecting it? The customer could certainly track their own activity if a company's terms were not satisfactory.

    Think of it this way: if you believe you should have control of and access to your medical files, credit reports, and bank records; then this customer should have the same with their data.

    It's not about saying what a customer can do with their data, it's about saying what a customer can do with your particular copy of their data. I can get my credit report, and look at it 1000 times in a day if I want, but I can't get my credit report 1000 times a day.
  • Re:Why? (Score:5, Insightful)

    by Unordained (262962) * <unordained_slash ... @pseudotheos.com> on Friday May 16, 2008 @03:19PM (#23438516) Homepage
    3) Who is responsible when they make decisions based on the results of queries that were incorrectly written, because they had an incomplete understanding of the tables?

    You currently have a choke point where you can make sure this is well-defined: up-front before they use canned reports, or ad-hoc when they request new ones; when they start writing their own, it needs to be clear that they're on their own, and that they should *probably* at least ask for help along the way to make sure they get what they want (get the right answer), and that what they want makes sense for what they need (ask the right question), and that they understand the limitations of the data (missing data, small sample sizes, small list of codes, known-dirty data...)
  • by pushf popf (741049) on Friday May 16, 2008 @03:27PM (#23438614)
    That's easy.

    Tell them that their contract does not include direct access to the database.

    Once you give them access to the database, you're screwed. They can easily replicate it and dump you.

    They can still dump you if you say "No", however it's more difficult and may not be worth their time or money.

    You could also say "Yes" and make it very expensive.

  • by Just_Another (319311) on Friday May 16, 2008 @03:31PM (#23438670)
    What about your license with Oracle? Will that allow such access? Their licenses tend to be restrictive about this type of thing.
  • by Z00L00K (682162) on Friday May 16, 2008 @03:32PM (#23438688) Homepage
    What you can do is to create a replicated database where they can execute their queries and do their mistakes. So if they bring down that secondary server it won't affect the production system.
  • Re:Why? (Score:2, Insightful)

    by Anonymous Coward on Friday May 16, 2008 @03:40PM (#23438812)

    Well intentioned or not, your response is like telling someone who's asking for directions that they are lost.
    I disagree. Grandparent post made an excellent point, which was more like finding someone who is asking for directions and suggesting a better destination.

    The original poster is asking us to dream up business reasons to justify his emotional preferences. Sure, there will be costs and problems associated with opening up database access, but there may also be significant benefits to his company. He shouldn't be asking for help building a case against open access. He should be asking for help understanding both sides of the equation.

    If impartial judgment really shows that the disadvantages outweigh the advantages then he needs to be prepared to make that case without letting his emotional issues clutter the discussion. If it looks like he's whining, he may lose, even if he is right.

  • by MrAnnoyanceToYou (654053) <dylan.dylanbrams@com> on Friday May 16, 2008 @03:43PM (#23438840) Homepage Journal
    Personally, I think a better way to solve the problem would be to spec out exactly how much time it would take to implement what would be necessary to accomplish the task at hand. Mention how long the first pass of addressing what the task would require would take, and be open and honest with exactly how much money this will cost, as well as what kind of system resources it would consume.

    If your database isn't designed for separation of customer data, and your data structure needs to be somewhat reorganized, you are going to come up with a fairly large number. Mention that there will be downstream issues, and that it's partial system redesign.

    Present options; you know what they are, you know what they will cost as far as your time is concerned. Is this account worth bringing someone on to take over some of your duties, or paying you overtime at double time for the next two or three months? Saying, "No, I don't wanna," is fairly ineffective; showing people (in numbers) why you're uneasy about the issue might help.
  • by jellomizer (103300) on Friday May 16, 2008 @03:48PM (#23438910)
    No that is wrong thinking... That is like saying modern farms can get by if they toss all their tractors and go back to ox pulled plows. The market is changing for the client having the data directly on the server for them to quary at will can give them them a competive advantage or at least to prevent competitors to have the advantage. So it could lead not having this data could kill the company.
  • by colinnwn (677715) on Friday May 16, 2008 @03:52PM (#23438966)
    ...that makes the IT department a liability.

    Providing improvements to business processes where technically possible, affordable, and not illegal is the number one job, just above securing company data. Because if you can't do number one, there isn't much worth securing for number 2.

    Is a requested enhancement required for a company? Probably not. Is it important to provide continuous improvement and efficiency to keep the company competitive? Frequently it is.

    I'm all for standing up and saying what kind of resources and safeguards are necessary to provide an enhancement so the company can decide how to expense the upgrade. But just saying ninny, ninny, boo, boo, you can't have it is ridiculous.
  • by j0eshm0e (720044) on Friday May 16, 2008 @03:54PM (#23438986)

    Seriously, this poster's attitude is WAY wrong! Instead of throwing up barriers which will only piss off your customers (which now even Microsoft knows is a bad thing), you need to solve 'why' they are asking for this in the first place, and then giving then a viable solution.

    That customer obviously has a valid business reason for asking for this --probably the condescending tone he gets whenever he asks for a one-off report-- and the DBA better jump at the opportunity he has to show how he can meet a client's need. If that means getting better metal to handle the increase in adhoc queries, so be it.

    The poster needs to remember it is that customer who generates his pay-cheque, and lay off the 'top of the food-chain' crap that'd see him fired if I were his boss.

  • Missed point (Score:2, Insightful)

    by ohtani (154270) on Friday May 16, 2008 @04:00PM (#23439074) Homepage
    I think a lot of these comments missed the point. It's not that he's not thinking of saying no. It's that he doesn't know HOW to say no or what reasons to give. So telling him to "just say no" isn't sufficient and was a no brainer from the beginning.

    I think the arguments I saw that were best boiled down to the fact that you are providing an information service, and that you're not selling the data. And the other thing is that they need to know the downfalls of somebody inexperienced bringing the whole server to a crawl.
  • by Awptimus Prime (695459) on Friday May 16, 2008 @04:31PM (#23439474)
    Well, the submitter is obviously not worth his salt if he can't make simple job decisions without "asking slashdot" and calling his paying clients stupid in a public forum. It probably wouldn't be terribly hard to put two and two together if a client happens to read this site and say to himself "I don't know, but I think this is the company we are dealing with" and looking for a provider of services that has their shit together a bit better.

  • by Minwee (522556) <dcr@neverwhen.org> on Friday May 16, 2008 @04:36PM (#23439560) Homepage

    First, you have to start by saying "Yes". Then you let the customer decide on his own that he really doesn't want what he just asked for.

    Your problem is that the customer has come to you with a business problem. Someone, somewhere, has decided that it might be fun to have full access to SQL queries instead of those boring prepared reports they have been getting. Chances are that it came up in a meeting when one of the customer's own technical people was trying to explain why he couldn't deliver the Moon, two pieces of cake and a pony upon request.

    "Why can't we get more detailed data than this?"

    "Um, because it's not in the report. We would need, uh, raw SQL access to the database to get that and that's not going to happen."

    "Why not?"

    "Um, because those guys won't let us."

    The idea built up momentum until it got to you. So far all that they can see is that they have business reasons for wanting data and all they need to do is ask you for it so they can have it. Now you have very understandable technical reasons why you do not want unwashed, barely literate knuckle dragging Neanderthals who don't know the difference between an outer join and an outside straight from being able to touch your database. Unfortunately they are _technical_ reasons and not _business_ reasons and business trumps technical. Think of business reasons as being 'Paper' and technical reasons as 'Rock'. Oh, and some kid ran off with the scissors, so that's all you have to play with. The only way to win at that game is to keep choosing 'Paper' until your opponent gets bored and leaves.

    So how do you do that? You forget about the technical problems and explain the simple _business_ costs involved in resolving them. Your customer needs access to a database? Fine. Naturally they can't just use the main database for that. They will need their own dedicated reporting database server. (Ching!) With software licenses. (Ching! Ching!) And storage. (Ching!) Plus administrative overhead, datacentre costs, additional bandwidth, and so on. (Ching ching ching!) These are all things which you will need to provide to the customer in order to give them their pony^W own database to play with. All they need to do is pay for them.

    Suddenly the technical problem of "No you can't play with the main database server" turns into "Of course you can have that if you pay $X up front and $Y additional annually", which is a business problem. Write up a rough quote, send it to the customers, and let them decide for themselves if their sudden whim of making their own queries justifies the actual costs involved in having it. If you have any alternative suggestions such as how you could provide additional canned reports or develop a slightly more flexible set of queries which they could use, feel free to attach estimates for the real costs of those projects too.

    The key here is to make sure you tell them that you would be quite happy to provide any of the solutions you have offered. If they're smart, and your estimation of the costs of replicating your entire DB server are accurate, they should be able to talk themselves into doing the right thing without any further encouragement from you. If, on the other hand, they do decide that it's worth that much to them, and you're smart, then you should be in a good position to sell them that additional service.

  • by lakeland (218447) <lakeland@acm.org> on Friday May 16, 2008 @04:54PM (#23439838) Homepage
    Of course Oracle has permissions. That area of Oracle is substantially more sophisticated than MySQL's, not that surprisingly really - large enterprise access is bread and butter for oracle. Oracle's permissions are so fine grained that most people haven't heard of half of them... has a very nice permission set called 'roles' which allows you to carefully work out a set of common permissions and easily grant them all to a bunch of users. One area Oracle is missing for some reason is grant permissions at a schema level (which MySQL would call a database) rather than the object level - it is something that comes up a lot in practice.

    However, when you start talking about load issues, that's where things that are feasible in MySQL just aren't in Oracle. Presuming this DBA is running Oracle EE, he'll be paying $40k/CPU (or technically, $40k/2 cores). That means for him to replicate onto another box for load issues will cost him an extra $40k just for a simple dual-core machine. Or $45k say, hardware isn't completely free.

    If he wants that load balancing to happen automatically rather than telling clients which machine to log into, then Oracle has a much better product than MySQL's cluster. Unfortunately, MySQL's cluster is virtually free, while Oracle RAC is over $500k. At the same price, I would have chosen RAC over Cluster, but with that kind of price difference...

    So, I think it basically comes down to load issues. Scaling up an Oracle install is unaffordable without a great business case and expecting random clients to not bring the server to its needs (granting them unlimited CPU) won't work - especially on a server which no doubt has limited cores - while not granting unlimited CPU will lead to all sorts of confused issues logged about queries failing.

    There are plenty of solutions. Replicate onto Postgres (it supports Oracle's syntax so would be a better choice then MySQL). Create some nice star schemas and export via Discover or similar, replicate onto a machine that the client supplies and pays for licencing of, etc. Ditching Oracle EE and going SE might be enough too, the EE features are nice but not when they prevent business growth. Writing a custom SQL Server integration and syncing daily is probably only a few hours work and good enough for a DB up to about a TB if daily sync is fresh enough. That's just off the top of my head, I'm sure there are more options.
  • by Vellmont (569020) on Friday May 16, 2008 @05:01PM (#23439950)
    This is the first intelligent reply I've seen.

    There's too much of an instinct in IT to think of the systems as "yours", and protect your little kingdom. It's a computer, not your children.

    The only thing I'd like to add is, if the customer wants this kind of access (and I'd agree about the replication system), then it's going to cost something. This kind of thing isn't cheap, and it should be free. Estimate some reasonable setup costs, as well as maintenance costs, add some kind of profit margin to each, and present it to the customer. Let THEM decide if it's worth the price.

    This is a business decision. There's really no reason the technology can't provide you a level of protection from the customer access to the system. The difference is they have to be willing to pay for that access.

    We successfully avoided letting the customer see how awful the design was until the contract ended (it was a fixed term job that could not be extended) by making the IP argument.

    Heh. I'm sure you can fool a non-developer with a line like that, but anyone that knows anything about software development knows that schema is about worth nothing, and you're just trying to hide something.
  • by stoolpigeon (454276) * <bittercode@gmail> on Friday May 16, 2008 @05:10PM (#23440066) Homepage Journal
    The added bonus is that if you have them using sql*plus - their love for ad hoc queries may be short lived. :)
  • by 2short (466733) on Friday May 16, 2008 @06:11PM (#23440740)
    Seriously. If our sales guys had the clients name, we'd eat his lunch.

    He seems to think 2-8 GB is a big database. If the customer wants some custom report, he thinks emailing someone who writes custom SQL and sends them an excel spreadsheet the next day is a process that "ticks along happily". If your customer is asking for direct SQL access so they can bypass you and do stuff themselves, your process is not ticking along happily.
  • by mikelieman (35628) on Friday May 16, 2008 @06:17PM (#23440792) Homepage
    "Who's paying for this?"

    DBA time ain't exactly cheap, and setting this all up, the needed SysAdmin time to get the firewall/proxy port issues worked out/certificates setup, etc...

    Figure 40 hours of time for the DBA and 30 hours for the Sysadmin..

    160 and 240 per sound good?

    That's $ 13,500.00

    You guys ain't planning on doing 10 grand worth of work for FREE, were you?

  • by sumdumass (711423) on Friday May 16, 2008 @06:43PM (#23441024) Journal

    There's too much of an instinct in IT to think of the systems as "yours", and protect your little kingdom. It's a computer, not your children.
    The problem is that a lot of times, the buck stops with you and your reputation is on the line when someone else borks something.

    I had a system that was breaking about once a week and I was getting some real heat from the managment to keep it running. It was usually on a Saturday when it failed and sometimes on a Thursday night. I eventually started suspecting that someone was messing with it because there were no logs of anything and none of the usual "something isn't acting right" when it would bork. I even started replacing things that I knew couldn't be the cause of the problems but it was about the only thing I haven't done yet. I wiped and reloaded the system 3 times, each time holding off on all the updates in case one of them was causing the problems. After about a month, I changed the passwords and took an IP camera in and set it by the terminal. Turns out that one of the members of the cleaning crew was on site alone during those nights. He would get the password from the sticky note on the wall of the management's office (why it was there, I will never know) and run a counterstrike/half life server from the server. He would then turn all the services off that he thought nobody needed, half ass his work then pull a laptop out and spend the next 4-6 paid hours playing games over it.

    After this came to light, I found out that another client I had been attempting to get a contract with talked to the managment of this place and got a bad review specifically because of this server having repeated issues that I couldn't fix. After the real problem was known, the client called me up and gave me the contract I was looking for and specifically mentioned that he was worried because of all the trouble I was having with the servers at the other place.

    It isn't just that one time either. I have sites that we totally lock down and reimage the profiles each night so any unapproved changes to the systems is removed at the end of each shift. I find that I am having to look for reasons to show up to those sites and make sure everything it working right. I also have sites where power users are present without any restrictions and I am constantly being called in to fix something. In fact, If I can keep people away from IE and outlook (express), convince them to not install anything not directly related to their work, make sure an up to date anti virus scanner is present, I don't have too many problems outside of hardware failures and stuff outside our control.

    We protect the system like they are our children because our reputations are on the line. In many situations, our reputation determines out pay or potential pay. It stops us from doing productive things when we have to fix over people's mess up's that they attempt to hide so they don't look bad. Even if you can always blame it on someone else, you still end up looking bad because your always blaming someone else.
  • by Giant Electronic Bra (1229876) on Friday May 16, 2008 @07:13PM (#23441262)
    Well, at the least you build your counterargument on top of a bunch of assumptions. All we're presented with here by the OP is the technical issue. We know he has a customer, and that the customer has access requirements to a database.

    It might well be reasonable for someone to ask "is this the best way to give them what they want", but I can pretty well see you haven't had to deal with the customer side of a business if your response is going to be "you are an idiot and you cannot have what you ask for".

    I work directly with my customers. I know what kinds of things piss them off. I can almost guarantee you the right thing to do is figure out a way to get them what they want, or at the very least to convince them you can give them something better.

    Truthfully it may not even be necessary to discuss it with the client. Depending on how they're billed or what the business relationship is you might well just give them access to a slave database and they don't even need to know a thing about what the solution was.
  • by Anonymous Coward on Friday May 16, 2008 @07:22PM (#23441330)
    I am a very senior level DBA. I am experienced in both Oracle and SQL Server. As a DBA you must develope a firm voice of authority based upon your knowledge, skills and experience. As a DBA, it is both anticipated and expected for an experienced DBA to provide access to the "precious" database" for the paying customer. You simply need to research the best solution before providing access for that client (to access their data only). Of course, depending upon your level of DBA experience, you could easily create limited (least privilege) access with user permissions, application permissions, group or role permissions, views, triggers, & or stored procedures, ect. How many years of production Oracle (DBA) database administrator experience do you have? It sound like the customer thinks they can do a better job pulling back ad hoc reports. Why not ask exactly what type of data the customer may need and get that data set up into a view and also provide the customer with select permissions to access that view of their data? I ask because you stated: "However they have now asked for direct read-only access to our Oracle database, to be able to run ad-hoc queries without consulting us. As a DBA, my heart sinks at the thought of amateurs pawing through my database."
  • by GaryOlson (737642) <slashdot AT garyolson DOT org> on Friday May 16, 2008 @07:32PM (#23441384) Journal
    Outstanding real examples. And very informative for those who question why system admins/DBAs distrust just about everyone.
  • by dredmon (1290946) on Friday May 16, 2008 @08:09PM (#23441760)
    There are so many posts, so I am not sure if anyone has posed the question of, "Is this your decision to make?" I trust your DB expertise. Depending on the size of your company, if there are "higher ups" beyond you and they are accessible then you may consider presenting the situation to one of them. Here's why: Sometimes customers ask for things they should not be asking for out of stupidity. On some occasions, they ask out of evil genius. The customer may know they shouldn't ask for this and therefore try to run it through channels that are inappropriate in an effort to pressure an answer they shouldn't get. Then they can argue the "high ground" that their request was agreed to. As a developer I have had this done by various clients by accident and by deception. We all like to be the smart person with the answer one way or the other, but I have learned to "run it up the flagpole" when I felt it appropriate. I have experienced 3 different categories of results: 1. I am concerned about reason A. The higher up simply agrees or disagrees. Either way it is a CYA 2. I am concerned about reason A. The higher up knows about reasons B and C that I was not privy to. The higher up actually provides me more ammo for it not to occur and may actually step in to handle the customer. (I know it is rare, but it happens) 3. I am concerned about reason A. The higher up knows I am right but due to reasons E and F that I may not be privy to. The higher up decides to appease the customer regardless of reason A. That is my humble offer of a way to handle this. Good luck, dredmon
  • by Anonymous Brave Guy (457657) on Friday May 16, 2008 @08:14PM (#23441796)

    I don't think there's much doubt about why your typical sysadmin distrusts a lot of people. Whether it's a sensible policy is a different question. What happens when you start distrusting otherwise reasonable people and it hampers their ability to do their job is that those reasonable people will do whatever is necessary to circumvent your protections. Unless you are literally operating in something like a military base or a bank vault, there's always something.

    Or, you could just support the competent people in doing their jobs, and save the distrust for those who earn it.

  • PLOY (Score:1, Insightful)

    by Anonymous Coward on Friday May 16, 2008 @08:19PM (#23441828)
    This is so stupid it has to be a hook to get free dba advice!!!

    Uggh.

    With data houses, cubes, replication, log shipping, backups/restores, snap shotting and a score of other things i've probably missed, how do you even ask this question and call yourself a DBA!!!

    Disclaimer i'm not a dba.
  • by bugs2squash (1132591) on Friday May 16, 2008 @09:02PM (#23442162)
    ..."Have you experienced a similar situation?"...

    Yes, It frustrates me frequently that useful, non-contentious (ie. not hippa, ssn, pci, DoD etc.) data seems to make a one-way trip into the corporate oracle system to be held hostage there by the dbas for not much good reason than they want to ensure perpetual employment.

    There are plenty of good ways in which this data could be made available. Hell; save it periodically to a flat text file, but don't lock people out of it. You're the guardian of the data, not its gaoler and I'm willing to bet that the people that want access to the data have their reasons.
  • by Symb (182813) on Friday May 16, 2008 @09:14PM (#23442236) Homepage
    The problem you face is trust; not technology. Trust requires rapport. Rapport requires experience. Try to think in terms of resource impact instead of "turf" or "stupidity." Consider these options, some mentioned before...
    • Trust them. Tell them you are trusting them. Give them a trial timeline. Then give them honest feedback after the trial.
    • Bill them. Tell them the resource impact of downtimes, restorals, and performance problems. Tell them they will be charged. Build an appropriate continuity plan.
    • Give them a replica. Then run their releases through your own QA.
    • Incorporate them in the dev cycle. Give them access to dev-test. Then you move their work to prod.
    • Show them they can trust you with a demonstration of the damage that can be done and the techniques you as an expert use to stop that from happening.

    Try not to squelch their enthusiasm to explore. It will likely mean new business opportunities for your company.

    If you are really "hiding" information as its owner and not "protecting" information as its custodian, then you should consider a different business model, one where the value is placed on the data and not the service.

    I am constantly reminded to look away from the monitor for for a few minutes and talk to people by this great quote from an interview of famous programmers [stifflog.com] I found on slash [slashdot.org] a few years(?) ago.

    The next big thing in computer programming will be eclipsed by the next-next big thing in programming, and so on, and so on. I'm kinda tired of the endless search for the big things, because while doing it people tend to forget about the real issues: getting the fundamentals right. We need to get a whole lot better at talking with our customers, focussing on delivering value, and taking pride in what we do. A developer who can do these things can deliver great software with any tool set, and won't need to worry about tracking the fads and fashions.
    - Dave Thomas, Author or The Pragmatic Programmer -
  • who are you? (Score:3, Insightful)

    by nguy (1207026) on Friday May 16, 2008 @09:45PM (#23442420)
    I'm sorry, but who are you to make that decision for your management and your customers? Did you pay for the creation of the database? Do you pay for the machines?

    Your job is to tell people how much it would cost (time, extra load) to support this, nothing more. And you should be honest about it, not make up some silly numbers. The decision on whether to grant the access is between your management and the customer.
  • by magarity (164372) on Friday May 16, 2008 @09:48PM (#23442444)
    Depends on your line of business.
  • by Hacksaw (3678) on Friday May 16, 2008 @10:30PM (#23442728) Homepage Journal
    I don't know that it applies to this situation, but one of the problems of letting random people in a company produce their own queries and the reports thereafter is that one can write a query which looks okay, but actually skews the data to make the report writer (often a mid-level manager) look good.

    So, one reason to refuse direct access is reporting integrity.
  • by Choozy (1260872) on Saturday May 17, 2008 @12:12AM (#23443180)
    If you believe that a couple "adhoc" reports are going to kill your database. It is DBA's like you that shit me to tears. What, are you scared that when they see how badly you've set up the database tables and joins that they are going to laugh at you? Honestly get over yourself and be a professional. If you are really scared that these amateurs are going to put too much demand on your system (although I believe that you are the amateur and don't know how to manage a database) then make a copy of it. Set up an overnight script and create a data warehouse or use the flashback ability that is available in ORACLE 9+.
  • by Anonymous Coward on Saturday May 17, 2008 @12:55AM (#23443410)
    Your attitude represents everything that is wrong with typical 'IT' thinking: "Pesky customers/business-stakeholders/clients - life would be much easier if they'd just leave me alone in my office to surf pr0n all day". Give them what they want, or they'll go elsewhere. If you can't figure out how to manage resource usage on whatever your database is, especially when the requested access is R/O, then you should look for another vocation. If you ever wondered why IT orgs get outsourced, look no further than this example.
  • DO YOUR JOB (Score:4, Insightful)

    by Unoti (731964) on Saturday May 17, 2008 @12:57AM (#23443422) Journal
    You're a DBA. You're supposed to figure out how to give your customers access to the data they want, not to keep them away from it. You have forgotten what your calling is. You should be ashamed of yourself. Stop asking yourself how to restrict access and lock your customer out, and start asking how to give them what they want.
  • Why ever not? (Score:3, Insightful)

    by cruachan (113813) on Saturday May 17, 2008 @06:41AM (#23444562)
    You have this completely the wrong way around. I always welcome interested user-access to my databases, except of course I make sure that they have access to read-only views set up so they can extract the maxiumum amount of business information out with the minimal amount of sql and if performance is an issue I give them access to a replicated copy (it's very rare indeed that a business user won't be happy with a nightly update).

    I used to work in blue-chips inhouse as dba, and now I'm an consultant to a mix of large and small businesses. In both positions one thing I always try to do is identify an office worker who is interested in IT and encourage them to act as the local 'expert' for extracting data from their databases. There's always someone in an office who everyone else asks first to fix their computers, if you identify them and take them under your wing not only do they get a lot of status from being the local expert (and possibly a good argument for a pay increment!) but they keep you from having to do mundane sql enquiries and you get a natural ally with your users.

    Don't make the mistake of dismissing office clerks as somehow stupid and not capable of handling the mysteries of IT like you do. Generally these people will be massively familiar with spreadsheets so explaining tables as like spreadsheets is an easy first step. I've encouraged and trained clerks to the level where they can throw around multi-level joins and subqueries quite happily (and taking acount of the indexes!) before now and these people often have an advantage over you in that they probably know the data at a more intimate level then you do. Furthermore having a good fan base of such people tends to work well for you as they then appreciate what a dba actually does and they're sure to make nice noises to their bosses.
  • by Kreigaffe (765218) on Saturday May 17, 2008 @11:51AM (#23446000)
    Except in the business world, NOT assuming your paying client is a complete fucking idiot is a big mistake.

    Most people are complete fucking idiots. And frighteningly, many of them THINK they know what they're doing.. and if you go ahead and let them, and they fuck things up, they'll tend to fall back on the one thing they ARE good at.

    Blaming someone else.

    (and if they're management, that's about the time you're forced to promote them so they have less opportunity to create huge fuckups)
  • by jdray (645332) on Saturday May 17, 2008 @01:18PM (#23446516) Homepage Journal

    How else would you do it?
    Create a replicated reporting database that the users can tie up with poorly-written SQL all they want?

What this country needs is a good five dollar plasma weapon.

Working...