Slashdot Mirror
Keeping Customer From Accessing My Database?
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?"
Don't use your work e-mail address when you call your clients "stupid" in a public forum?
(It's two a.m. here, I bet somebody'll point out some completely idiotic assumption I made in about two seconds. Oh well, so it goes.)
I thought Oracle DBA's were all uber-brilliant? Everyone I have met has told me so.
Anyhow, you never give end users direct access to tables. Never. Users who create nice cross joined tables will bring your system down to a crawl Create data dumps to ancillary database -- one per company in this case. And that is if your management won't back you up in just saying "no". I know this much, and I am NOT a DBA.
See my journal for slashdot ID's by year. Mine created in 2005. http://slashdot.org/journal/289875/slashdot-ids-by-year
Be sure to refactor the tablenames. The customer will catch-on when the "Moron" flag in your users table is set to 1 for their login.
What's the worst that could happen if you issue them full read access? I work at a major isp, and I just gave a customer full read access to our client database server (which I am typing this from). As you can see, everything is operating perfe
Wow, you're right. Next week "Ask Slashdot: How to find a DBA job after being fired from EDS"
select bt.* from big_table bt, bigger_table bbt, biggest_table bbbt where bt.id=bbt.bt_id order by non_indexed_column;
Perhaps a good left outer join tossed in there to really thrash the drives. why join tables anyway? if you really want to fsck your server just SELECT * FROM HUGE_TABLE t1, HUGE_TABLE t2, HUGE_TABLE t3;
if you want to make it less obvious feel free to throw in a few FIRST_ROWs, RANKs and DISTINCTs
Oracle has a different concurrency model to older versions of MS-SQL. There are no read locks.
You just violated the MS-SQL license.
"what kind of DBA is unable to create views and restrict access to tables?"
One that works for EDS, who are famous for their incompetence. Next question!
A pizza of radius z and thickness a has a volume of pi z z a
no, the cross-join (or unbounded join) was deliberate, I think adding a nice left outer join on top of the cross-join would be just the icing on the cake, or sand in the bearings.
Remind them that simply because they don't have to use the waterfountains for coloreds anymore doesn't mean you two can coexist in the database together.
Then put a white sheet over the server and a noose from the CDROM tray.
never EVER show your privates to a customer.
Snowden and Manning are heroes.
Slashdot-reading paying clients, at that. I'll be discussing the option of switching providers with management after reading this thread.
You hit the nail on the head.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.