16

I've been a programmer for the past six years. Throughout my career, I have worked on many web applications.

Most of the time, when a database was needed, it was given to us (the programmers) or we had some legacy database to work on. If not that, we had to create and design the database on our own which was not that tough.

But are we, as programmers, supposed to create the entire database from scratch when we have to build new application where data is so important and have messy requirements with a complex data model?

Isn't it in the best interest of the app and the company to get it done by an expert?

I am not trying to run away from designing the database, but it's a thing that is so important to get right.

Dynamic
  • 5,746
  • 9
  • 45
  • 73
ajm
  • 1,255
  • 1
  • 10
  • 23
  • 2
    The answer is yes. Is the correct answer here going to help your management change their mind? I don't think so. And on the other hand, it will be a very good experience to have. Why not give it a try to design the data schema? – eminemence Apr 28 '12 at 11:50
  • 9
    "DB expert" and "programmer" are not mutually exclusive. You'll want an expert to design the database. That expert could be a programmer. – Lord Tydus Apr 28 '12 at 12:06
  • 10
    Is it my job as a soldier to know how to ride a horse? This may or may not be part of the training, but if for some reason your survival depends on the horse, then the answer is obvious. If your job description is changing, surprising, then maybe look elsewhere. I personally would pick up these db skills just because I do not like to depend on others. – Job Apr 28 '12 at 15:20
  • @Job couldn't have said it better :) – Songo Apr 29 '12 at 02:13

5 Answers5

32

First of all, it's your job if the project manager tells you so. Smaller companies often don't have full-time DB experts. There isn't (and shouldn't be) a clear distinction between developers and DB experts anyway - any good developer will have considerable knowledge about DBs, and any good DBA will know how to code, at least in the DB's language for stored procedures.

While the DB design is a pretty central part of an application, it's no more important to "get right" than other central parts that a lot of other code will depend on.

And just like code, the idea that you get some super-expert to sit down and think hard for a week and then write down the perfect design that will never need to change is an illusion. The DB design can and will change as the application is being developed.

It is therefore actually beneficial to have the DB designed by a programmer (who understands DBs well), because then you have someone who knows both sides. That's certainly better than having it done by someone who only understand DBs and has nothing to do with the rest of the development work.

Michael Borgwardt
  • 51,037
  • 13
  • 124
  • 176
  • Could you please tell me the difference between a DBA and a Database developer when it comes to database design? – Songo Apr 29 '12 at 02:18
  • @Songo: IMO there should by no difference. – Michael Borgwardt Apr 29 '12 at 07:14
  • 1
    really? I always thought a DBA was more about running a database and tuning it while a database developer is more concerned about database modeling and design! – Songo Apr 29 '12 at 07:16
  • @Songo: How a database is designed has a huge influence on how it's run. Either job will be done much better by people having experience doing both. – Michael Borgwardt Apr 29 '12 at 07:21
  • 3
    Database administrator and database developer are two different things. Small and medium size companies normally don't know the difference. When working in a large enterprise system you may have dba, business intelligence developer (analysis services, data warehouse) and a database developer. To us those are very different jobs. – CodeART Apr 29 '12 at 08:47
  • 1
    @CodeWorks: They're certainly different, but IMO it's an organizational antipattern to entrench excessive specialization of that kind, as it makes collaboration between people who know only their specialization very problematic. – Michael Borgwardt Apr 29 '12 at 09:08
  • That's a good point, collaboration is equally important so Ideally we should strive to have a good balance of the two :) – CodeART Apr 29 '12 at 09:12
  • I've never been in a company where I wasn't expected to be able to design a database, knowing at least the 4 normal forms and understanding querying & performance mechanisms.... – C Bauer Oct 21 '15 at 13:11
5

It's common for programmers to make the database. Very common. Unfortunately many programmers do not have experience with the DB. They don't understand how to report against big data, the concepts of data marts, star schemas, etc. Some don't even understand the basics of normalization.

If one man has the skills to do everything at an expert level it makes for a very good product. A one man army can do what a 10 man team can do in a fraction of the time with 1000 times the quality. Not an exaggeration.

It's in the best interest for the programmer to do it (less people), assuming the programmer knows what he is doing. Of course there are thousands of failures to point at too.

Lord Tydus
  • 1,429
  • 1
  • 10
  • 12
  • I find this happening a lot on all my small teams. The developers with little DB experience are expected to design (not so tough on the surface) and tune (a lot harder) databases under their code. Always wish I could have a DBA at my disposal. – Rig Apr 28 '12 at 22:33
  • 1
    "Not an exaggeration." It is, unless you can qualify this claim somehow. – Burhan Ali Oct 11 '12 at 06:03
4

Its an interesting question - there is a strong argument that most decent developers should understand how to properly structure a relational database, that is to say that they should be capable of producing a normalised schema and - based on experience and common patterns - to make reasonable decisions as to how data should be structured stored (for me its mostly self evident, but I know that not everyone sees it that way).

Further, if you look at Entity Framework Code-first that suggests that the same thought that goes to building a low level data model will product a reasonable schema - or at least hint at one.

So no, I don't particularly think that you need a database expert to design a database schema - at least not for small and medium size databases (which are the things I've worked on).

The issue is that designing a good (or at least adequate) schema is not the whole story - especially not if the database has to scale. It seems to me that the "added value" brought by a DBA is in getting the things other than the basic schema right - indexes, configuring storage, maintenance of the database (keeping file sizes in check, rebuilding indexes, etc), being smarter with users and roles and so on and so forth.

A good programmer should bring a diverse portfolio of skills - should be more than an [insert langugage of choice] coder and I would include understanding of databases in that portfolio.

Murph
  • 7,813
  • 1
  • 28
  • 41
4

I think the ability to design a reasonable relational database is essentially a necessity for non-junior programmers.

With that said, particularly for large applications, it's vital to get the database "right" the first time (schema, indexing, etc). If the company has access to a skilled DBA, that task should fall onto their plate; in general they will be more qualified. Potentially review/discussion should be done with the lead developer who will be accessing and working with the database on the client-side so that there are no surprises. If there's no DBA, the programmer designs the database.

Bobby Everyteen
  • 71
  • 2
  • 1
    Data base administrators are not necessarily data analysts. It requires different skill sets to tune a database and normalize relational data, respectively. – Gilbert Le Blanc Apr 30 '12 at 14:06
2

I see two questions here:

  • Should database developers model business logic?
  • Should I know how to persist data to the database?

Business Logic

  • Business logic does not live in a database. It's a conceptual model which must be independent of other layers within your system.

  • You can always replace one database with another, or you might even decide to use a NoSQL solutions to address potential performance issues.

  • Database developers can be involved during modelling process, but normally this is done by people with a complete understanding of a problem domain. In our organisation this is done by server side developers.

  • Many think that database is a foundation of your application. Make poor foundation, and the system will fall. I disagree with this. I see database as a storage medium that can be always replaced.

Persisting Data

  • You should know how to persist data to different storage mediums, including SQL and NoSQL solutions.

  • Level of required expertise will vary with the size of the system that you are working on.

  • Small companies would expect you to have that knowledge, when larger companies would normally hire experts to address performance, scalability and security related requirements.

To summarise:

  • Domain model is a foundation of your system, not the database.

  • If you work for a small company on a relatively small project, then you should probably design the database yourself.

  • If you work for a large company on an enterprise system, then it probably makes more sense to pass work to the domain experts.

CodeART
  • 3,992
  • 1
  • 20
  • 23