Is there any point to having a dedicated development database server(s) that all developers can use, i.e. they don't have a local copy of the db in their machines. Quite clearly, this will slow down development but I'm curious whether anyone actually does this in the enterprise level. I know I should trust the devs we hire and I'm guessing this will mostly be the kind of answers that I will be getting but if anyone actually does this I would want to know if it's even worth doing.


Great answers. My question arises from this question from quora regarding source code protection: http://www.quora.com/How-does-Facebook-protect-their-source-code

Here's the pertinent answer that got me thinking:

Facebook (and Google and probably many others) don't have employees check out code on their laptops. Code is checked out on developer servers or workstations and employees connect to these to work. These are only accessible on the corporate network, and connecting from outside the network requires VPN, which itself requires multi-factor authentication.

Now that I think about this, if developer have terminal access to the development servers then they must have access to mostly whatever is in there which most likely includes the db.

  • 5
    How would they even write database queries without knowing the schema? – CodesInChaos May 11 '15 at 9:04
  • 1
    Consider the cost of a developer hour. Then calculate the cost of slowing your developers down ;) – Oded May 11 '15 at 9:05
  • 1
    If your application is well written, knowledge of the database scheme shouldn't allow any attacks. Don't rely on security-through-obscurity. – CodesInChaos May 11 '15 at 9:05
  • 1
    You don't indicate what you think the advantages might be, so your question comes off like "Is there any point to tying your shoelaces together?" Where does this question come from? – user7043 May 11 '15 at 9:21
  • 1
    Having a development database server instead of local development databases is quite common, at least in the Oracle world. Several instances, spread across the development PCs, are rather cumbersome to keep up-to-date. – user281377 May 11 '15 at 9:39

Sometimes you have a corporate environment where development is client-side only, and databases are the realm of the DBAs. In these cases, devs will still have a common development instance to work on even if they cannot make changes to it, they can still fill it with crap data for testing. If your DB is a mainframe or minicomputer, then chances are the API to access it wil be via stored procedures rather than plain SQL, in which case hiding the underlying schema is ok as the devs don't need to know it - they do need to know the sprocs however.

Incidentally, even if you do have devs with local DBs they use, its still worth having a centralised DB server that hosts the 'last release' or even just an integration DB, so devs can test their code against a known state DB with good (or reasonable) data in it.

The 2nd aspect is code security. I used to work for a company in the financial services sector that took security very seriously, our offshore devs would only work on code by RDPing onto computers that were hosted in the local office. My laptop was locked down to prevent use of filesharing and email websites and things like the USB ports were disabled. I think this is required for PCI security accreditation.

|improve this answer|||||
  • You may consider to edit your question due to the changed question title. – Doc Brown May 11 '15 at 11:12

If you have Devs and DBAs rather than just Devs then you should probably only allow devs to access the DB via SProcs. and thus knowledge of the underling schema is not needed. A test DB could be created which always returned static data in response to sproc calls and Dev velocity would be unaffected (possibly even improved!)

However, in my experience, even if a company does have a separated DBA team, its usually the Devs who write the sprocs and table schemas etc which are then handed off to DBAs who look after the DB infrastructure/backups/indexing etc

In this case its ridiculous to hide the schema from the devs who are writing it.

Also, I'm not sure any security benefit is gained by hiding the schema. Or even the source code! Unless you have a very technical cutting edge product (in which case you should patent the algorithms) Anyone can code up a better version in a few months.

In fact, if your product is any good, you can probably already download an open source version for free.

The value of a software company is it user base and copyrighted names. Not its code.

Answer to rewritten question : Should Devs be allowed local Databases

OK, Assuming your Devs create the database schema there is no difference (security wise) between code and DB schema.

ie. You should have a DB project and maintain the schema in a source control system. Having a local DB is just an implementation of the schema and increases no risk.

Now you can argue that not having source code locally on a laptop which is taken out of the building is a security benefit. Even if you trust your devs laptops are lost/stolen all the time.

But this isn't really an argument for or against local vs development DBs its an argument for not taking development computers home. Which, unless you have people working from home why would you?

If you have remote workers, then yes you can address security issues about stolen computers releasing confidential info. but I would be far more worried about confidential customer data/emails etc rather than sourcecode/db schema

|improve this answer|||||
  • 1
    This answer doesn't seem very useful to me. Accessing a database only through store procedures is cumbersome and probably makes the product slower. Having those stored procedure return static data in the test DB means that developers cannot even properly test a simple CRUD application. And unless we talk about very small programs, the idea that "anyone can code up a better version in a few months" appears to be somewhere between unlikely and ridiculous. – user281377 May 11 '15 at 10:00
  • 1
    SProcs are generally considered the fastest way to access DBs and give a level of abstraction which allows DBAs to refactor databases for speed without changing the code. Most big shops will use this model. – Ewan May 11 '15 at 10:02
  • Rewriting in a few months is perhaps extreme, but entirely feasible. Even what would have been cosidered 'large' bits of software like Word, operating systems or programming languages are now routinely developed by new players. Due I think to the large about of open source code out there which can be used to implement the known very quickly – Ewan May 11 '15 at 10:05
  • Note the OP has changed the question title to match his real question - seems you answer does not really fit any more. – Doc Brown May 11 '15 at 11:09
  • Jeeze, does the question even make sense anymore? – Ewan May 11 '15 at 11:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.