Which is more important? DB design or coding? [closed]

Answer 1

If you are careless with either one you are doomed.

Answer 2

If you are unsure of your skills in either area then do your best to seperate the two as much as possible. The worst scenario is writing a tangled mess that can't be easily corrected or maintained later.

Answer 3

It depends on your perspective. If you're a DBA then the db, if you're a developer than the code.

I've seen developers utterly abuse database with "bag" tables and i've seen DBAs create monsterous application code that is fine if you understand the structure of the database but opaque otherwise.

Ergo, both are critically important and if you're only experienced in the one you should get someone experienced to look at the other or improve your own skill set where it is lacking.

Answer 4

I will not attempt to duplicate many of the fine comments made thus far. Nor will I spend any time identifying the dubious statements also made.

But I will add the following points.

If you are like most people you are referring to a RDBMS as the database in your question. An RDBMS is essentially a slave. It listens on a port and is duty bound to attempt to service all requests that come over that port. It has no way of know which of those requests are just plain stupid or ill-advised. Thus it is is easy for the most perfectly designed DB to be abused to the point of locking up the server. This implies that the code is more important. DBAs everywhere can be found pulling out their hair in response to some of the dumber things that app developers throw at the servers they manage.

So the best advice I can give you on the topic is to ensure that the DB is accessed by an API that is written by the same developer who designed the DB. Make it the responsibility of one dude (or one group reporting to the same dude) to ensure sound design decisions are made for both. If you're that dude, then don't skimp on one at the expense of the other. Design your API so that a refactoring of the DB can be done transparently to the clients of the API.

Answer 5

Having worked with an appalling database design before, I must put my hat in the database (or data model / ORM) design ring.

Get together with some people knowledgeable in your company/client about the problem area, and get all of the data required on paper, the group it by logical areas, then you will start forming a data model which you could turn into Objects, Database Schemas or an .xsd, etc. Each item of data will have a name, a type, maybe maximum length for strings, or be a set or list or map of certain minimum or maximum capacities.

Whether you design the database first after this, or the OO model is up to you, but at least you made an effort to get a sane partitioned model up front.

In fact in an MVC design, I would classify the OO data model (classes in Java/C#) as the Model and intrinsically linked with the database schema (with added transients and utility methods of course). Your controller - the "coding" in your question - should really implement business logic using the model as represented by the objects you extract from the database via a DAO/ORM.

Answer 6

Depends one where you are in knowledge about both...and product requirements.

Neglect either side and your product could be in trouble.

That said, I tend to follow a DDD style of coding, where I define everything but my database first. That gives me a better idea of what data needs to be stored.

Then, once that is complete I can create and tune my database to suite.